You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I think you can do a scriptless commitment as follows:
Take any random transaction you're going to sign (possibly via musig).
Generate the (public) nonce for it, ie R where sG=R+H(R,P,m)P.
Then, rather than doing that signature, calculate X=R+H(R,msg)G and sign sG=X+H(X,P,m)P, publishing s,X as the transaction's signature.
Revealing R allows you to then verify that X did indeed commit to msg.
This avoids the overhead of an OP_RETURN output, and may be superior to using p2c or a dummy tapscript path for the commitment in cases where it's the spender of funds that wants to make a commitment, not the receiver, or where the receiver doesn't want to complicate their wallet by maintaining info about the commitments.
That may have applications to timestamping (eg, organisations doing regular transactions could add timestamping commitments without changing their on-chain footprint), and maybe RGB (cf rgb-archive/spec#61) or Taro?
You should be able to use the adaptor sig api in order to implement it (set T=X-R=H(R,msg)G in musig_nonce_process?), so perhaps this is a subset of adaptor signatures.
The text was updated successfully, but these errors were encountered:
Yep! I believe this is "sign-to-contract", which I can't find an original citation for, but has been floating around in various guises (most recently as "anti-exfil" which is a special case where you commit to random crap) for some years. I even have an opentimestamps pull request implementing it.
I think you can do a scriptless commitment as follows:
sG=R+H(R,P,m)P
.X=R+H(R,msg)G
and signsG=X+H(X,P,m)P
, publishings,X
as the transaction's signature.R
allows you to then verify thatX
did indeed commit tomsg
.This avoids the overhead of an OP_RETURN output, and may be superior to using p2c or a dummy tapscript path for the commitment in cases where it's the spender of funds that wants to make a commitment, not the receiver, or where the receiver doesn't want to complicate their wallet by maintaining info about the commitments.
That may have applications to timestamping (eg, organisations doing regular transactions could add timestamping commitments without changing their on-chain footprint), and maybe RGB (cf rgb-archive/spec#61) or Taro?
You should be able to use the adaptor sig api in order to implement it (set
T=X-R=H(R,msg)G
inmusig_nonce_process
?), so perhaps this is a subset of adaptor signatures.The text was updated successfully, but these errors were encountered: