Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 774B49E7 for ; Wed, 17 Aug 2016 00:25:40 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from thomaskerin.io (static.204.212.9.5.clients.your-server.de [5.9.212.204]) by smtp1.linuxfoundation.org (Postfix) with ESMTP id 8AD241CA for ; Wed, 17 Aug 2016 00:25:38 +0000 (UTC) Received: from [10.137.3.17] (tor-relay.m5i.uk [178.239.167.15]) by thomaskerin.io (Postfix) with ESMTPSA id F035511981029 for ; Wed, 17 Aug 2016 00:25:32 +0000 (UTC) To: bitcoin-dev@lists.linuxfoundation.org References: <57B31EBC.1030806@jonasschnelli.ch> From: Thomas Kerin Message-ID: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io> Date: Wed, 17 Aug 2016 01:25:29 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Icedove/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="P8p9DkC0LSXHrBbmPilabWnHfd8wJQ95N" X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Wed, 17 Aug 2016 00:26:08 +0000 Subject: Re: [bitcoin-dev] Hardware Wallet Standard X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 00:25:40 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --P8p9DkC0LSXHrBbmPilabWnHfd8wJQ95N Content-Type: multipart/mixed; boundary="iN0N0tFHgqOJln4tDXdFvgUfN4jRkpMhO" From: Thomas Kerin To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io> Subject: Re: [bitcoin-dev] Hardware Wallet Standard References: <57B31EBC.1030806@jonasschnelli.ch> In-Reply-To: --iN0N0tFHgqOJln4tDXdFvgUfN4jRkpMhO Content-Type: multipart/alternative; boundary="------------025D8A9ED594D5FDC3F544C7" This is a multi-part message in MIME format. --------------025D8A9ED594D5FDC3F544C7 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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 segw= it) > - 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 p2s= h > transactions. Is this always the scriptPubKey of the transaction outpu= t > that is spent by this input? For p2wsh nested in BIP16 p2sh transaction= s > there are three scripts > > witness: 0 <1 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 segw= it) > - 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 p2s= h > transactions. Is this always the scriptPubKey of the transaction outpu= t > that is spent by this input? For p2wsh nested in BIP16 p2sh transaction= s > there are three scripts > > witness: 0 <1 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 --------------025D8A9ED594D5FDC3F544C7 Content-Type: text/html; charset=windows-1252 Content-Transfer-Encoding: quoted-printable

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.

=46rom 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&=
gt; 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.linuxfounda=
tion.org
https://lists.=
linuxfoundation.org/mailman/listinfo/bitcoin-dev


On 08/16/2016 06:48 PM, Jochen Hoenick= e 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.

=46rom 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&=
gt; 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/mailm=
an/listinfo/bitcoin-dev

--------------025D8A9ED594D5FDC3F544C7-- --iN0N0tFHgqOJln4tDXdFvgUfN4jRkpMhO-- --P8p9DkC0LSXHrBbmPilabWnHfd8wJQ95N Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXs675AAoJED6nkklm0EibrtMP/RxUkbi2WBSFrYJwyA26tSjI zpLw+W6Op8pmLYQXOA7DTqN07biCFKRCHNKdm+SXkTS108eisDkYdYEtbpz4GpG0 f/qUy1PKigyvuJFzI0BKK/SCpWeafeDM9ISjYbDiaODO/SkiLbAuRbyS9hj9NQpe eljNZopggLddFUnvAqldjq9CryeoQeXqaD3JlIViZ4V+j49qopgzvjitB3Dbpk9N rjes3xAj6oStIzZF9PVnJefkt1KG8VlG+pyDZya+0s93xAHsKYU9968ikLQ9U0/B U68zjo7I6fHK0Qt+eiiR7WOqjol9j9dJfrDatiDsvqmxiSYo81y+8Txzk+JOX7Zb 6xusz0BHDQtJZnGBC5iLHVzapug5TxDxR6mc7om2188p4j9I0iWVst/93OGcIogI LY9z8OP20b/Tx/0PIhJPj8tTWBqTJt07P4nsnMgOzkUOUC5t6Kn+QM+QN74PSCHX VRFBAHHkQUsN5p1mmAGZcYydAkinLZ0NbEObFuTKYdehZXKdVxuaiPRaFMrrhEBR 6yfS4lTUFPPKXKPiAZlsiwj/PhCRduBcx1bggY71+c7FUGzOz0POPMyhXqCLFO9R k21LTiKPyK4iV0M2vTwwtpSFx+X3ua1oDS98QTZZdc1os0kRLtP+RUlx8UWAGvaa QRK643UrxGBb/vP8RPz+ =TGSI -----END PGP SIGNATURE----- --P8p9DkC0LSXHrBbmPilabWnHfd8wJQ95N--