Peter D. Gray [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-02-06 to 2021-09-01
💬 Posted a total of 18 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 22:58:24

- reply

📅 Original date posted:2021-09-01
📝 Original message:> ... I tried doing this with "application/bitcoin-psbt" back in
> 2019 but it was not accepted...
Thanks for this background.
Based on your experience, we should probably ignore the IANA then,
and just declare a few useful "mime types" (note the quotes) in a
new BIP. We can then agree inside the Bitcoin community on their
usage and meaning.
Anyone want to write that BIP and shepherd it? I can support you
but I'd rather write code.
---
@DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
On Tue, Aug 31, 2021 at 07:46:55PM +0000, Andrew Chow wrote:
> Hi Peter,
>
> It would be nice to have mime types registered for Bitcoin things, but
> I'm not sure that it will be possible, at least not in the way that we
> would like. I tried doing this with "application/bitcoin-psbt" back in
> 2019 but it was not accepted. From that attempt, here is what I have
> learned:
>
> There are only a few accepted top level types, so we would not be able
> to use "bitcoin" as the top level (unless you want to submit an RFC to
> add a "bitcoin" top level). Of the available top level types,
> "application" is the most appropriate for Bitcoin.
>
> Next is the tree that the mime type should be in. The best would be the
> Standards tree, but it has some requirements that Bitcoin doesn't really
> meet. In order to be in the standards tree, the registration must be
> either associated with an IETF specification (so a RFC) or registered by
> a recognized standards related organization. Unfortunately the closest
> thing to a standards organization that Bitcoin has is the BIPs process,
> and that is not a really a standards organization nor is it recognized
> by IANA. So in order to register the mimetypes as Standards tree types,
> we would need to write an RFC, but this could be an independent
> submission (https://www.rfc-editor.org/about/independent/) rather than
> IETF-stream submission. I did not continue to pursue this because I
> didn't have the time.
>
> Another alternative would be to use the Vendor tree, but that would
> prefix the mimetype with "vnd." so it would end up being something like
> "application/vnd.bitcoin.psbt". I did not think this was an reasonable
> so I did not continue to pursue this avenue.
>
>
> Andrew Chow
>
> On 8/31/21 2:27 PM, Peter D. Gray via bitcoin-dev wrote:
> > Hi list!
> >
> > I am proposing to register the following MIME (RFC 2046) media types with the IANA:
> >
> >
> > bitcoin/psbt
> >
> > - aka. a BIP-174 file, in binary
> > - does not make any claims about signed/unsigned status; lets leave that to the file
> >
> > bitcoin/txn
> >
> > - aka. wire-ready fully-signed transaction in binary
> >
> > bitcoin/uri
> >
> > - aka [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki)
> > - could be just a bare bech32 or base58 payment address
> > - but can also encode amount, comments in URL args
> > - potentially interesting as a response to 402 - Payment required
> >
> >
> > Other thoughts
> >
> > - some mime-types are proposed in BIP-71 but those are unrelated to above, and never
> > seem to have been registered
> >
> > - for those who like to encode their binary as base64 or hex, that can be indicated
> > as "encoding=hex" or "encoding=base64" in the optional parameters, just like
> > "text/plain; encoding=utf-8" does. However, the default must be binary.
> >
> > - although the above are useful for web servers, they are also useful elsewhere and I
> > intend to use them in NFC (NDEF records) where a shorter length is critical.
> >
> > - I have no idea how easily IANA will accept these proposals.
> >
> > - current approved mime types: https://www.iana.org/assignments/media-types/media-types.xhtml
> >
> > Thoughts?
> >
> > ---
> > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210901/c6f95528/attachment.sig>

2023-06-07 22:58:23

- reply

📅 Original date posted:2021-08-31
📝 Original message:QR Codes do not use IANA mime-types.
If anyone wanted to use UR encoding for PSBT data in a web context (http),
NFC, or email, it would probably be best to discourage them.
While I can understand the need for UR encoding in animated QR
codes, I don't think any other use-case could justify introducing
a new word list (ByteWords), a unique checksum algo (Xoshiro256),
fountain codes (Luby Transform) and CBOR... just to wrap a few k
of binary.
I do love CBOR though. It's the best.
---
@DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
On Tue, Aug 31, 2021 at 12:01:23PM -0700, Christopher Allen wrote:
> Note that a number of wallet companies are now supporting the UR encoded
> version of PSBTs, allowing for better QR & Airgap solutions, and also
> leverage CBOR which is an IETF standard.
>
> We have a community of Airgap wallet developers at
> https://github.com/BlockchainCommons/Airgapped-Wallet-Community
>
> …and libraries at
> https://github.com/BlockchainCommons/crypto-commons#urs
>
> We’d love for you to register UR as well, maybe as bitcoin/psbt+ur
>
> Can you bring this up in our community for further discussion?
> https://github.com/BlockchainCommons/Airgapped-Wallet-Community/discussions
>
> Thanks!
>
> — Christopher Allen [via iPhone]
>
> On Tue, Aug 31, 2021 at 11:41 AM Peter D. Gray via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> > Hi list!
> >
> > I am proposing to register the following MIME (RFC 2046) media types with
> > the IANA:
> >
> >
> > bitcoin/psbt
> >
> > - aka. a BIP-174 file, in binary
> > - does not make any claims about signed/unsigned status; lets leave
> > that to the file
> >
> > bitcoin/txn
> >
> > - aka. wire-ready fully-signed transaction in binary
> >
> > bitcoin/uri
> >
> > - aka [BIP-21](
> > https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki)
> > - could be just a bare bech32 or base58 payment address
> > - but can also encode amount, comments in URL args
> > - potentially interesting as a response to 402 - Payment required
> >
> >
> > Other thoughts
> >
> > - some mime-types are proposed in BIP-71 but those are unrelated to above,
> > and never
> > seem to have been registered
> >
> > - for those who like to encode their binary as base64 or hex, that can be
> > indicated
> > as "encoding=hex" or "encoding=base64" in the optional parameters, just
> > like
> > "text/plain; encoding=utf-8" does. However, the default must be binary.
> >
> > - although the above are useful for web servers, they are also useful
> > elsewhere and I
> > intend to use them in NFC (NDEF records) where a shorter length is
> > critical.
> >
> > - I have no idea how easily IANA will accept these proposals.
> >
> > - current approved mime types:
> > https://www.iana.org/assignments/media-types/media-types.xhtml
> >
> > Thoughts?
> >
> > ---
> > @DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >

2023-06-07 22:58:22

- reply

📅 Original date posted:2021-08-31
📝 Original message:Hi list!
I am proposing to register the following MIME (RFC 2046) media types with the IANA:
bitcoin/psbt
- aka. a BIP-174 file, in binary
- does not make any claims about signed/unsigned status; lets leave that to the file
bitcoin/txn
- aka. wire-ready fully-signed transaction in binary
bitcoin/uri
- aka [BIP-21](https://github.com/bitcoin/bips/blob/master/bip-0021.mediawiki)
- could be just a bare bech32 or base58 payment address
- but can also encode amount, comments in URL args
- potentially interesting as a response to 402 - Payment required
Other thoughts
- some mime-types are proposed in BIP-71 but those are unrelated to above, and never
seem to have been registered
- for those who like to encode their binary as base64 or hex, that can be indicated
as "encoding=hex" or "encoding=base64" in the optional parameters, just like
"text/plain; encoding=utf-8" does. However, the default must be binary.
- although the above are useful for web servers, they are also useful elsewhere and I
intend to use them in NFC (NDEF records) where a shorter length is critical.
- I have no idea how easily IANA will accept these proposals.
- current approved mime types: https://www.iana.org/assignments/media-types/media-types.xhtml
Thoughts?
---
@DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210831/a4aa0e7d/attachment.sig>

2023-06-07 22:52:28

- reply

📅 Original date posted:2021-05-06
📝 Original message:Hi Tobias.
The most recent release of Coldcard now offers "Seed XOR" to solve
similar problems. It allows any numbers of standard BIP-39
compatible seed phrases to be bitwise XOR'ed together to make a new seed.
Coldcard can split an existing seed into 2, 3 or 4 new phrases, or
you can take your existing seed phrase, and XOR-in a new seed phrase
to arrive at a new random seed phrase (and wallet).
More details about this feature at: <https://seedxor.com>
Best part is XOR is simple enough that the split or combine operation can
be worked out by hand on paper. (We even made a worksheet for this.)
The checksums on each of the XOR parts protects the final result, and
each "part" is a fully functional decoy wallet.
Hope that helps!
On Wed, May 05, 2021 at 07:32:05PM +0200, Tobias Kaupat wrote:
> Hi all,
> I want to start a discussion about a use case I have and a possible
> solution. I have not found any satisfying solution to this use case yet.
>
> *Use case:*
> An existing mnemonic (e.g. for a hardware wallet) should be saved on a
> paper backup in a password encrypted form. The encrypted form should be a
> mnemonic itself to keep all backup properties like error correction.
>
> *Suggested solution:*
> 1) Take the existing mnemonic and extract the related entropy
> 2) Create a SHA526 hash (key) from a user defined password
> 3) Use the key as input for an AES CTR (empty IV) to encrypt the entropy
> 4) Derive a new mnemonic from the encrypted entropy to be stored on a paper
> backup
...
> *Existing solutions*
> One solution I found is "Seedshift" which can be found here:
> https://github.com/mifunetoshiro/Seedshift
>
> But I consider it less secure and I would like to suggest a solution based
> on provably secure algorithms rather than a "rot23 derivation". Also using
> a date as password seems not very clever to me.
>
> Kind regards
> Tobias
---
@DocHEX || Coinkite || PGP: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210506/a6b3fc68/attachment.sig>

