📅 Original date posted:2016-08-16
📝 Original message: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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 213 bytes
Desc: OpenPGP digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/37adb191/attachment.sig>;
Jochen Hoenicke [ARCHIVE] /
npub1tu…dca6f
2023-06-07 17:52:48
in reply to nevent1q…w0nl
Author Public Key
npub1tue9u2scw5pe77vn4fz0464zz0387gm0zwy2zjhqg2yap36zhj2s4dca6fPublished at
2023-06-07 17:52:48Event JSON
{
"id": "2c36ca60c5b1377468603d265a6db8656890fb7df68810a530edb10f27e76788",
"pubkey": "5f325e2a1875039f7993aa44faeaa213e27f236f1388a14ae04289d0c742bc95",
"created_at": 1686160368,
"kind": 1,
"tags": [
[
"e",
"6e7f7cb2c3110cb7289a3abd667304a3b4e6f9ba4e2581c492d7b93c214a5ea1",
"",
"root"
],
[
"e",
"5d0f059c1d51ee795bb62e231740ab004737ab556bdf32825005088f76a11c30",
"",
"reply"
],
[
"p",
"7631397e469f47f3535567311f5f7c17129e0ff2cb253df015e3d92ddfd92c63"
]
],
"content": "📅 Original date posted:2016-08-16\n📝 Original message:Hello Jonas,\n\nthanks for your efforts of writing the draft for the standard.\n\nFirst, this only describes detached signing. A wallet also needs to\nconnect with a hardware wallet at some time to learn the xpubs\ncontrolled by the hardware. Do you plan to have this in a separate\nstandard or should this also be included here? Basically one needs one\noperation: get xpub for an HD path.\n\nFrom a first read over the specification I found the following points\nmissing, that a fully checking hardware wallet needs to know:\n\n- the amount spent by each input (necessary for segwit).\n- the full serialized input transactions (without witness informations)\nto prove that the amount really matches (this is not necessary for segwit)\n- the position of the change output and its HD Path (to verify that it\nreally is a change output).\n- For multisig change addresses, there are more extensive checks\nnecessary: All inputs must be multisig addresses signed with public\nkeys derived from the same set of xpubs as the change address and use\nthe same \"m of n\" scheme. So for multisig inputs and multisig change\naddress the standard should allow to give the parent xpubs of the other\npublic keys and their derivation paths.\n\nIt is also a bit ambiguous what the \"inputscript\" is especially for p2sh\ntransactions. Is this always the scriptPubKey of the transaction output\nthat is spent by this input? For p2wsh nested in BIP16 p2sh transactions\nthere are three scripts\n\n witness: 0 \u003csignature1\u003e \u003c1 \u003cpubkey1\u003e \u003cpubkey2\u003e 2 CHECKMULTISIG\u003e\n scriptSig: \u003c0 \u003c32-byte-hash\u003e\u003e\n (0x220020{32-byte-hash})\n scriptPubKey: HASH160 \u003c20-byte-hash\u003e EQUAL\n (0xA914{20-byte-hash}87)\n (quoted from BIP-141).\n\nIn principle one could put witness and scriptSig (with \"OP_FALSE\" in\nplaces of the signatures) in the raw transaction and make inputscript\nalways the scriptPubKey of the corresponding output. Then one also\ndoesn't need to distinguish between p2pkh or p2sh or p2wpkh or \"p2wpkh\nnested in bip16 p2sh\" transactions.\n\nRegards,\n Jochen\n\n\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 213 bytes\nDesc: OpenPGP digital signature\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160816/37adb191/attachment.sig\u003e",
"sig": "ab63f89c7f5308ce921673c6ac234c95aab882ea1e4e246956dd5b470543e8494e883f7c0781e5ecf8feab9caac60c71a9001e09203e757f946fca3fdc80c4ca"
}