Post
Topic
Board Development & Technical Discussion
Re: BIP 322 draft design and improvement thread
by
garlonicon
on 10/08/2022, 20:48:30 UTC
Quote
There was no such thing in the world before you guys made it up, right?
Wrong. You can always send your coins to "<messageHash> OP_DROP <pubkey> OP_CHECKSIG" and spend them, then it will be quite similar to OP_CHECKDATASIG, the difference will be just in the format of the message: in "Bitcoin Message" you have this famous prefix, here you would have transaction data as your prefix. So, the different message will be signed, but the whole functionality will be the same. Or you could have "<pubkey> OP_CHECKSIG" and use different sighashes that would take your message from the stack instead. There are many options.

Quote
No problem, as super devs you are entitled to do inventions, but as an observer I have all the rights to review and to resist.
Good luck banning "OP_SHA256 <messageDoubleHash> OP_EQUALVERIFY <pubkey> OP_CHECKSIG" from the script, and all other variants of that.

Quote
Why should anybody do it?
Because you cannot stop people from implementing it on their own. Having it standardized would mean that their signatures will at least be compatible with some BIP. Now we have a situation, where different wallets implement their own ways of handling signatures, so there is a choice between getting it standardized or not. You cannot stop it, because it is not something that has to go through some kind of soft-fork, it is purely informational no-fork, trying to resist is like trying to stop HD wallets.

Also note that we have almost-BIP-322-compatible network called signet, and note that it can be hijacked to serve the same purpose: the recipient could set some signet challenge, and wait for a valid signed block. The only catch in hijacking the signet is that mining is needed to make a valid signature. But one simple change, and you can get fully working script verifier, if you set the difficulty to the same value as in regtest.

Quote
Then how is it possible to have both, template based and interpreter based implementations in one world?
Guess what, P2SH is template-based and interpreter-based: you have some template, some fixed opcodes here and there, and it works. It is fully compatible with other nodes, because just more data are pushed into the stack, and old nodes simply check if the hash of the script is correct, but upgraded nodes actually execute the script. And here it could be similar: some nodes could know how to handle transactions, and other nodes could simply require some magic bytes in some format, and then perform signature checking on some hashed data, and report everything non-standard as "not implemented".

Quote
First and foremost, stop scrambling the terminology, I know, we all know, Greg is genius, you are genius, ..., no doubts, but we are all humans, sometimes we go too far.
So, go on, and propose some BIP to get rid of the entire Script, and go back to P2PK-only-world. Or make a sidechain for that, and put your coins there. Because as long as we have Script, and as long as it gets more and more complex, there will be use cases for signing different outputs. Unless you want to tell someone that "You have your coins on P2SH/P2WSH/P2TR? Too bad, please move to P2PKH, and sign it, then I will verify it".