2023-06-07 18:28:35

- reply

📅 Original date posted:2021-02-12
📝 Original message:Hard no to this idea:
On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen proposed:
...
> /48'/0'/0'/3'/PBKDF(complex string)'
As someone who has helped people find UTXO at key paths they didn't
know/want, this is a terrible idea. Key derivation paths should be
small, sequential integers, so they can be searched in reasonable time.
Of course when things are working it doesn't matter, but the stakes
can be very high when they stop working.
This is true for multisig and single signer.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
On Thu, Feb 11, 2021 at 02:29:46PM -0800, Christopher Allen wrote:
> I think the key issue here is avoiding xpub key reuse in multisig. Not only
> in the future with Schnorr, but we need it today!
>
> Current common practice by hardware wallets is the 48'/0'/0'/2' derivation
> for segwit multsig ( e.g.
> [90081696/48'/0'/0'/2']xpub6DYLEkDfCdHzh5FHGHDJksQvFqu6kYANa1sfo6fA8n5ZWkSwyCRVVzyq9LY2eNGB6T9BKDeGJp2ZarjRZHd7WB95nSaFEDhFMK6zSV6D49b
> ) is the only one used for ALL multisigs offered by that hardware wallet.
>
> As Pieter said, leveraging a HD path parameters can help, but we need a
> better, less reusable path for the index.
>
> I personally suggest a simpler solution, which is to create an index using
> a PBKDF of the Account Policy (a descriptor with all xpubs and keys
> removed), plus optional notes. (BTW, I think double sha256 or HMAC is
> overkill).
>
> Example: for the reference bit descriptor that might result in:
>
> ```
> wsh(sortedmulti(2,xpub661MyMwAqRbcFW31YEwpkMuc5THy2PSt5bDMsktWQcFF8syAmRUapSCGu8ED9W6oDMSgv6Zz8idoc4a6mr8BDzTJY47LJhkJ8UB7WEGuduB/1/0/*,xpub69H7F5d8KSRgmmdJg2KhpAK8SR3DjMwAdkxj3ZuxV27CprR9LgpeyGmXUbC6wb7ERfvrnKZjXoUmmDznezpbZb7ap6r1D3tgFxHmwMkQTPH/0/0/*))
> ```
>
> What Blockchain Commons (and the Airgapped Wallet Community) call a policy
> map would be
>
> ```
> wsh(sortedmulti(1,,,))
> ```
>
> A PBKDF of that as would be unique for all 2 of 3 segwig transactions. With
> the addition of the addition of the Policy Map creators optional note, it
> would be truly unique. The Policy Map and/or PBKDF are small and could
> easily added to existing APIs.
>
> So for legacy hardware, we can use existing 48' subtree, but 3' as the
> format for this form (2' is segwit), then the desktop can just ask for the
> /48'/0'/0'/3'/PBKDF' when it requests a new xpub from the hardware token.
> More sophisticated Airgapped apps you can send
> "wsh(sortedmulti(1,,,))"+label and let the cosigner app do the PBKDF, and
> optionally allow it return something different in a full keyset (i.e.
> "[90081696/48'/0'/0'/3'/af3948cg…'/]xpub6DYLEk…", and then the requesting
> app, knowing that it is different from the PBKDF can know what to do if it
> needs to what to ask for in the future.
>
> The other advantage of this technique is that the cosigner app can know
> what policy it is participating in, before the descriptor is completed. It
> may decide it doesn't want to participate in some funky 4:9 with a weird
> script, and not return an xpub at all.
>
> Long term I think a commitment scheme should be used, so that you don't
> reveal what xpub you offered until all the parties xpubs are shared, but as
> Pieter said, we can do that at the same time we do the musig. But we need
> to prevent xpub reuse NOW, and I think my proposal easy and could the job.
>
> -- Christopher Allen, Blockchain Commons
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20210212/cce516d7/attachment-0001.sig>

2023-06-07 18:23:23

- reply

📅 Original date posted:2020-03-20
📝 Original message:I like this proposal and I see it's value: "One seed to rule them all."
Not hard to implement either.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
On Fri, Mar 20, 2020 at 03:44:01PM +0000, Ethan Kosakovsky wrote:
> I would like to present a proposal for discussion and peer review. It aims to solve the problem of "too many seeds and too many backups" due to the many reasons stipulated in the proposal text.
>
> https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-from-bip32.mediawiki
>
> <pre>
> BIP:
> Title: Deterministic Entropy From BIP32 Keychains
> Author: Ethan Kosakovsky <ethankosakovsky at protonmail.com>
> Comments-Summary: No comments yet.
> Comments-URI:
> Status: Proposed
> Type: Standards Track
> Created: 2020-03-20
> License: BSD-2-Clause
> OPL
> </pre>
>
> ==Abstract==
>
> This proposal provides a way to derive entropy from a HD keychain path in order to deterministically derive the initial entropy used to create keychain mnemonics and seeds.
>
...
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200320/4e6f725f/attachment.sig>

2023-06-07 18:22:23

- reply

📅 Original date posted:2020-01-13
📝 Original message:> In your proposal, it is the Signer who adds the signature, so it
> will receive a PSBT without auth sigs and thus that could be mutated to
> trigger those bugs anyways.
The Signer may be signing a PSBT that was corrupted by the MitM,
but at least later users of the signed PSBT can detect that occured.
At present, they do not know what the input PSBT content was when
it got to the Signer.
> ... The Combiner still has to deserialize the PSBT to get the signature, then it
> needs to re-serialize the PSBT to check that signature.
If we use a fixed-width signature, such as just R+S bytes (64 bytes),
and not DER-encoding, then the signature is a fixed distance from
the last byte of the file. A conservative PSBT parser could start
by verifying the signature exists and is valid, before parsing the
rest of the file. (It would need to use the pubkeys from the original
PSBT, which it would ideally have on-hand already to verify the source
PSBT to the Coldcard.)
> For Finalizers, since its job is to construct the final
> scriptSig/scriptWitness, at worst, all it can do is produce an invalid
> transaction. Finalizers don't have access to the private keys so there's
> no bug possible that can result in a Finalizer producing a transaction
> that reveals the private key.
I agree that Finalizers cannot access the Bitcoin private keys, but
they still have stacks that can overflow, buffers that can be overrun
and so on. Perhaps if sighash is not SIGHASH_ALL, there are dangerous
things they can be tricked into... I don't know, but at least we
should make it possible to detect these cases. My goal is detection.
> ISTM the same is true of your proposal. You need to deserialize the PSBT
> and then figure out which fields were "original" and in what order. If
> there is a bug in your deserialization, an attacker can still exploit
> that. And if there is a bug in your reconstruction of "original", you'll
> have false positives.
No, I am not proposing anyone re-construct PSBT's... My proposal
is really only helpful if you have the full original PSBT on hand
(or its digest). For ultimate safety I would recommend checking the
incoming PSBT's signature is valid before parsing it.(If the
signature is fixed-length, see above.)
> My point was that you can achieve your MiTM protection by having the
> signature separate from the PSBT. You can still make your ECDSA
> signature and send it along with the PSBT, and you can do it with fixed
> or exchanged keys, no need for parsing the PSBT itself. It can be part
> of the transport protocol, not part of the data that is being transferred.
In the USB protocol between Coldcard and desktop, we do end-to-end
encryption with a session key picked via diff-hel so we're doing
our best there against MitM. However, our customers love the air-gap
feature which involves lots of sneakernet handling of MicroSD cards.
I don't want to force them into handling paired files, like detacted
signatures, and I was hoping this would be a good way to move the
signatures inside the PSBT files already being moved about.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
On Mon, Jan 13, 2020 at 05:05:10PM +0000, Andrew Chow wrote:
>
> On 1/13/20 9:28 AM, Peter D. Gray wrote:
> > I don't have a specific attack in mind, but these signatures, if
> > adopted by the community at large, will allow detection of-, and
> > could mitigate damage from-, some broad "bug-classes".
> >
> > Consider if the PSBT Signer (hardware wallet) has bugs. Perhaps if
> > you tweak the PSBT in some unnatural way it produces output that
> > reveals the private key (duplicate k-value perhaps), or corrupts
> > the display of the transaction in helpful (to the attacker) ways
> > (typically case: output hidden as change).
>
> Since the PSBT is to be signed by one of the Signers for the PSBT, I
> don't see how this is useful. If it is mutated and the signer has bugs,
> especially parsing bugs, the Signer also adding its signature won't
> help. In your proposal, it is the Signer who adds the signature, so it
> will receive a PSBT without auth sigs and thus that could be mutated to
> trigger those bugs anyways.
>
> > There could also be bugs in the Combiner/Finalizer which the MiTM
> > wants to trigger. Legimate files, signed by the PSBT Signer, will not
> > contain those attacks, so are "safer" to process, even if your
> > Combiner's PSBT parser has bugs or is tragically dumb.
>
> The job of Combiners is fairly limited and is really just related to
> parsing the PSBT into some internal object then shuffling those fields
> around. In that case, any bugs an attacker would want to exploit have to
> be deserialization bugs, in which case, your auth sigs don't help. The
> Combiner still has to deserialize the PSBT to get the signature, then it
> needs to re-serialize the PSBT to check that signature. An attacker
> could insert bad bytes into the PSBT which causes problems during
> deserialization, before the Combiner is able to check the signature.
>
> For Finalizers, since its job is to construct the final
> scriptSig/scriptWitness, at worst, all it can do is produce an invalid
> transaction. Finalizers don't have access to the private keys so there's
> no bug possible that can result in a Finalizer producing a transaction
> that reveals the private key.
>
> >
> > That's just it, when we receive a signed PSBT, at present we don't
> > know *what* was signed without a complete understanding of the
> > transaction, the input UTXO (at least syntactially), and PSBT file
> > contents. If there are bugs in that understanding (ie. checks we
> > all know are needed, but no-one actually implemented) then we might
> > transmit an harmful transaction, or continue to process a file
> > that has been corrupted-with-intent by a MiTM.
>
> ISTM the same is true of your proposal. You need to deserialize the PSBT
> and then figure out which fields were "original" and in what order. If
> there is a bug in your deserialization, an attacker can still exploit
> that. And if there is a bug in your reconstruction of "original", you'll
> have false positives.
>
> > It's fine to say that, but in an embedded environment, with very
> > limited memory like the Coldcard, PGP isn't an option (signing vs.
> > signature verification). I want to leverage the existing crypto and
> > PKI that we already have in play.
>
> My point was that you can achieve your MiTM protection by having the
> signature separate from the PSBT. You can still make your ECDSA
> signature and send it along with the PSBT, and you can do it with fixed
> or exchanged keys, no need for parsing the PSBT itself. It can be part
> of the transport protocol, not part of the data that is being transferred.
>
> Andrew
>
> >
> >> On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:
> > ... [many valid points, repeated by Andrew] ...
> >>> If there is MitM, checking something at Finalizer is likely too
> >>> late - the party that can intercept PSBTs can finalize before the
> >>> legitimate Finalizer and broadcast the transaction.
> >
> > Yes, that is a problem which is proposal does not address. If the
> > MitM has control over both directions, in and out, then whatever
> > he or she was trying to do will still happen. Personally, I'm okay
> > with that as a limition, but using the same signatures features,
> > and a pre-shared public key between the PSBT Creator and the Signer,
> > we could block the Signer from looking at MitM'ed files. (The Signer
> > would require and verify incoming unsigned PSBT to contain the
> > last-output-section-signature thing.) I'm not planning on supporting
> > that on the Coldcard (at least not yet), but with the proposed
> > additions, it is possible to do without further changes to the PSBT
> > spec.
> >
> >>> Participants can work from the same PSBT ...
> >>> either pass two files (original and updated), or work out which fields
> >>> (key-value blobs) to remove to get the 'source' PSBT (which might not be
> >>> trivial with presense of proprietary and unknown fields). Even if you
> >>> know which key-value pairs to remove, there is no requirement for
> >>> ordering of the fields, and some signer can serialize them in different
> >>> order after dserialize/sign/add-signatures/re-serialize operation.
> > ...
> >>> Introducing additional ordering or other structure requirements over
> >>> simple key-value structure will add complexity to PSBT processing, and
> >>> adding complexity on such a basic level should have really serious
> >>> reasons, because that increases effort required for even basic
> >>> implementations and increases chance of bugs.
> >
> > I want these signatures to protect against PSBT parsing bugs. That's
> > why they are byte-level on the whole file contents, and not based
> > on sub-sections of the file or various fields inside the file. Yes,
> > there are non-linear PSBT paths that will be difficult or impossible
> > to support with this approach. I would not expect implementations to
> > do anything fancy to reconstruct PSBT contents, I think they would
> > just track the complete file. In most setups today the Creator,
> > Combiner and Finalizer are the same device, and they are desktop
> > systems with gigs of memory.
> >
> >>> If there is some authority on the 'correctness' of 'original' PSBT
> >>> (all particpants receive same PSBT at the start), particpants should
> >>> check the signature by that authority. That authority might use
> >>> the key used only for authentication, and not in the tx signing.
> >
> > Yes, this can be acheived by pre-sharing a public key with the
> > Signer (described above). Only signed incoming PSBT's would be
> > accepted. That key doesn't have anything to do with the blockchain
> > or value transfer.
> >
> >>> I think you do not need to wait for officially-assigned key numbers,
> >>> and can just implement the scheme you envision with proprietary keys,
> >>> document and promote it. Then if it shows its usefulness, it will
> >>> either become de-facto standard with your proprietary keys...
> >
> > Yes, 100% ... but I value the list's feedback, and I would prefer to
> > start with a legitimate key number which I don't need to change later. It's
> > a non-breaking change and I wouldn't propose it otherwise.
> >
> > ---
> > Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
> >
> > On Mon, Jan 13, 2020 at 06:39:28AM +0000, Andrew Chow wrote:
> >> I agree with Dimitry. I don't see the point of having the MiTM
> >> protection within the PSBT structure itself, in addition to the fact
> >> that adding new fields is largely unnecessary. In fact, I'm not quite
> >> sure what kind of attack you are trying to defend against with this
> >> proposal.
> >>
> >> If there is a MiTM who can modify your PSBT, then they can just modify
> >> the result the signed PSBT to drop the auth signatures. Furthermore, any
> >> modifications to scripts or UTXOs would just result in an invalid
> >> signature, so only time is wasted. But you'll just waste time anyways
> >> when you see a failed auth sig.
> >>
> >> Additionally, when a signer processes a PSBT, it will either accept the
> >> PSBT and add a signature for its inputs, or reject it and do nothing.
> >> Given this behavior (and I assume you aren't going to add auth sigs for
> >> rejected PSBTs because that doesn't make any sense), then you already
> >> have a signature there that covers everything your auth signature would
> >> cover. So just verify those signatures instead; for any inputs with
> >> signatures, everything you need to verify them are already there.
> >>
> >> Lastly, IMO, if you want MiTM protection, then you should do your
> >> protection with out of band communication. Just PGP sign the PSBT (or
> >> something similar) and send the signature along separately.
> >>
> >> Andrew
> >>
> >> On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:
> >>>
> >>> I am not sure that this particular task should be done with data
> >>> embedded in PSBT itself, and not with some sort of container that
> >>> includes PSBT and the authentication information.
> >>>
> >>> The benefit seems to be in reusing PSBT structure for compatibilty, and
> >>> this might be a valid way, although I do not agree with some of your
> >>> points. I elaborate below:
> >>>
> >>>> 1) In the PSBT globals section, a signature over the "source" PSBT
> >>>> file. It would cover all the bytes of the original PSBT file, as
> >>>> it was received by the Signer.
> >>>
> >>> The problem of authenticating the contents of PSBT is independent of
> >>> the signing action. PSBT might be altered on the path from Creator to
> >>> Signer. Therefore you cannot always say that Signer will be an
> >>> authority over 'correctness' of PSBT.
> >>>
> >>>> - At the end of the signing process, the Finalizer should check all
> >>>> the Signers have worked from the same PSBT file (assuming that's
> >>>> the flow expected)
> >>>
> >>> If there is MitM, checking something at Finalizer is likely too
> >>> late - the party that can intercept PSBTs can finalize before the
> >>> legitimate Finalizer and broadcast the transaction.
> >>>
> >>> Participants can work from the same PSBT file if they all receive the
> >>> same PSBT, and not working in chain where next particpant receives
> >>> updated PSBT from the previous participant. Otherwise they will need to
> >>> either pass two files (original and updated), or work out which fields
> >>> (key-value blobs) to remove to get the 'source' PSBT (which might not be
> >>> trivial with presense of proprietary and unknown fields). Even if you
> >>> know which key-value pairs to remove, there is no requirement for
> >>> ordering of the fields, and some signer can serialize them in different
> >>> order after dserialize/sign/add-signatures/re-serialize operation.
> >>>
> >>> Introducing additional ordering or other structure requirements over
> >>> simple key-value structure will add complexity to PSBT processing, and
> >>> adding complexity on such a basic level should have really serious
> >>> reasons, because that increases effort required for even basic
> >>> implementations and increases chance of bugs.
> >>>
> >>> If there is some authority on the 'correctness' of 'original' PSBT
> >>> (all particpants receive same PSBT at the start), particpants should
> >>> check the signature by that authority. That authority might use
> >>> the key used only for authentication, and not in the tx signing.
> >>>
> >>> If particpants send PSBT in chain after adding their signatures, then
> >>> each participant can add their signature to say 'the contents
> >>> of PSBT after my updates should match this hash'.
> >>>
> >>> The signatures of previous participants in the chain most likely do not
> >>> matter because of difficulty of restoring the contents of PSBT as it
> >>> was before the previous particpant, if you do not pass _all_ the PSBTs
> >>> (which is excessive).
> >>>
> >>>> 2) In the output section, specifically, the last key/value pair of
> >>>> the last output of the transaction, I want to add a similar signature,
> >>>> again signed by one of the keys used in the signing process. This
> >>>> signature will cover all the bytes of the resulting (signed) PSBT
> >>>> up to that point. Because it is the last output of the output
> >>>> section, that signature will be the last few bytes of the PSBT file.
> >>>> By "appending" the signature in this way, it's easier to validate
> >>>> and create the signature, without blanking the signature area during
> >>>> digest step.
> >>>
> >>> This will introduce unnecessary higher-level structure to PSBT for the
> >>> reasons that I do not find strong enough for the amount of complexity
> >>> added.
> >>>
> >>> Also, as I said above, you likely do not need more than one
> >>> signature - if this is 'fan-out' scheme, then participants need do
> >>> check the sig of authority that created PSBT; if this is piggy-back
> >>> chain, then only previous particpant's signature is easily verifiable.
> >>>
> >>>> ## Next Steps
> >>>>
> >>>> I'd like to get two officially-assigned BIP-174 key numbers assigned
> >>>> for these two signatures, and then I will see that it gets added
> >>>> into Coldcard's firmware immediately. In time, other tools are
> >>>> welcome to take advantage of these checks. I will also write a BIP
> >>>> for this, and/or make an addition to BIP-174.
> >>>
> >>> I think you do not need to wait for officially-assigned key numbers,
> >>> and can just implement the scheme you envision with proprietary keys,
> >>> document and promote it. Then if it shows its usefulness, it will
> >>> either become de-facto standard with your proprietary keys (and
> >>> everyone will want to support 'Coldard PSBT auth' or whatever the name),
> >>> or the scheme will have serious grounds to be converted to standard and
> >>> have non-proprietary keys assigned.
> >>>
> >>> // Dmitry.
> >>> _______________________________________________
> >>> bitcoin-dev mailing list
> >>> bitcoin-dev at lists.linuxfoundation.org
> >>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >>>
>

