Thanks for the reply Peter. Comments inline:
Thanks I get the idea better now: You want the PSBT creator to be
able to indicate to the signers that it (the PSBT creator) controls
specific outputs that don't otherwise look like change.
Some problems:
> extended private key of the current signer derived from the
> signer's root to m/2042083607'/959190427'/1400854130'/990526201'
1) The PSBT creator would need to know that private key, and the Coldcard, as a matter
of policy, will never export a private subkey.
I think you have misunderstood. The signature inserted into this 0x02 field is generated BY the signer (Coldkey) airgapped ahead of time. Then the signature (and all the xpubs that were signed, since basically the "key" value contains the "pubkey" and "message" while the "value" part has the "signature". so all data items for verification are present.) will be stored on the unsigned transaction preparing app. (MyTrezor dot com etc. have an encrypted storage through Dropbox + encrypting with Trezor, so they, for instance, could store the "whitelist signatures" on that dropbox feature.
2) The 'm' in that path depends on who is reading the PSBT file, in the multisig
case. Each cosigner would need a different version of the PSBT file
Again, this is the m of the signer's root. The signer should have an xprv, or some sort of seed (a la BIP39 or aezeed or Electrum phrase etc.) that gets turned into a xprv. That xprv is m in this case... in the case that some offline signer is storing the xprv of some path like "xprv/25'/42'" or something, then the signer's "identity" is whatever xprv that signer holds and not any of the xprvs derived from that first xprv.
The reason we want only one HD key to sign it is because we want the signer to be able to generate that path from the root xprv they hold, check that the pubkey matched the pubkey for verification, then verify. Now the signer knows "oh, I have signed this xpub / multisig setup before, therefore I trust it"
3) XPUB's are big and hard to parse, and this addition is using lots of them.
Any app requiring this level of security would gladly add a few millisecond for parsing some xpubs.
Any HD wallet that can sign using HD derived keys already has the necessary tools to parse an xpub.
4) Coinjoins, and more complex script types, will want to authorize
outputs that the PSBT signer may not fully understand. Your proposal
would only help P2PKH and M-of-N multisig users.
Yes. This proposal is not a requirement. It is just a reservation for a slot in the key-value scheme for a use case that many exchanges and hardware wallets should implement. We have implemented something similar to this using JSON format internally, but since HW wallet makers seem to be moving toward PSBT adoption, I would love for this info to be possible to be sent into an HW wallet so that Trezor etc. can implement this "whitelist" type situation in a way that the Trezor can trust. (remember, a "whitelist" that just lives in my trezor dot com website cache etc. is prone to modification, whereas with my proposal the worst case is a hacker deletes a signature, so Trezor doesn't trust something it should have, and fails signing. It can not add itself to the "whitelist" without the HW wallet private key.)
To fix, may I propose:
The following suggestions seems to be predicated on a misunderstanding of my proposal, so I will hold off for now.
- the signer and PSBT creator must share a pubkey/private key out of band (setup time)
- the origin of that key is out of scope of this standard (but it could be derived via BIP32)
- the PSBT creator can, optionally, sign any or all output sections by number using that key
I would prefer the signatures are in the global section, and the
signature is over all the bytes in the indicated output section,
as originally serialized when it came into the signer's possession.
We should be able to support multiple signers for individual outputs,
and also multiple signatures for the same output section. That would
support different derived keys per co-signer, and also quorum
approval or other policies like that.
Afterthought: Might be good to allow signature over the unsigned transaction, or
maybe it should be part of the signature always.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
On Fri, Jun 28, 2019 at 11:44:15AM +0900, Jonathan Underwood wrote:
> Hi Peter,
>
> tl;dr The problem this solves is "How can a signer verify an address with
> HD changing the address every time?"
>
> As an aside: (This is sort of explaining the current PR for the 0x01 global
> field (separate from mine))
> The problem is more easily understood with change addresses: If someone can
> alter my PSBT before signing, they could replace my change address with
> their address, and my signer would not know unless the signer just guesses
> all the path sets it knows, then derives thousands of change addresses and
> searches (most likely a signer is offline, so gap limit doesn't work since
> we can't tell which change addresses have tx history. So the 0x01 global
> tag will tell the signer "here's how you get from your master private key
> to the xpub used in the change output's output BIP32_DERIVATION tag... you
> can then derive the same key and check it is yours before signing."
>
> Back to my proposal, this problem extends across wallets, since,
> for example, if I want to send from my cold wallet to my warm wallet, I
> don't want to give my cold signer my warm master key just so it can derive
> and check the key. That's what signatures are for. So this proposal says "A
> signer can be built to only sign if it sees a signature that itself has
> signed, then from that signed xpub(s) derives the BIP32_DERIVATION in the
> outputs, and if the output doesn't match it will reject and not sign"
>
> This creates a sort of "chain of trust" for the wallet.
>
> Currently the best way to prevent this (hacker swapping the send to
> address) without using signatures is to reuse the same address every time
> you want to send to the warm wallet, since after a few times, the signers
> (people) will be able to remember the address.
>
> This is a huge HD drawback for high security requirement environments.
> Having this data in the PSBT standard will allow Trezor etc. to create an
> enforceable whitelist feature.
>
> Let me know if you have feedback on the details.
>
> Thanks,
> Jon
>
> 2019年6月28日(金) 0:07 Peter D. Gray <peter@coinkite.com>:
>
> > I haven't studied the new proposal in depth, but my first impression is:
> >
> > Wouldn't it just be easier and better to just sign the entire "outputs"
> > section of the PSBT?
> >
> > The signature would cover every byte, and therefore would cover any
> > future BIP additions to the outputs area, and also help non-multisig
> > cases today.
> >
> > ---
> > Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG:
> > A3A31BAD 5A2A5B10
> >
> >
>
> --
> -----------------
> Jonathan Underwood
> ビットバンク社 チーフビットコインオフィサー
> -----------------
>
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
>
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3