Earlier last year on March, there was a post here by Jeremy Rubin that explains
how a person could delegate its UTXO to some script, by (AFAICT) creating a new
transaction using that UTXO, with whatever script you want it to have.
It was written in terms of normal transactions, but can be extend
>> TODO: A way for the initial signer to delegate to another
>> scriptPubKey; needed for better privacy and CoinJoin/Lightning
>> compatibility
I need more documentation to understand this motivation.
On Tue, Aug 9, 2022 at 8:46 PM Ali Sherief via bitcoin-dev
wrote:
> In the case of the last TOD
Wait a minute. I did some lookup on OP_CHECKDATASIG to see if it's in some btc
BIP draft somewhere, and it is actually an opcode in Bitcoin Cash since some
years ago -
https://mengerian.medium.com/the-story-of-op-checkdatasig-c2b1b38e801a
I think we can safely assume that Kalle and the other ma
> I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG
> can take off the stack and perform an ECDSA public
> key recovery
You can always perform key recovery for legacy ECDSA: " OP_SWAP
OP_CHECKSIG" is always spendable, for any valid DER-encoded pair. Here,
if "
> Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be
> somehow introduced to make it compatible with "Bitcoin Message".
I suppose in the case of legacy P2PKH signing, a hypothetical OP_CHECKDATASIG
can take off the stack and perform an ECDSA public key
recovery, follo
> I'm not sure what is to be gained from adding an opcode
Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be
somehow introduced to make it compatible with "Bitcoin Message". And we have
opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is
"conditionally va
