AdamISZ [ARCHIVE] on Nostr: 📅 Original date posted:2022-05-21 📝 Original message:Sent with ProtonMail ...

📅 Original date posted:2022-05-21
📝 Original message:Sent with ProtonMail secure email.
------- Original Message -------
On Tuesday, May 3rd, 2022 at 02:37, vjudeu via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:


> Typical P2PK looks like that: "<signature> <pubkey> OP_CHECKSIG". In a typical scenario, we have "<signature>" in out input and "<pubkey> OP_CHECKSIG" in our output. I wonder if it is possible to use covenants right here and right now, with no consensus changes, just by requiring a specific signature. To start with, I am trying to play with P2PK and legacy signatures, but it may turn out, that doing such things with Schnorr signatures will be more flexible and will allow more use cases.
>
>
> The simplest "pay to signature" script I can think of is: "<signature> OP_SWAP OP_CHECKSIG". Then, any user can provide just a "<pubkey>" in some input, as a part of a public key recovery. The problem with such scheme is that it is insecure. Another problem is that we should handle it carefully, because signatures are removed from outputs. However, we could replace it with some signature hash, then it will be untouched, for example: "OP_TOALTSTACK OP_DUP OP_HASH160 <signatureHash> OP_EQUALVERIFY OP_FROMALTSTACK OP_CHECKSIG".
>

Doesn't this suffer from the standard "circular reference" problem for covenants? To pay to a utxo U1, whose scriptpubkey is a (p2wsh wrapped, say) script of: sig, op_checksig, I must create that sig, using my chosen public key, and a message which is a (signature style) hashing of a tx TX1, where an/the input to TX1 is U1, and the txid of U1 'hashes over' that script, which includes the sig we're trying to create. You can't make a hash of data which includes that hash (unless the hash fn is broken ofc).

I don't think that's affected by the later discussion here or in Zmn's response right?

Also a side detail which you might find useful in these ponderings: pubkey recovery is, as you know, possible in ECDSA but is not possible in BIP340 schnorr (which has key prefixing, i.e. the pubkey is included in the message hash binding, i.e. the e in s = k + ex), but is in the original Schnorr where only R(=kG), m are included in e. Easy to see why: from R, s and e(=H(R,m) .. easy to calculate) you can get P = (sG - R)* e^-1.
But in BIP340 Schnorr where (R, s) is published and e (=H(P, R, m)) is not, you cannot reconstruct e and so can only calculate e*P, which by DL assumption does not reveal P. Another way to put it is: if you made up a random R, s you wouldn't be able to find the right 'P' to put into e=H(P, R, m) so that the same P came out, and so that the sig actually verifies.

Cheers,
waxwing/AdamISZ