10 sats \ 5 replies \ @petertodd 8 Feb 2023 \ on: What Are Bitcoin Ephemeral Anchors? bitcoin
One of the odd things about ephemeral anchors is the use of OP_2 rather than OP_TRUE.
There's really no technical reason for it. It's just being too lazy to change a few unit tests that assume OP_TRUE is nonstandard. IMO we're much better off spending the time now to do the obvious thing, rather than doing something that'll unnecessarily confuse devs for years to come.
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021406.html
so could there be a case where some implementations are using OP_2 and others are using OP_True, and based on the one you used if someone wanted to use a fee sponsor for example, you'd need to use a wallet that is using the same implementation? Seems hella confusing
reply
Since the proposal is to add OP_2 (with a bunch of unnecessary other limits) to the standard transaction output types, only wallets that used that particular mechanism would work. Not OP_TRUE.
But yeah, it's still confusing. Heck, there's plenty of documentation out there giving OP_TRUE as an example of "anyone-can-spend" outputs. Which is what ephemeral anchors are when you strip away the fancy language.
reply
(author here for those reading)
The proposal is a bit more broad then the script itself, it's just what I imagine would be the dominant usage pattern if you weren't concerned about pinning by children.
An alternative proposal would be to watermark outputs via 0-value outputs only, and separately allow OP_TRUE-y outputs as an efficiency measure if people don't want key material for specific anchors.
Currently proposal allows any value output. This makes it easier to compose smart conracts such as dumping the "trimmed htlc" values to outputs rather than fee of the commitment transaction. Currently, the "parent tx" has to be 0-fee to ensure it doesn't get mined with the output remaining in the utxo set.
I guess the proposal could be relaxed to allow OP_TRUE-y (any value), or any otherwise standard script but must be 0-value? I think keeping the proposal narrow and focused is best personally, and no reason it can't be further expanded later if anchor-specific key material is strongly desired.
reply
Later in that thread I went ahead and implemented the suggested change: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-February/021418.html
It doesn't really matter to me. Most of my efforts is in making sure the proposal's methods and goals gets mind-share.
Looking forward to having robust RBF and CPFP interfaces in the nearish future!
reply
But IIUC you didn't actually merge the change to OP_TRUE into the pull-req, so the main pull-req was still OP_2.
reply