2023-06-07 18:22:22

- reply

📅 Original date posted:2020-01-13
📝 Original message:Thanks for the useful comments guys. I understand where you are
coming from, but my PoV is from the deep embedded side.
On Mon, Jan 13, 2020 at 06:39:28AM +0000, Andrew Chow wrote:
> ... In fact, I'm not quite
> sure what kind of attack you are trying to defend against with this
> proposal.
I don't have a specific attack in mind, but these signatures, if
adopted by the community at large, will allow detection of-, and
could mitigate damage from-, some broad "bug-classes".
Consider if the PSBT Signer (hardware wallet) has bugs. Perhaps if
you tweak the PSBT in some unnatural way it produces output that
reveals the private key (duplicate k-value perhaps), or corrupts
the display of the transaction in helpful (to the attacker) ways
(typically case: output hidden as change).
Seeing a corrupted file signature would alert you of the attempt
to do this. So maybe you don't transmit the transaction, maybe you
warn the user and so on. What happens next is up to you, but at
least we know something is happening.
There could also be bugs in the Combiner/Finalizer which the MiTM
wants to trigger. Legimate files, signed by the PSBT Signer, will not
contain those attacks, so are "safer" to process, even if your
Combiner's PSBT parser has bugs or is tragically dumb.
It's just another layer of security and confidence, on top of the
existing system-level security (which is already excellent).
> If there is a MiTM who can modify your PSBT, then they can just modify
> the result the signed PSBT to drop the auth signatures.
Yes, the MiTM can remove the signatures. However, if your tools expect
and require the signatures in place, then the feature is working
as intended, because the user will be alerted to the funny-business.
More importantly: nothing has been lost by implementing the feature,
and Coldcard (and other PSBT Signers) have to be first to implement it.
> ... then you already
> have a signature there that covers everything your auth signature would
> cover. So just verify those signatures instead; for any inputs with
That's just it, when we receive a signed PSBT, at present we don't
know *what* was signed without a complete understanding of the
transaction, the input UTXO (at least syntactially), and PSBT file
contents. If there are bugs in that understanding (ie. checks we
all know are needed, but no-one actually implemented) then we might
transmit an harmful transaction, or continue to process a file
that has been corrupted-with-intent by a MiTM.
> Lastly, IMO, if you want MiTM protection, then you should do your
> protection with out of band communication. Just PGP sign the PSBT (or
> something similar) and send the signature along separately.
It's fine to say that, but in an embedded environment, with very
limited memory like the Coldcard, PGP isn't an option (signing vs.
signature verification). I want to leverage the existing crypto and
PKI that we already have in play.
> On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:
... [many valid points, repeated by Andrew] ...
> > If there is MitM, checking something at Finalizer is likely too
> > late - the party that can intercept PSBTs can finalize before the
> > legitimate Finalizer and broadcast the transaction.
Yes, that is a problem which is proposal does not address. If the
MitM has control over both directions, in and out, then whatever
he or she was trying to do will still happen. Personally, I'm okay
with that as a limition, but using the same signatures features,
and a pre-shared public key between the PSBT Creator and the Signer,
we could block the Signer from looking at MitM'ed files. (The Signer
would require and verify incoming unsigned PSBT to contain the
last-output-section-signature thing.) I'm not planning on supporting
that on the Coldcard (at least not yet), but with the proposed
additions, it is possible to do without further changes to the PSBT
spec.
> > Participants can work from the same PSBT ...
> > either pass two files (original and updated), or work out which fields
> > (key-value blobs) to remove to get the 'source' PSBT (which might not be
> > trivial with presense of proprietary and unknown fields). Even if you
> > know which key-value pairs to remove, there is no requirement for
> > ordering of the fields, and some signer can serialize them in different
> > order after dserialize/sign/add-signatures/re-serialize operation.
...
> > Introducing additional ordering or other structure requirements over
> > simple key-value structure will add complexity to PSBT processing, and
> > adding complexity on such a basic level should have really serious
> > reasons, because that increases effort required for even basic
> > implementations and increases chance of bugs.
I want these signatures to protect against PSBT parsing bugs. That's
why they are byte-level on the whole file contents, and not based
on sub-sections of the file or various fields inside the file. Yes,
there are non-linear PSBT paths that will be difficult or impossible
to support with this approach. I would not expect implementations to
do anything fancy to reconstruct PSBT contents, I think they would
just track the complete file. In most setups today the Creator,
Combiner and Finalizer are the same device, and they are desktop
systems with gigs of memory.
> > If there is some authority on the 'correctness' of 'original' PSBT
> > (all particpants receive same PSBT at the start), particpants should
> > check the signature by that authority. That authority might use
> > the key used only for authentication, and not in the tx signing.
Yes, this can be acheived by pre-sharing a public key with the
Signer (described above). Only signed incoming PSBT's would be
accepted. That key doesn't have anything to do with the blockchain
or value transfer.
> > I think you do not need to wait for officially-assigned key numbers,
> > and can just implement the scheme you envision with proprietary keys,
> > document and promote it. Then if it shows its usefulness, it will
> > either become de-facto standard with your proprietary keys...
Yes, 100% ... but I value the list's feedback, and I would prefer to
start with a legitimate key number which I don't need to change later. It's
a non-breaking change and I wouldn't propose it otherwise.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
On Mon, Jan 13, 2020 at 06:39:28AM +0000, Andrew Chow wrote:
> I agree with Dimitry. I don't see the point of having the MiTM
> protection within the PSBT structure itself, in addition to the fact
> that adding new fields is largely unnecessary. In fact, I'm not quite
> sure what kind of attack you are trying to defend against with this
> proposal.
>
> If there is a MiTM who can modify your PSBT, then they can just modify
> the result the signed PSBT to drop the auth signatures. Furthermore, any
> modifications to scripts or UTXOs would just result in an invalid
> signature, so only time is wasted. But you'll just waste time anyways
> when you see a failed auth sig.
>
> Additionally, when a signer processes a PSBT, it will either accept the
> PSBT and add a signature for its inputs, or reject it and do nothing.
> Given this behavior (and I assume you aren't going to add auth sigs for
> rejected PSBTs because that doesn't make any sense), then you already
> have a signature there that covers everything your auth signature would
> cover. So just verify those signatures instead; for any inputs with
> signatures, everything you need to verify them are already there.
>
> Lastly, IMO, if you want MiTM protection, then you should do your
> protection with out of band communication. Just PGP sign the PSBT (or
> something similar) and send the signature along separately.
>
> Andrew
>
> On 1/11/20 3:17 PM, Dmitry Petukhov via bitcoin-dev wrote:
> >
> > I am not sure that this particular task should be done with data
> > embedded in PSBT itself, and not with some sort of container that
> > includes PSBT and the authentication information.
> >
> > The benefit seems to be in reusing PSBT structure for compatibilty, and
> > this might be a valid way, although I do not agree with some of your
> > points. I elaborate below:
> >
> >> 1) In the PSBT globals section, a signature over the "source" PSBT
> >> file. It would cover all the bytes of the original PSBT file, as
> >> it was received by the Signer.
> >
> > The problem of authenticating the contents of PSBT is independent of
> > the signing action. PSBT might be altered on the path from Creator to
> > Signer. Therefore you cannot always say that Signer will be an
> > authority over 'correctness' of PSBT.
> >
> >> - At the end of the signing process, the Finalizer should check all
> >> the Signers have worked from the same PSBT file (assuming that's
> >> the flow expected)
> >
> > If there is MitM, checking something at Finalizer is likely too
> > late - the party that can intercept PSBTs can finalize before the
> > legitimate Finalizer and broadcast the transaction.
> >
> > Participants can work from the same PSBT file if they all receive the
> > same PSBT, and not working in chain where next particpant receives
> > updated PSBT from the previous participant. Otherwise they will need to
> > either pass two files (original and updated), or work out which fields
> > (key-value blobs) to remove to get the 'source' PSBT (which might not be
> > trivial with presense of proprietary and unknown fields). Even if you
> > know which key-value pairs to remove, there is no requirement for
> > ordering of the fields, and some signer can serialize them in different
> > order after dserialize/sign/add-signatures/re-serialize operation.
> >
> > Introducing additional ordering or other structure requirements over
> > simple key-value structure will add complexity to PSBT processing, and
> > adding complexity on such a basic level should have really serious
> > reasons, because that increases effort required for even basic
> > implementations and increases chance of bugs.
> >
> > If there is some authority on the 'correctness' of 'original' PSBT
> > (all particpants receive same PSBT at the start), particpants should
> > check the signature by that authority. That authority might use
> > the key used only for authentication, and not in the tx signing.
> >
> > If particpants send PSBT in chain after adding their signatures, then
> > each participant can add their signature to say 'the contents
> > of PSBT after my updates should match this hash'.
> >
> > The signatures of previous participants in the chain most likely do not
> > matter because of difficulty of restoring the contents of PSBT as it
> > was before the previous particpant, if you do not pass _all_ the PSBTs
> > (which is excessive).
> >
> >> 2) In the output section, specifically, the last key/value pair of
> >> the last output of the transaction, I want to add a similar signature,
> >> again signed by one of the keys used in the signing process. This
> >> signature will cover all the bytes of the resulting (signed) PSBT
> >> up to that point. Because it is the last output of the output
> >> section, that signature will be the last few bytes of the PSBT file.
> >> By "appending" the signature in this way, it's easier to validate
> >> and create the signature, without blanking the signature area during
> >> digest step.
> >
> > This will introduce unnecessary higher-level structure to PSBT for the
> > reasons that I do not find strong enough for the amount of complexity
> > added.
> >
> > Also, as I said above, you likely do not need more than one
> > signature - if this is 'fan-out' scheme, then participants need do
> > check the sig of authority that created PSBT; if this is piggy-back
> > chain, then only previous particpant's signature is easily verifiable.
> >
> >> ## Next Steps
> >>
> >> I'd like to get two officially-assigned BIP-174 key numbers assigned
> >> for these two signatures, and then I will see that it gets added
> >> into Coldcard's firmware immediately. In time, other tools are
> >> welcome to take advantage of these checks. I will also write a BIP
> >> for this, and/or make an addition to BIP-174.
> >
> > I think you do not need to wait for officially-assigned key numbers,
> > and can just implement the scheme you envision with proprietary keys,
> > document and promote it. Then if it shows its usefulness, it will
> > either become de-facto standard with your proprietary keys (and
> > everyone will want to support 'Coldard PSBT auth' or whatever the name),
> > or the scheme will have serious grounds to be converted to standard and
> > have non-proprietary keys assigned.
> >
> > // Dmitry.
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200113/2ad4e27c/attachment-0001.sig>

