related posts
10 sats \ 4 replies \ @TNStacker 8 Feb 2023
Nice, deep intro!
reply
0 sats \ 3 replies \ @TheBTCManual OP 8 Feb 2023
LOL I tend to get a little long-winded doing my best to think of if a reader is coming to the post knowing zero, can they leave knowing something without having to learn all there is to know about bitcoin first, learning and refining the approach as we go
reply
0 sats \ 2 replies \ @TNStacker 8 Feb 2023
I am Gen X, so I can handle deep reads. Some of the youngers might have issue, but they probably aren't here, right?
reply
0 sats \ 1 reply \ @TheBTCManual OP 8 Feb 2023
Lol hopefully it doesn't alienate too many, our biggest readership base (32%) is the under-34 demographic
reply
0 sats \ 0 replies \ @TNStacker 8 Feb 2023
I KNOW!!! 🤣
reply
10 sats \ 5 replies \ @petertodd 8 Feb 2023
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
reply
10 sats \ 2 replies \ @TheBTCManual OP 8 Feb 2023
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
0 sats \ 1 reply \ @petertodd 8 Feb 2023
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
0 sats \ 0 replies \ @theinstagibbs 10 Feb 2023
(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
0 sats \ 1 reply \ @theinstagibbs 10 Feb 2023
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
0 sats \ 0 replies \ @petertodd 10 Feb 2023
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