pull down to refresh
10 sats \ 2 replies \ @TheBTCManual OP 8 Feb 2023 \ parent \ on: What Are Bitcoin Ephemeral Anchors? bitcoin
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
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