<div><div dir="auto">+1 love that progress is being made on this. Excited to implement it once it’s ready.</div></div><div dir="auto"><br></div><div dir="auto">Would love if things like the incrementing number were included in the standard as well.</div><div dir="auto"><br></div><div dir="auto">Cheers! 🍻</div><div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Feb 28, 2020 at 9:51 AM Marko via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks for starting this initiative; it has been a long standing goal of<br>
mine to implement and release this protocol. Your blog post on the topic<br>
actually inspired me to pick up this work again a few months ago.<br>
<br>
Jonas Nick has implemented the protocol in the secp256k1 library for<br>
Schnorr sigs here: <a href="https://github.com/bitcoin-core/secp256k1/pull/590" rel="noreferrer" target="_blank">https://github.com/bitcoin-core/secp256k1/pull/590</a><br>
<br>
I have backported the same scheme to ECDSA in the secp256k1 library<br>
here, so it can be used also for current transactions:<br>
<br>
<a href="https://github.com/bitcoin-core/secp256k1/pull/669" rel="noreferrer" target="_blank">https://github.com/bitcoin-core/secp256k1/pull/669</a><br>
<br>
I also made proof of concepts for the BitBox02 hw wallet firmware and<br>
BitBoxApp wallet to verify that the protocol also works well in practice.<br>
<br>
The actual scheme used in those implementations is a generalized<br>
sign-to-contract scheme, where the final nonce is computed as `k' = k +<br>
H(k*G, n)` instead of `k'=k+n`, but otherwise it works mostly the same<br>
for the anti nonce covert channel protocol. I suggest to use this scheme<br>
in PSBT as well.<br>
<br>
> We can either use proprietary fields [4] or define key-value pairs and add<br>
> them to the BIP-174. Depends if anyone else is interested in using this<br>
> protocol or not.<br>
<br>
I'd definitely be interested in seeing widespread support for this, and<br>
standardizing it would help with that.<br>
<br>
With PSBT used with an air-gapped signer, there is increased danger in<br>
implementing the protocol wrongly by relying on the contents of the PSBT<br>
alone in the final verification step of a signature. The PSBT must be<br>
verified carefully against state stored by the host for the PSBT.<br>
Otherwise the signer can for example change or pre-fill the relevant<br>
NONCE fields and leak the private keys anyway. Is there a current best<br>
practice for how a PSBT can be identified by the host to store/retrieve<br>
the state?<br>
<br>
Are there other examples in PSBT where the host can't trust the contents<br>
of the PSBT the signer returns (except of course for the parts the user<br>
can verify themselves, like recipients, amounts, etc.)? In any case,<br>
guidelines or conventions on how to avoid the pitfalls would be good.<br>
<br>
Best, Marko<br>
<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div></div>