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.
I think you can do a scriptless commitment as follows:
sG=R+H(R,P,m)P.X=R+H(R,msg)Gand signsG=X+H(X,P,m)P, publishings,Xas the transaction's signature.Rallows you to then verify thatXdid 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)Ginmusig_nonce_process?), so perhaps this is a subset of adaptor signatures.