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