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". And then, signatures are more flexible than public keys, because we can use many different sighashes to decide, what kind of transaction is allowed and what should be rejected. Then, if we could use the right signature with correct sighashes, it could be possible to disable key recovery and require some specific public key, then that scheme could be safely used again. I still have no idea, how to complete that puzzle, but it seems to be possible to use that trick, to restrict destination address. Maybe I should wrap such things in some kind of multisig or somehow combine it with OP_CHECKSIGADD, any ideas? _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
