public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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 --]

  reply	other threads:[~2016-08-17  0:25 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-16 14:10 [bitcoin-dev] Hardware Wallet Standard Jonas Schnelli
2016-08-16 14:48 ` Pavol Rusnak
2016-08-16 15:13   ` Jonas Schnelli
2016-08-16 15:21     ` Pavol Rusnak
2016-08-16 17:48 ` Jochen Hoenicke
2016-08-17  0:25   ` Thomas Kerin [this message]
2016-08-17  7:24     ` Jonas Schnelli
2016-08-17  7:40       ` Nicolas Bacca
2016-08-17 10:13       ` Dana L. Coe
2016-08-17 11:34         ` Jonas Schnelli
2016-08-17 17:06           ` Marek Palatinus
2016-08-18  6:54             ` Jonas Schnelli
2016-08-18  9:15               ` Marek Palatinus
2016-08-18  9:35                 ` Jonas Schnelli
2016-08-18  9:43                   ` Marek Palatinus
2016-08-18  9:49                     ` Jonas Schnelli
2016-08-18 10:23                       ` Nicolas Bacca
2016-08-24 10:31                         ` Thomas Kerin
2016-08-16 19:22 ` Luke Dashjr
2016-08-17  0:03   ` Thomas Daede
2016-08-16 23:36 ` Aiqin Li
2016-08-17  0:14   ` Peter Todd
2016-08-17  7:27     ` Nicolas Bacca
2016-08-17 18:36     ` Bryan Bishop
2016-08-22 16:50 ` Moral Agent
2016-08-28 23:14   ` Corey Haddad

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9c8dd0e5-e333-90c8-965f-10fb29d875a5@thomaskerin.io \
    --to=me@thomaskerin.io \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox