Thomas Kerin [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-16 📝 Original message:Hi all, Thanks again Jonas ...
📅 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>;
📝 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>;