One large drawback of this approach is that it relies on Bitcoin’s legacy script. This means that the transaction spending the anchor is txid-malleable by miners. This is due to legacy script’s lack of CLEANSTACK consensus rules. This means composition with other protocols like splicing can be problematic, where the pre-signed transaction chains can be broken unless a new signature type like ANYPREVOUT or similar is used.
At first blush, something like wsh(OP_TRUE) neatly solves this, at the expense of 33 more output vbytes, and a witness script of “OP_TRUE” being revealed. This seems pretty costly, and theoretically could also already be used in mainnet, both for output creation and redemption.
Instead, why not just utilize bip141’s softfork for witness programs, and use an otherwise undefined witness program? For example, replace the script “OP_TRUE” with “OP_TRUE 0xffff” which triggers the scriptSig rule in bip141:
The scriptSig must be exactly empty or validation fails.
But is otherwise undefined, allowing an empty witness to spend. This is 3 additional vbytes over the original proposal total, and is implemented here:
Note that these (non-dust)outputs are already standard to create, but not to spend, which is the additional relay relaxation in the commit.
The branch will actually get smaller since I’m not messing with OP_TRUE outputs anymore which tests in master love to use.
If you made the two digit code be 0x4e73 instead of 0xffff that would give it the bech32m address bc1pfeessrawgf (ie “bc1p”, “fees”, checksum).
You can choose any three letters in the bech32 charset followed by either q or s, followed by the 6 char checksum. (0xffff is bc1plllsqd8ech; 0x0100 (1) gives bc1pqyqqgs7ult; 0x0001 (256) gives bc1pqqqs4em24rand 0x0000 gives bc1pqqqqqcnjqs)
EDIT: testnet/signet has 4e73 look like tb1pfees9rn5nz or with regtest bcrt1pfeesnyr2tx. bitcoin-cli decodescript 51024e73 if you want to try other combinations for something fun.
I’m considering supporting both OP_TRUE and OP_TRUE 0x4e73 at this point. It’s a tiny difference, and users can opt into non-segwit versions if they simply don’t care about the child transactions’ txid stability.
I don’t understand what you’re doing here. The BIP you link seems to only talk about plain OP_TRUE, right? So the malleable version? What part of the BIP141 are you using to do this?
I don’t understand “otherwise undefined witness program”. You mean v1 programs that are not 32 bytes and redefine those? But then why would you need OP_TRUE? Can’t you simply standardize a v1 program that is 1-byte in size and make it standard if thar 1 byte has a fixed value? Which is anyone can spend anyway, so it’s the same as OP_TRUE?
Heh? Can you re-read my original message? And explain what you are proposing/describing? What I said was to standardize a v1 (taproot-version) witness program of a single byte. So like scriptPubkey of OP_1 OP_PUSHBYTES_1 0x42. I think for consensus any non-32-byte v1 program is anyone-can-spend, no?
Seems like a good question for https://bitcoin.stackexchange.com/ – I think segwit was originally a single push, where the first byte was the version, and the rest was the program; with that push being between 2 and 41 bytes; now the version and program are separate pushes, but rather than having the program be 1-40, it’s 2-40…