Sent with ProtonMail secure email.
------- Original Message -------
On Tuesday, May 3rd, 2022 at 02:37, vjudeu via bitcoin-dev
<bitcoin-dev@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
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
