Jonathan Underwood [ARCHIVE] on Nostr: ๐ Original date posted:2019-06-28 ๐ Original message:Thanks for the reply ...
๐
Original date posted:2019-06-28
๐ Original message:Thanks for the reply Peter. Comments inline:
2019ๅนด6ๆ28ๆฅ(้) 23:37 Peter D. Gray <peter at coinkite.com>:
> 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 at 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
>
--
-----------------
Jonathan Underwood
ใใใใใณใฏ็คพ ใใผใใใใใณใคใณใชใใฃใตใผ
-----------------
ๆๅทๅใใใกใใปใผใธใใ้ใใฎๆนใฏไธ่จใฎๅ ฌ้้ตใใๅฉ็จไธใใใ
ๆ็ด: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190629/4b55a1c7/attachment-0001.html>;
๐ Original message:Thanks for the reply Peter. Comments inline:
2019ๅนด6ๆ28ๆฅ(้) 23:37 Peter D. Gray <peter at coinkite.com>:
> 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 at 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
>
--
-----------------
Jonathan Underwood
ใใใใใณใฏ็คพ ใใผใใใใใณใคใณใชใใฃใตใผ
-----------------
ๆๅทๅใใใกใใปใผใธใใ้ใใฎๆนใฏไธ่จใฎๅ ฌ้้ตใใๅฉ็จไธใใใ
ๆ็ด: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190629/4b55a1c7/attachment-0001.html>;