Re: [bitcoin-dev] Hardware Wallet Standard

From: Thomas Kerin <me@thomaskerin•io>
To: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Hardware Wallet Standard
Date: Wed, 17 Aug 2016 01:25:29 +0100	[thread overview]
Message-ID: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io> (raw)
In-Reply-To: <e740b4e0-0597-4f80-2434-70e667b7923c@gmail.com>

[-- Attachment #1.1.1: Type: text/plain, Size: 6432 bytes --]

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@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@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #1.1.2: Type: text/html, Size: 8034 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]