Nostr notes by

📅 Original date posted:2019-07-09 📝 Original message:Hi ...

2023-06-07T20:19:17+02:00

In reply to nevent1q…nvyx
_________________________

📅 Original date posted:2019-07-09
📝 Original message:Hi all,

Just to be brief, I'll kick off with an attack scenario.

1. I am a signer, I get a PSBT that is ready to sign. I parse. I sign
according to the PSBT as-is.
2. I notice my UTXO was stolen by a hacker because they changed my PSBT
input's sighashtype to SIGHASH_ANYONECANPAY | SIGHASH_NONE and after the
fact they changed the outputs to send to themselves, and added an input
they signed with SIGHASH_ALL.
3. I lose the BTC in my UTXO.

So we should definitely add to the signer checks "ensure the sighash type
given is the type of sighash you want to sign." etc.

My proposal for a wording change would be addition to the bullet list:

- If a sighash type is provided, the signer MUST check that the sighash
type is acceptable to them, and fail signing if unacceptable.
- If a sighash type is not provided, the signer SHOULD sign using
SIGHASH_ALL, but may sign with any sighash type they wish.

Any thoughts?

Thanks,
Jon

--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190710/60601766/attachment.html>;

📅 Original date posted:2019-06-28 📝 Original message:Thanks ...

2023-06-07T20:18:49+02:00

In reply to nevent1q…hc9t
_________________________

📅 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 date posted:2019-06-27 📝 Original message:Hi ...

2023-06-07T20:18:48+02:00

In reply to nevent1q…0cr6
_________________________

📅 Original date posted:2019-06-27
📝 Original message: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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190628/eee0ccf7/attachment.html>;

📅 Original date posted:2019-06-27 📝 Original message:Thanks ...

2023-06-07T20:18:45+02:00

In reply to nevent1q…3eld
_________________________

📅 Original date posted:2019-06-27
📝 Original message:Thanks for the reply.

The way we would do it is:

Let's say we have 3 cold keys for multisig: A B and C

Whose xpubs are: xA xB and xC

We all sign each other's xpubs, whose signatures are:
sAxB
sAxC
sBxA
sBxC
sCxA
sCxB

We can then create a wallet that says "when verifying change with 0x01
global type proposed by Andrew Chow, if the change is multisig, we MUST
require the other pubkeys to have signatures via my 0x02 proposal"

This way, all my PSBTs for my cold will have:
1. an 0x01 entry to tell me how to get my change.
2. All 6 of the signatures above.

And the signer will then look at the change, check my pubkey by deriving
the xpub and checking equality to the BIP_DERIVATION of the output... it
will then check the OTHER pubkeys via BIP32_DERIVATION to master
fingerprint, then link that fingerprint to a 0x02 sig from MY key,
verifying all pubkeys.

So this proposal of mine would not only fix the "send to address
verification" problem for HD, but also the multisig change problem with
0x01.

Cool.

Only thing that is kind of sad is having to include n! (of m-of-n)
signatures in every PSBT... but tbh, the PSBT size is not of much concern.

Thanks for the reply.
- Jonathan

2019年6月27日(木) 13:49 Dmitry Petukhov <dp at simplexum.com>:

> Hi!
>
> I wonder how your scheme handles multisig ?
>
> As I understand, you sign individual xpubs with cold keys, so that cold
> keys can check destination addresses are trusted.
>
> I seems to me that if you sign individual xpubs of a multisig warm
> wallet, and one key from that multisig is compromized, attackers can
> then create a single-sig destination address that they control, and
> move the coins in a chain of two transactions, first to this single-sig
> address, and then to an address that they independently control.
>
> My idea to prevent this [1] is to sign the whole 'xpub package' of the
> multisig wallet, but there is also an issue of 'partial compromize',
> where some of the keys in a multisig warm wallet is compromized, and
> you do not want to regard a particular 'xpub package' as trusted. My
> idea was [2] to use an auxiliary message that would be signed along with
> the 'xpub package', and that message can include specific 'epoch' word
> that hardware wallet can show prominently before signing, or have
> 'serial number' for xpub packages (but that will require to store last
> known serial inside hw wallet, making it stateful).
>
> I like the idea to extend PSBT to accomodate these schemes, but given
> that the huge number of possible schemes that each may probably
> require its own PSBT field type, I think that this is better dealt with
> outside of PSBT, as 'PSBT metainformation', or using some form of
> 'vendor-specific', or 'metainformation-specific' PSBT field. This way
> each usecase can be independently described in its own documentation,
> that would include the particulars of the format for the
> metainformation. This would also make it easier to implement PSBT for
> simple cases, because the 'core specification' would not grow that big.
>
> [1]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016917.html
>
> [2]
>
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016926.html
>
>
> В Thu, 27 Jun 2019 11:11:23 +0900 Jonathan Underwood via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Hello all,
> >
> > Just wanted to pick your brains about an idea for PSBT extension.
> >
> > One problem we try to solve with cold -> warm and warm -> hot sends
> > for our exchange wallet is "How do I know that the address I am
> > sending to is not a hacker's address that was swapped in between
> > unsigned tx creation and first signature?"
> >
> > We have a proprietary JSON based encoding system which we are looking
> > to move towards PSBT, but PSBT is missing this key functionality.
> >
> > BIP32_DERIVATION does allow us to verify the address is from a certain
> > XPUB, but, for example, it can not allow us to verify a signature of
> > that xpub.
> >
> > I have made a rough draft of the proposed key value specification.
> >
> https://github.com/junderw/bips/blob/addXpubSig/bip-0174.mediawiki#specification
> >
> > The signing key path used in the spec is just randomly chosen 31 x 4
> > bits shown as numbers with hardened paths.
> >
> > Since this issue seems similar to the change address issue, I started
> > from that as a base. With the HW wallet case, I can verify the xpub
> > by just deriving it locally and comparing equality, however, in our
> > case, we need to verify an xpub that we do not have access to via
> > derivation from our cold key(s) (since we don't want to import our
> > warm private key into our cold signer)
> >
> > So the flow would be:
> > 1. Securely verify the xpub of the warm / hot wallet.
> > 2. Using the airgap signing tool, sign the xpub with all cold keys.
> > 3. Upload the signature/xpub pairs to the online unsigned transaction
> > generator.
> > 4. Include one keyval pair per coldkey/xpub pairing.
> > 5. When offline signing, if the wallet detects there is a global
> > keyval XPUB_SIGNATURE with its pubkey in the key, it must verify that
> > all outputs have BIP32_DERIVATION and that it can verify the outputs
> > through the derivation, to the xpub, and to the signature.
> >
> > In my attempt to fitting this into PSBT, I am slightly altering our
> > current system, so don't take this as an indication 100% of how we
> > work in the backend.
> >
> > However, I would like to hear any feedback on this proposal.
> >
> > Thanks,
> > Jonathan
> >
>
>

--
-----------------
Jonathan Underwood
ビットバンク社チーフビットコインオフィサー
-----------------

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20190627/14367388/attachment-0001.html>;