2023-06-07 18:22:20

- reply

📅 Original date posted:2020-01-11
📝 Original message:## Background
PSBT files in transit are at risk of MiTM changes. This isn't
supposed to matter, but as another layer of defence, I would like
to add two signatures to PSBT files when they are processed by the
PSBT Signer. These additional fields would be optional, and should
pass through existing PSBT processors transparently, assuming they
pass unknown key/values as BIP-174 specifies.
## Additional Key/Values
1) In the PSBT globals section, a signature over the "source" PSBT
file. It would cover all the bytes of the original PSBT file, as
it was received by the Signer. The key used for the signature may
be any one the keys that the Signer applied during its transaction
signing process. (This is flexible so that the Signer can make the
signature at any point in the signing process. On the Coldcard, we
would probably use the first key that we used for signing, so the
first key involved in the first input.)
The "key" of the global value will be pubkey value of the key which
was selected by the Signer. If its BIP32 derivation is needed for
some reason, that is documented in the input section already.
The "value" will be 65(?) bytes of a standard Bitcoin signature.
The digest (hash) of the source PSBT is not provided, so any tool
that wants to verify this signature will need to have a copy of the
original PSBT. (I see that as a critical feature, not a limitation).
2) In the output section, specifically, the last key/value pair of
the last output of the transaction, I want to add a similar signature,
again signed by one of the keys used in the signing process. This
signature will cover all the bytes of the resulting (signed) PSBT
up to that point. Because it is the last output of the output
section, that signature will be the last few bytes of the PSBT file.
By "appending" the signature in this way, it's easier to validate
and create the signature, without blanking the signature area during
digest step.
## Role-Based View
The above additions can only be made by a PSBT processor in the Signer
role. No-one else has the keys needed. As for the other PSBT roles:
- Any tool that reads in a PSBT and finds a signature in the final output
section can and should verify it:
- check signature over a digest of the PSBT file up to the last X bytes
- file must end at that point, with only the signature following it
- also check the key used for signature is one of the input's keys
- PSBT processors in the "combining" role, should preserve the
signatures in the global section, accumulating them into the next
PSBT. (Of course they should validate them, if they have the original
PSBT on hand as well, but that's optional and could be done later
in the flow.) The Combiner should always check a signed PSBT was
not modified in transit via the signature in the final output
section, and then strip it out of the combined PSBT.
- At the end of the signing process, the Finalizer should check all
the Signers have worked from the same PSBT file (assuming that's
the flow expected), or the appropriate PSBT if it's a more complex
case. If the Finalizer is working on a file directly from a Signer,
then it can verify the signature in the output section as well.
## Open Questions
For the message digest, I propose simple SHA256(SHA256(bytes of PSBT)).
I'm not sure of the best way to serialize the signature, but to be
consistent with the rest of the file, it should probably be DER-encoded
and variable length.
## Next Steps
I'd like to get two officially-assigned BIP-174 key numbers assigned
for these two signatures, and then I will see that it gets added
into Coldcard's firmware immediately. In time, other tools are
welcome to take advantage of these checks. I will also write a BIP
for this, and/or make an addition to BIP-174.
I think with these changes, and assuming all the tools are verifying
properly, we can shutdown undetectable MiTM changes to PSBT contents.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 529 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200111/51fab912/attachment.sig>

