📅 Original date posted:2020-03-02
📝 Original message:+1 love that progress is being made on this. Excited to implement it once
it’s ready.
Would love if things like the incrementing number were included in the
standard as well.
Cheers! 🍻
On Fri, Feb 28, 2020 at 9:51 AM Marko via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Thanks for starting this initiative; it has been a long standing goal of
> mine to implement and release this protocol. Your blog post on the topic
> actually inspired me to pick up this work again a few months ago.
>
> Jonas Nick has implemented the protocol in the secp256k1 library for
> Schnorr sigs here: https://github.com/bitcoin-core/secp256k1/pull/590
>
> I have backported the same scheme to ECDSA in the secp256k1 library
> here, so it can be used also for current transactions:
>
> https://github.com/bitcoin-core/secp256k1/pull/669
>
> I also made proof of concepts for the BitBox02 hw wallet firmware and
> BitBoxApp wallet to verify that the protocol also works well in practice.
>
> The actual scheme used in those implementations is a generalized
> sign-to-contract scheme, where the final nonce is computed as `k' = k +
> H(k*G, n)` instead of `k'=k+n`, but otherwise it works mostly the same
> for the anti nonce covert channel protocol. I suggest to use this scheme
> in PSBT as well.
>
> > We can either use proprietary fields [4] or define key-value pairs and
> add
> > them to the BIP-174. Depends if anyone else is interested in using this
> > protocol or not.
>
> I'd definitely be interested in seeing widespread support for this, and
> standardizing it would help with that.
>
> With PSBT used with an air-gapped signer, there is increased danger in
> implementing the protocol wrongly by relying on the contents of the PSBT
> alone in the final verification step of a signature. The PSBT must be
> verified carefully against state stored by the host for the PSBT.
> Otherwise the signer can for example change or pre-fill the relevant
> NONCE fields and leak the private keys anyway. Is there a current best
> practice for how a PSBT can be identified by the host to store/retrieve
> the state?
>
> Are there other examples in PSBT where the host can't trust the contents
> of the PSBT the signer returns (except of course for the parts the user
> can verify themselves, like recipients, amounts, etc.)? In any case,
> guidelines or conventions on how to avoid the pitfalls would be good.
>
> Best, Marko
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200302/668d43e4/attachment.html>;
Dustin Dettmer [ARCHIVE] /
npub1x5…kqsqu
2023-06-07 18:23:09
in reply to nevent1q…zpqw
Author Public Key
npub1x54n25utwk7dzwzvk2v0aknptez5gxdwcyrxx2wgc0lnhgvwu72qmkqsquPublished at
2023-06-07 18:23:09Event JSON
{
"id": "617566f3300b5c30b013b399ff916cd78284eb15f7e46bb272e6133cf650fbc4",
"pubkey": "352b35538b75bcd1384cb298feda615e454419aec1066329c8c3ff3ba18ee794",
"created_at": 1686162189,
"kind": 1,
"tags": [
[
"e",
"ad59d63a6b7e856d84eaf1807902b36480de4abb0014248a3ea57a9df2b30a3a",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2020-03-02\n📝 Original message:+1 love that progress is being made on this. Excited to implement it once\nit’s ready.\n\nWould love if things like the incrementing number were included in the\nstandard as well.\n\nCheers! 🍻\n\nOn Fri, Feb 28, 2020 at 9:51 AM Marko via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Thanks for starting this initiative; it has been a long standing goal of\n\u003e mine to implement and release this protocol. Your blog post on the topic\n\u003e actually inspired me to pick up this work again a few months ago.\n\u003e\n\u003e Jonas Nick has implemented the protocol in the secp256k1 library for\n\u003e Schnorr sigs here: https://github.com/bitcoin-core/secp256k1/pull/590\n\u003e\n\u003e I have backported the same scheme to ECDSA in the secp256k1 library\n\u003e here, so it can be used also for current transactions:\n\u003e\n\u003e https://github.com/bitcoin-core/secp256k1/pull/669\n\u003e\n\u003e I also made proof of concepts for the BitBox02 hw wallet firmware and\n\u003e BitBoxApp wallet to verify that the protocol also works well in practice.\n\u003e\n\u003e The actual scheme used in those implementations is a generalized\n\u003e sign-to-contract scheme, where the final nonce is computed as `k' = k +\n\u003e H(k*G, n)` instead of `k'=k+n`, but otherwise it works mostly the same\n\u003e for the anti nonce covert channel protocol. I suggest to use this scheme\n\u003e in PSBT as well.\n\u003e\n\u003e \u003e We can either use proprietary fields [4] or define key-value pairs and\n\u003e add\n\u003e \u003e them to the BIP-174. Depends if anyone else is interested in using this\n\u003e \u003e protocol or not.\n\u003e\n\u003e I'd definitely be interested in seeing widespread support for this, and\n\u003e standardizing it would help with that.\n\u003e\n\u003e With PSBT used with an air-gapped signer, there is increased danger in\n\u003e implementing the protocol wrongly by relying on the contents of the PSBT\n\u003e alone in the final verification step of a signature. The PSBT must be\n\u003e verified carefully against state stored by the host for the PSBT.\n\u003e Otherwise the signer can for example change or pre-fill the relevant\n\u003e NONCE fields and leak the private keys anyway. Is there a current best\n\u003e practice for how a PSBT can be identified by the host to store/retrieve\n\u003e the state?\n\u003e\n\u003e Are there other examples in PSBT where the host can't trust the contents\n\u003e of the PSBT the signer returns (except of course for the parts the user\n\u003e can verify themselves, like recipients, amounts, etc.)? In any case,\n\u003e guidelines or conventions on how to avoid the pitfalls would be good.\n\u003e\n\u003e Best, Marko\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20200302/668d43e4/attachment.html\u003e",
"sig": "2d35b775883a96e0cf23986a8e735d0a108d67c0b27ec447ed7ef9655c85fddf0c1a46fc1ad91f2c0889021e8ec2dc013a84be881c215a6c0fc3449107ef05f8"
}