📅 Original date posted:2016-08-16
📝 Original message:Hi all,
Thanks again Jonas for starting this!
I worked on a similar proposal a while back (never posted), approaching
the same problem as if a merchant's website accepted xpubs/public keys,
created multi-signature addresses, and wanted the user to easily sign
offline instead of using some javascript code / using Core's debug
console / coinb.in
Happily the procedure is largely the same, though I would echo Jochen's
point that there needs to be a way to request an xpub/public key.
The redeemScript and witnessScript are also required fields for full
validation & signing a transaction input if it's P2SH, or just the
witnessScript if it's bare V0_P2WSH
Since the output amounts are required, so maybe instead provide
serialized TxOut's? or Utxo's i.e: [txid, vout, amount, scriptPubKey].
The protocol ought to be as stateless as possible - it can't be assumed
whether the redeemScript and other details will ever be saved on the
device - so perhaps provide the redeemScript + witnessScript as the
final fields on the Utxo structure above.
I do think it enables two important choices for bitcoin users:
* it might be preferable to provide your own xpub vs generating a brand
new HD key to potentially lose.
* you could leverage the services provided by [random example]
GreenAddress without necessarily having to rely on signing code provided
by them, and so end up only having to trust only one ECDSA
implementation when interacting with a wide number of services
All the best
Thomas
On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing. A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware. Do you plan to have this in a separate
> standard or should this also be included here? Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary: All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme. So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions. Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
> witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
> scriptSig: <0 <32-byte-hash>>
> (0x220020{32-byte-hash})
> scriptPubKey: HASH160 <20-byte-hash> EQUAL
> (0xA914{20-byte-hash}87)
> (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output. Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
> Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
On 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:
> Hello Jonas,
>
> thanks for your efforts of writing the draft for the standard.
>
> First, this only describes detached signing. A wallet also needs to
> connect with a hardware wallet at some time to learn the xpubs
> controlled by the hardware. Do you plan to have this in a separate
> standard or should this also be included here? Basically one needs one
> operation: get xpub for an HD path.
>
> From a first read over the specification I found the following points
> missing, that a fully checking hardware wallet needs to know:
>
> - the amount spent by each input (necessary for segwit).
> - the full serialized input transactions (without witness informations)
> to prove that the amount really matches (this is not necessary for segwit)
> - the position of the change output and its HD Path (to verify that it
> really is a change output).
> - For multisig change addresses, there are more extensive checks
> necessary: All inputs must be multisig addresses signed with public
> keys derived from the same set of xpubs as the change address and use
> the same "m of n" scheme. So for multisig inputs and multisig change
> address the standard should allow to give the parent xpubs of the other
> public keys and their derivation paths.
>
> It is also a bit ambiguous what the "inputscript" is especially for p2sh
> transactions. Is this always the scriptPubKey of the transaction output
> that is spent by this input? For p2wsh nested in BIP16 p2sh transactions
> there are three scripts
>
> witness: 0 <signature1> <1 <pubkey1> <pubkey2> 2 CHECKMULTISIG>
> scriptSig: <0 <32-byte-hash>>
> (0x220020{32-byte-hash})
> scriptPubKey: HASH160 <20-byte-hash> EQUAL
> (0xA914{20-byte-hash}87)
> (quoted from BIP-141).
>
> In principle one could put witness and scriptSig (with "OP_FALSE" in
> places of the signatures) in the raw transaction and make inputscript
> always the scriptPubKey of the corresponding output. Then one also
> doesn't need to distinguish between p2pkh or p2sh or p2wpkh or "p2wpkh
> nested in bip16 p2sh" transactions.
>
> Regards,
> Jochen
>
>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.sig>;
Thomas Kerin [ARCHIVE] /
npub1e4…nt5am
2023-06-07 17:52:48
in reply to nevent1q…kqtp
Author Public Key
npub1e4azew50kk9xzvfpqxzlyftkjt6kken0kf9lnncpdj524f9y4cqsfnt5amPublished at
2023-06-07 17:52:48Event JSON
{
"id": "aca229e760b02b1f0b74cb9492dcf4c9599231e634f9c9655c217a497d1db160",
"pubkey": "cd7a2cba8fb58a6131210185f2257692f56b666fb24bf9cf016ca8aaa4a4ae01",
"created_at": 1686160368,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"2c36ca60c5b1377468603d265a6db8656890fb7df68810a530edb10f27e76788",
"",
"reply"
],
[
"p",
"5f325e2a1875039f7993aa44faeaa213e27f236f1388a14ae04289d0c742bc95"
]
],
"content": "📅 Original date posted:2016-08-16\n📝 Original message:Hi all,\n\nThanks again Jonas for starting this!\n\nI worked on a similar proposal a while back (never posted), approaching\nthe same problem as if a merchant's website accepted xpubs/public keys,\ncreated multi-signature addresses, and wanted the user to easily sign\noffline instead of using some javascript code / using Core's debug\nconsole / coinb.in\n\nHappily the procedure is largely the same, though I would echo Jochen's\npoint that there needs to be a way to request an xpub/public key.\n\nThe redeemScript and witnessScript are also required fields for full\nvalidation \u0026 signing a transaction input if it's P2SH, or just the\nwitnessScript if it's bare V0_P2WSH\n\nSince the output amounts are required, so maybe instead provide\nserialized TxOut's? or Utxo's i.e: [txid, vout, amount, scriptPubKey].\n\nThe protocol ought to be as stateless as possible - it can't be assumed\nwhether the redeemScript and other details will ever be saved on the\ndevice - so perhaps provide the redeemScript + witnessScript as the\nfinal fields on the Utxo structure above.\n\nI do think it enables two important choices for bitcoin users:\n\n* it might be preferable to provide your own xpub vs generating a brand\nnew HD key to potentially lose.\n\n* you could leverage the services provided by [random example]\nGreenAddress without necessarily having to rely on signing code provided\nby them, and so end up only having to trust only one ECDSA\nimplementation when interacting with a wide number of services\n\nAll the best\n\nThomas\n\nOn 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:\n\u003e Hello Jonas,\n\u003e\n\u003e thanks for your efforts of writing the draft for the standard.\n\u003e\n\u003e First, this only describes detached signing. A wallet also needs to\n\u003e connect with a hardware wallet at some time to learn the xpubs\n\u003e controlled by the hardware. Do you plan to have this in a separate\n\u003e standard or should this also be included here? Basically one needs one\n\u003e operation: get xpub for an HD path.\n\u003e\n\u003e From a first read over the specification I found the following points\n\u003e missing, that a fully checking hardware wallet needs to know:\n\u003e\n\u003e - the amount spent by each input (necessary for segwit).\n\u003e - the full serialized input transactions (without witness informations)\n\u003e to prove that the amount really matches (this is not necessary for segwit)\n\u003e - the position of the change output and its HD Path (to verify that it\n\u003e really is a change output).\n\u003e - For multisig change addresses, there are more extensive checks\n\u003e necessary: All inputs must be multisig addresses signed with public\n\u003e keys derived from the same set of xpubs as the change address and use\n\u003e the same \"m of n\" scheme. So for multisig inputs and multisig change\n\u003e address the standard should allow to give the parent xpubs of the other\n\u003e public keys and their derivation paths.\n\u003e\n\u003e It is also a bit ambiguous what the \"inputscript\" is especially for p2sh\n\u003e transactions. Is this always the scriptPubKey of the transaction output\n\u003e that is spent by this input? For p2wsh nested in BIP16 p2sh transactions\n\u003e there are three scripts\n\u003e\n\u003e witness: 0 \u003csignature1\u003e \u003c1 \u003cpubkey1\u003e \u003cpubkey2\u003e 2 CHECKMULTISIG\u003e\n\u003e scriptSig: \u003c0 \u003c32-byte-hash\u003e\u003e\n\u003e (0x220020{32-byte-hash})\n\u003e scriptPubKey: HASH160 \u003c20-byte-hash\u003e EQUAL\n\u003e (0xA914{20-byte-hash}87)\n\u003e (quoted from BIP-141).\n\u003e\n\u003e In principle one could put witness and scriptSig (with \"OP_FALSE\" in\n\u003e places of the signatures) in the raw transaction and make inputscript\n\u003e always the scriptPubKey of the corresponding output. Then one also\n\u003e doesn't need to distinguish between p2pkh or p2sh or p2wpkh or \"p2wpkh\n\u003e nested in bip16 p2sh\" transactions.\n\u003e\n\u003e Regards,\n\u003e Jochen\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n\nOn 08/16/2016 06:48 PM, Jochen Hoenicke via bitcoin-dev wrote:\n\u003e Hello Jonas,\n\u003e\n\u003e thanks for your efforts of writing the draft for the standard.\n\u003e\n\u003e First, this only describes detached signing. A wallet also needs to\n\u003e connect with a hardware wallet at some time to learn the xpubs\n\u003e controlled by the hardware. Do you plan to have this in a separate\n\u003e standard or should this also be included here? Basically one needs one\n\u003e operation: get xpub for an HD path.\n\u003e\n\u003e From a first read over the specification I found the following points\n\u003e missing, that a fully checking hardware wallet needs to know:\n\u003e\n\u003e - the amount spent by each input (necessary for segwit).\n\u003e - the full serialized input transactions (without witness informations)\n\u003e to prove that the amount really matches (this is not necessary for segwit)\n\u003e - the position of the change output and its HD Path (to verify that it\n\u003e really is a change output).\n\u003e - For multisig change addresses, there are more extensive checks\n\u003e necessary: All inputs must be multisig addresses signed with public\n\u003e keys derived from the same set of xpubs as the change address and use\n\u003e the same \"m of n\" scheme. So for multisig inputs and multisig change\n\u003e address the standard should allow to give the parent xpubs of the other\n\u003e public keys and their derivation paths.\n\u003e\n\u003e It is also a bit ambiguous what the \"inputscript\" is especially for p2sh\n\u003e transactions. Is this always the scriptPubKey of the transaction output\n\u003e that is spent by this input? For p2wsh nested in BIP16 p2sh transactions\n\u003e there are three scripts\n\u003e\n\u003e witness: 0 \u003csignature1\u003e \u003c1 \u003cpubkey1\u003e \u003cpubkey2\u003e 2 CHECKMULTISIG\u003e\n\u003e scriptSig: \u003c0 \u003c32-byte-hash\u003e\u003e\n\u003e (0x220020{32-byte-hash})\n\u003e scriptPubKey: HASH160 \u003c20-byte-hash\u003e EQUAL\n\u003e (0xA914{20-byte-hash}87)\n\u003e (quoted from BIP-141).\n\u003e\n\u003e In principle one could put witness and scriptSig (with \"OP_FALSE\" in\n\u003e places of the signatures) in the raw transaction and make inputscript\n\u003e always the scriptPubKey of the corresponding output. Then one also\n\u003e doesn't need to distinguish between p2pkh or p2sh or p2wpkh or \"p2wpkh\n\u003e nested in bip16 p2sh\" transactions.\n\u003e\n\u003e Regards,\n\u003e Jochen\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.html\u003e\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 819 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160817/69978782/attachment-0001.sig\u003e",
"sig": "be0b9d1a828a1e34dea3e0ada4fdf15bedfb55e55c6321acf2cfa43cc6f2f94517f43586bad190bedb5513b62cd45c2829309e61c75f1cf737dc7a22bd1e17ab"
}