2023-06-07 18:18:48

- reply

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

2023-06-07 18:18:48

- reply

📅 Original date posted:2019-06-28
📝 Original message: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.
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.
3) XPUB's are big and hard to parse, and this addition is using lots of them.
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.
To fix, may I propose:
- 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

2023-06-07 18:17:52

- reply

📅 Original date posted:2019-05-03
📝 Original message:On Fri, Apr 26, 2019 at 05:21:06PM +0200, Stepan Snigirev wrote:
...
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned
Writing the multisig support for Coldcard, I've come to the same conclusion. I've
exchanged some helpful mail with Andrew Chow on this subject.
...
> I suggest to add the following key-value pairs to PSBT:
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
...
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
I'd rather see the xpubs shared in the global section of the file,
with the restriction that they must/should only include the hardened
prefix of the path. The existing bip32 derivation path included in
individual inputs and outputs be merged in as needed.
After all in a typical PSBT, we would expect the same master keys
to be used on all inputs, and at least one output, and there might
be as many as 20 co-signers. No need to repeat all that information.
Even with this additions to the PSBT format, I think PSBT-signing
devices still need to store the xpubs of their co-signers. It's not
possible to safely show an incoming address to the user without a
full understanding of the other keys in a "multisig wallet". Also,
it represents data that should not change between PSBT instances
(ie. tomorrow's co-signers should match today's).
Having said that, the xpubs in the PSBT would allow a "trust on first
use" which I think can be a good feature.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
> Hi list,
>
> I was looking at the bip174 PSBT specs, in particular for multisignature
> setup, and I think with current spec there is a way to steal user funds in
> M of N setup with M ≤ N/2.
>
> I made a small write-up on this:
> https://github.com/stepansnigirev/random_notes/blob/master/psbt_multisig.md
>
> To compress:
>
> Currently in PSBT there is no way to reliably say if the output uses the
> keys derived from the same root keys as the inputs aside from the key owned
> by the signer => there is no way to verify that the output is a change
> output in multisig setup.
>
> Therefore an attacker can replace half of the keys in the change address by
> his own keys and still get the transaction signed.
>
> I suggest to add an xpub field to the inputs and outputs metadata, then
> signers can verify that the same xpubs are used for public keys in inputs
> and outputs => output is indeed a change.
>
> Normally change and receiving addresses are derived from the same xpub with
> non-hardened derivation pathes, so providing xpub after the last hardened
> index should be enough to see that public keys of inputs and change output
> are derived from the same xpub.
>
> I suggest to add the following key-value pairs to PSBT:
>
> Type: BIP 32 public key `PSBT_IN_BIP32_XPUB = 0x10`
> - Key: derivation path for xpub
> `{0x10}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
> `{xpub}`
>
> Type: BIP 32 public key `PSBT_OUT_BIP32_XPUB = 0x03`
> - Key: derivation path for xpub
> `{0x03}|{master key fingerprint}|{32-bit int}|...|{32-bit int}`
> - Value: 78-byte xpub value
> `{xpub}`
>
> Derivation paths are in the key of the key-value pair as they are used for
> lookup, and xpub itself is the actual value being looked up.
>
> I also want to mention that Trezor for example doesn't suffer from this
> problem as they use xpubs to verify change outputs. So it may make sense to
> go through the communication protocols of existing hardware /
> multisignature wallets and see if there is something else we are missing.
>
> If everyone is happy about the proposal I would prepare a pull request to
> the bip.
>
> Best regards,
> Stepan Snigirev.

2023-06-07 18:13:15

- reply

📅 Original date posted:2018-06-29
📝 Original message:...
> I believe that this discussion has become bikeshedding and is really no longer constructive.
...
Thanks for saying this Andrew! I agree with your point of view, and personally I'm ready to lock this BIP down ... or at least move it to the next level of approval.
...
> I propose to move the BIP from Draft to Proposed status.
Yes please, all praise the BIP gods!
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10

2023-06-07 18:13:11

- reply

📅 Original date posted:2018-06-23
📝 Original message:On Fri, Jun 22, 2018 at 06:28:33PM -0400, Achow101 wrote:
> After reading the comments here about BIP 174, I would like to propose the following changes:
>
> - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to per-input and per-output data
...
I like this. I agree it's making things easier and it's more flexible.
> - Finalized scriptSig and scriptWitness fields
>
> To determine whether two PSBTs are the same, we can compare the unsigned transaction. To ensure that the
> unsigned transactions are the same for two PSBTs with data for the same tx, we cannot put scriptSigs or
> scriptWitnesses into it. Thus for each input, two new fields have been added to store the finalized scriptSig
> and finalized scriptWitness.
...
To be honest, I don't understand the reasons/implications of this change, but it seems harmless.
> - Mandatory sighash
...
Good improvement.
> - Encoding
>
> I have decided that PSBTs should either be in binary or encoded as a Base64 string. For the latter, several
> Bitcoin clients already support Base64 encoding of data (for signed messages) so this will not add any extra
> dependencies like Z85 would.
...
Personally, I don't think you should spec an encoding. It should be binary only and hex for developers and JSON interfaces. My thinking is that PSBT's are not user-visible things. They have a short lifetime and are nothing something that is "stored" or referenced much later. Hex is good enough and has no downsides as an excoding except for density.
On the other hand, suggesting a filename extension (probably .PSBT?) and a mime-type to match, are helpful since wallets and such will want to register with their operating systems to become handlers of those mimetypes. Really that's a lot more important for interoperability at this point, than an encoding.
> A draft of the revised BIP can be found here: https://github.com/achow101/bips/blob/bip174-rev/bip-0174.mediawiki
> If these changes are satisfactory, I will open a PR to the BIPs repo to update the BIP tomorrow. I will also
> create test vectors and update the implementation PR'ed to Core.
...
Looking forward to test vectors, and I might have more to say once my code can handle them (again).
Feedback on the BIP as it stands now:
- Appendix A needs an update, and I suggest defining symbols (PK_PARTIAL_SIG == 0x02) for the numeric key values. This helps implementers as we don't all define our own symbols and/or use numeric constants in our code.
- Those tables are just not working. Might want to reformat as descriptive lists, point form, or generally anything else... sorry.
> Andrew
> _______________________________________________
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180623/9c0b1846/attachment.sig>

2023-06-07 18:13:08

- reply

📅 Original date posted:2018-06-21
📝 Original message:On Thu, Jun 21, 2018 at 04:32:07PM +0200, Tomas Susanka wrote:
...
> First of all, let me thank you for all the hard work you and others have
> put into this.
>
> On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote:
> > While I agree that the BIP itself should be revised to reflect these suggestions, I fear that it may be too late. I know of a few other developers who have implemented BIP 174 already but have not yet responded to this email.
>
> We do realize that this discussion should have happened earlier, however
> agreeing on a good standard should be the number one priority for all
> the parties involved.
>
> The fact that someone already implemented this is indeed unfortunate,
> but I don't think we should lower our demands on the standard just
> because of a bad timing.
We all want a "good" standard but we have that already, IMHO.
What you are really saying is you want a "better" standard, and I
would argue that's our enemy right now. It's just too easy to propose a
few tweaks, with "wouldn't it be better if..."
I feel strongly we are entering the "design by committee" territory with BIP174.
I have personally implemented this spec on an embedded micro, as
the signer and finalizer roles, and written multiple parsers for
it as well. There is nothing wrong with it, and it perfectly meets
my needs as a hardware wallet.
So, there is a good proposal already spec'ed and implemented by
multiple parties. Andrew has been very patiently shepherding the PR
for over six months already.
PSBT is something we need, and has been missing from the ecosystem
for a long time. Let's push this out and start talking about future
versions after we learn from this one.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180621/8d63430a/attachment.sig>

2023-06-07 18:13:04

- reply

📅 Original date posted:2018-06-21
📝 Original message:On Tue, Jun 19, 2018 at 05:20:34PM +0200, Jonas Schnelli wrote:
...
>
> I don’t see any reasons why space would be an issue.
>
> HWWs probably can’t handle PBST natively since it is not optimised for
> presenting various informations in a signing-verification.
The Coldcard hardware wallet is PSBT native and does work directly from PSBT.
> A single stream-in of a PSBT through USB (or similar channel) will not work in
> many cases since HWW come often with very restrictive RAM constraints.
For the Coldcard, we expect a PSBT to be 'uploaded' over USB (can
also be provided on MicroSD card) and we work in-place with it,
scanning over it a few different times. If the user approves the
transaction, we produce a signed PSBT or final transaction and that
gets downloaded.
We support 256k byte PSBT files with hundreds of inputs/outputs
(IIRC, and exact limits still TBD) and are operating in a system
with only 25k free RAM after startup.
> Furthermore, I forget to mention in my last mail, that registering (or defining)
> a mime-type for PSBT would probably a great usability feature.
> (Send PSBT by email/messanger and with dbl-click to open feature, etc.)
+1 for mimetype, especially since it's a binary format.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180621/be77e362/attachment.sig>

2023-06-07 18:13:02

- reply

📅 Original date posted:2018-06-16
📝 Original message:On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote:
...
> First of all, it's unclear to me to what extent projects have already
> worked on implementations, and thus to what extent the specification
> is still subject to change. A response of "this is way too late" is
> perfectly fine.
...
The new Coldcard hardware wallet is based on PSBT (ie. BIP 174 as
published), and we consider it "PSBT Native". It can add signatures
to PSBT files delivered on MicroSD card and/or over USB, and is
able to finalize PSBT files for lots of simple cases. It already
works well against the existing BIP174 pull request.
I think the BIP174 spec is reasonable as it is, and should only be
changed in a forwards-compatible way from this point... but obviously
I'm biased.
As for your specific comments, I don't have strong feelings really.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 496 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180616/7ae9d1a2/attachment.sig>

2023-06-07 15:29:58

- reply

📅 Original date posted:2015-02-06
📝 Original message:I think the Bitcoin community needs a good person-to-person payment
protocol for BLE simply because Bluetooth LE is effectively
peer-to-peer. Unlike NFC or conventional Bluetooth, a $5 micro can
be either the master or slave and talk directly to other $5 micros
nearby.
[ASIDE... BLE is also the first wireless tech that Apple has allowed us free
access to. They have claimed all NFC/RFID connections for their own
"Pay" junk, and Bluetooth accessories are all locked down into their
"make for iphone" program which literally requires a letter from
your lawyer to enter. Of course Apple is just one vendor.]
Surely, as a community, we can make a rock-solid P2P protocol that
is resistant to spoofing and vandalism. I'm a big fan of putting
crypto to good use, and doing a slightly more complex protocol
involving EC signing of nonces sounds great.
My only change to the RedPhone based "commit protocol" proposed
previously, is I'd like the confirmation code to be a 6-digit decimal
number rather than words. Wordlists are good for Red phone's audio
application, but it's a lot easier to display a 6-digit code on
vending machines, small mobile screens, and printed receipts.
Just my two cents.
---
Peter D. Gray || Founder, Coinkite || Twitter: @dochex || GPG: A3A31BAD 5A2A5B10
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 514 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150206/8db62979/attachment.sig>