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 <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 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 <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