Mar 29, 2023
V3 and Package RBF Part 1 and Part 2 for background info on the problem setting and proposed solution for RBF pinning.
The proposed Ephemeral Anchor BIP is hosted
There is also a
bitcoin-inquisition PR. Motivation
Version 3 transactions solve the issue with what is commonly dubbed BIP125 rule#3 pinning: A large, low fee-rate transaction enters the mempool, and becomes economically prohibitive to remove from the mempool via today’s RBF rules. By limiting the size of a child transaction in a parent-child relationship to 1 KvB, we can bound this economic damage to a small multiple which depends upon what an “honest” CPFP’ing child transaction would look like given a users’ wallet utxo makeup. In essence, it is a “RBF carveout” policy.
Ephemeral anchors are a special type of output that are watermarked (by policy only) via a short static output script. These, along with a few policy ground rules, enable a new, more general “CPFP Carveout” which can sidestep package limit pinning. It also allows relaxation of output script requirements, increasing smart contract composability.
BOLT03 for some “light” reading about how to avoid package limit pinning(poorly) with today’s mempool policies. See
option_anchors scripts, with
1 OP_CHECKSEQUENCEVERIFY OP_DROP as the canonical widget to avoid pinning.
Did you review the PR?
Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach?
Why do anti-pinning measures in
BOLT03 appear suboptimal?
What is today’s
CPFP carve-out in Bitcoin Core? What are its limitations?
In what ways could BOLT03 be improved with Ephemeral Anchors?
What use cases are helped by including an ephemeral anchor? What use cases is it not helpful for?
Why does the usage of ephemeral anchors rely on package relay?
What mechanisms do we have in place to discourage dust level utxos?
Are 0-value outputs consensus valid to create? How about in policy? (Hint: see standardness checks for
Are 0-value outputs consensus valid to spend? How about in policy?
Does this increase the risk of dust entering the utxo set? Can you think of any situations that might arise?
Why does this new output type use
What benefits does this PR get from requiring V3 transactions? What properties of V3 does it rely on, if any?
Why are non-0 value outputs allowed to be Ephemeral Anchors?
Why not just watermark ephemeral anchors by being a dust output?
What is the
bitcoin-inquisition PR doing differently? Why? Meeting Log
2 17:00 <michaelfolkson> hi
4 17:00 <instagibbs> everyone make some digital noise
6 17:00 <abubakarsadiq> hi
8 17:00 <Luke96> First time here
9 17:00 <michaelfolkson> #startmeeting
11 17:01 <instagibbs> oops thanks michaelfolkson
12 17:01 <instagibbs> This is my first time hosting, IIUC I just dive on in by asking: Did you get a change to look at the notes? y/n
14 17:02 <michaelfolkson> y
15 17:02 <abubakarsadiq> y
16 17:02 <DaveBeer> y, at notes
17 17:02 <LarryRuane> Hope you don't mind a very basic question, something I've wondered for a while... the BIP says "Ephemeral anchors of any satoshi value are standard for relay" -- is there ever a difference between standardness for *relay* versus *mempool accept*? Or are those always the same?
20 17:02 <glozow> LarryRuane: theyre the same
21 17:03 <instagibbs> LarryRuane great question! Sometimes things can be standard for mempool entry but not propagate for various racey reasons... hopefully not super important for EA
22 17:03 <LarryRuane> 0.5y (notes)
23 17:03 <LarryRuane> instagibbs: +1 thanks!
24 17:04 <instagibbs> Regarding the PR, Concept ACK, approach ACK, tested ACK, or NACK? What was your review approach?
25 17:05 <LarryRuane> concept ACK, but (probably questionable to say this) mainly because I know many very smart people have worked on it! I believe we can all be influenced in that way
26 17:05 <michaelfolkson> I guess so far this seems the best solution hence Concept ACK but unsure whether something else could end up being better
27 17:05 <DaveBeer> lost myself in study of package RBF, version 3 and ephemeral anchors, need deeper understanding of problem to review, here mostly to lurk & learn
28 17:07 <michaelfolkson> I guess similar to LarryRuane I'm kinda trusting that the design space has been exhausted at this point and this is best
30 17:07 <instagibbs> ok let's dive into nitty gritty
31 17:08 <instagibbs> 2) Why do anti-pinning measures in BOLT03 appear suboptimal?
32 17:08 <michaelfolkson> instagibbs: Ah nice that link wasn't in the notes
33 17:08 <instagibbs> Can anyone understand the measures in place in BOLT03 to stop pinning?
34 17:08 <glozow> Anchor outputs suck: they're tiny little outputs that often don't get spent and hang out in utxo set, you need 1 for each party and CPFP carve out only works for 2 party.
35 17:09 <glozow> Also pinning
36 17:09 <instagibbs> right, today there are two dusty outputs per commitment transaction, and lots of pinning vectors. If we adopt V3 transactions we can already do a lot better.
37 17:10 <instagibbs> What anti-pinning measures do the "balance" outputs have?
38 17:10 <instagibbs> to_us IIRC
39 17:10 <instagibbs> to_local, excuse me
40 17:10 <michaelfolkson> Locks to the funding key
41 17:11 <glozow> I have a question. IIUC one motivation for OP_CSV 1 is we don't want any unconfirmed descendants to be added to these outputs, we only want unconfirmed children added to the anchor outputs. Are there other reasons to have the 1 block relative timelock?
42 17:11 <instagibbs> glozow sorry I was trying to talk about this feature
43 17:11 <instagibbs> look for "option_anchors" which includes " 1 OP_CHECKSEQUENCEVERIFY OP_DROP" snippets in code
44 17:12 <instagibbs> the only reason they are there is to stop people from spending that output with large junk, pinning the transaction
45 17:12 <instagibbs> There is simply no other reason for it
46 17:12 <glozow> ah! good to know, i thought there was another reason
47 17:12 <lightlike> instagibbs: aren't these part of the to_remote outputs instead of to_local?
48 17:13 <instagibbs> yes, LN today is very confusing, I was turned around :)
49 17:13 <instagibbs> to_local has the realy timelock delay, to_remote does not
50 17:13 <instagibbs> just the single block to stop spending
51 17:13 <instagibbs> to swing back to what glozow mentioned
52 17:13 <instagibbs> What is today’s CPFP carve-out in Bitcoin Core? What are its limitations?
53 17:15 <michaelfolkson> An exception to the max package size
54 17:15 <lightlike> If one parties CPFP's their anchor up to the mempool package size limit in order to pin the tx, the other party can use "one more" tx for their anchor, even though that exceeds the limit by 1.
55 17:15 <instagibbs> correct, "just one more", up to some fairly large size tx
56 17:16 <instagibbs> So as glozow mentioned, this only scales to 2 spendable unconfirmed outputs
57 17:16 <instagibbs> so if we wanted multiparty channels, robust CPFP of batched payouts, etc, it doesn't quite work
58 17:16 <michaelfolkson> And we don't have package relay yet so this CPFP carve out isn't actually possible to be utilized currently?
59 17:17 <michaelfolkson> Even though it is in Core
60 17:17 <instagibbs> the parent tx has to be higher than the min feerate of the node's mempool
61 17:17 <instagibbs> then CPFP takes care of the rest
62 17:17 <instagibbs> So in other words, you cann't have a 0-fee parent you bump, without package relay
63 17:18 <instagibbs> So, assuming we already have package relay/V3....
64 17:18 <instagibbs> 4) In what ways could BOLT03 be improved with Ephemeral Anchors?
65 17:18 <glozow> er another question sorry. why do we need 2 anchors instead of 1 anyone can spend anchor for example?
66 17:19 <instagibbs> We only need the one, sorry might have not said something clearly...
68 17:19 <glozow> sorry i meant 2 in the current spc
70 17:19 <michaelfolkson> glozow: Currently in the BOLT there are 2 needed
71 17:19 <michaelfolkson> Right
72 17:20 <glozow> yes, my question is why
73 17:20 <michaelfolkson> It says "to prevent a malicious peer from attaching child transactions with a low fee density to an anchor"
74 17:20 <michaelfolkson> So a form of pinning, right?
75 17:20 <instagibbs> So the idea was that Alice OR Bob could CPFP either version of the latest commitment transaction
76 17:21 <instagibbs> but in practice, that is really hairy, because mempools are not synced, so generally speaking you should be trying to bump your version only
77 17:21 <glozow> Ah so Rule 3 pinning. If it was anyone can spend, somebody might add 100ksat 1sat/vB child and you'd need to RBF that to do a new bump
78 17:21 <instagibbs> Oh, yes, EA *today* without V3 means child can be 101kvb
79 17:21 <instagibbs> sorry, didn't understand
80 17:22 <glozow> (note to self to specify whether I mean "today" "with v3" or "with ea" in the future)
81 17:22 <instagibbs> right, so today anchors require key material
82 17:22 <lightlike> does that mean that one anyone-can-spend anchor would work suffice if RBF rules were pinning-safe? And we need 2 because RBF rules aren't?
83 17:23 <instagibbs> lightlike you may not want anyone to bump your tx, theoretically, but that's the vast majority of the motivation yes
84 17:23 <instagibbs> Alice and Bob could have a single anchor they share key material for I suppose
85 17:23 <michaelfolkson> MuSig output
86 17:23 <glozow> lightlike: along the same lines... I'm wondering if, with v3, we could do 1 anyonecanpay anchor?
87 17:24 <instagibbs> glozow you could do wsh(OP_TRUE) with minimal sats, yes
88 17:24 <instagibbs> extra bytes to be standard to relay the output, and "not dust"
89 17:24 <michaelfolkson> Oh no MuSig output wouldn't work, or sharing key material, because you need this if your counterparty is unresponsive
90 17:24 <glozow> that is larger than a bare OP_TRUE though, and small UTXO if not spent. so still see value in EA
92 17:25 <instagibbs> Also there are cases where you can't "bleed out" value
93 17:25 <lightlike> glozow: isn't that basically what ephemeral anchor is, with the added benefit that it *must' be spent?
94 17:25 <glozow> lightlike: basically, but I think the biggest draw is the 0-value
95 17:26 <glozow> and the smaller size is pretty nice imo
96 17:26 <instagibbs> Well not just that, but also the fact you can un-CSV other outputs
97 17:26 <glozow> ahhhhhhhh
98 17:26 <instagibbs> "balance" outputs can now be whatever you want
99 17:26 <instagibbs> the "option_anchors" stuff I was talking about can safely be removed
100 17:27 <instagibbs> think of the EA output as a "mutex" on an unconfirmed transaction's outputs.
101 17:28 <instagibbs> So for LN with EA, we would get rid of the dusty values in the single anchor, and relax all the scripts required for the spec. This makes splicing much more powerful
102 17:29 <lightlike> Is it a problem, that when the child is replaced by different parties CPFP'ing, each party needs to contribute the fees for the entire package (not just the delta) because the parent is always 0 fee?
103 17:29 <instagibbs> 5) What use cases are helped by including an ephemeral anchor? What use cases is it not helpful for?
104 17:30 <instagibbs> we already talked a bit about LN, other ideas?
105 17:30 <michaelfolkson> Can you elaborate on the splicing more powerful thing? You still need to agree any splicing with your counterparty
106 17:31 <instagibbs> so for splicing, you want to be able to send funds to arbitrary destinations, even if counter-party doesn't know what the underlying script is
107 17:31 <instagibbs> so they may want a 1 block CSV to stop pinning
108 17:32 <instagibbs> but even if you wanted to doxx your script showing the 1 block CSV is in the script(handwave), things like LN funding outputs are incompatible!
109 17:32 <instagibbs> So you could not splice out into a new LN channel, in this example
110 17:32 <michaelfolkson> So this could increase the channel capacity without your counterparty agreeing to it?
111 17:33 <instagibbs> it just makes splicing out easier to design from anti-pin perspective
112 17:33 <michaelfolkson> Ok
113 17:35 <instagibbs> So EA is not useful for situations where you have ample ability to RBF your transactions
114 17:35 <michaelfolkson> On the use cases vaults always comes up with this kinda stuff
115 17:35 <instagibbs> that's the main thing it doesn't really help
116 17:35 <instagibbs> Another use-case I like to mention is that it allows a separation of "custodied" funds from fee funds. This is helpful in business settings or custodial settings
117 17:36 <instagibbs> hurrying along
118 17:36 <instagibbs> 6) Why does the usage of ephemeral anchors rely on package relay?
119 17:38 <glozow> because the only reason it's ephemeral is it's spent immediately by the child that it can't live without. Otherwise it's just "potentially dust anchors."
120 17:38 <glozow> Or “never propagated 0fee transactions”
121 17:38 <instagibbs> exactly, basically those two
122 17:38 <instagibbs> 7) What mechanisms do we have in place to discourage dust level utxos?
123 17:39 <michaelfolkson> DoS standardness limits
124 17:39 <LarryRuane> transactions spending dust aren't standard (not relayed) (?)
125 17:40 <abubakarsadiq> ephimeral policy rules
126 17:40 <instagibbs> LarryRuane creating or spending dust?
127 17:40 <abubakarsadiq> I mean policy rules :)
128 17:40 <LarryRuane> i thought spending
129 17:41 <instagibbs> LarryRuane incorrect! Spending dust is actually something we all want. It's making dust utxos we don't want
130 17:41 <michaelfolkson> Spending is good, it reduces the UTXO set. Creating them is bad
131 17:41 <LarryRuane> ah shoot, bad memory! :)
132 17:41 <instagibbs> 8) Are 0-value outputs consensus valid to create? How about in policy? (Hint: see standardness checks for vout).
133 17:42 <abubakarsadiq> I think they are consensus valid
134 17:42 <abubakarsadiq> policy invalid
135 17:42 <instagibbs> correct!
136 17:43 <LarryRuane> instagibbs: that's right, though, dust outputs bloat the UTXO set... spending them reduces the UTXO set... thanks
137 17:43 <instagibbs> 9) Are 0-value outputs consensus valid to spend? How about in policy?
138 17:43 <instagibbs> We just answered this one I think
139 17:43 <instagibbs> yes and yes. making utxo set smaller is good
140 17:44 <instagibbs> 10) Does this (EA) increase the risk of dust entering the utxo set? Can you think of any situations that might arise?
141 17:45 <michaelfolkson> It doesn't increase the risk assuming everyone applies these policy rules. It is a policy adoption question?
142 17:45 <abubakarsadiq> Yes assuming v3 policy is applied I think it does not
143 17:46 <instagibbs> correct, using "stock" PR it will not be mined into utxo set, but miners could of course modify their software
145 17:47 <instagibbs> thanks for the link
146 17:47 <instagibbs> Please jump back to old questions if you like, I'm just plowing forward
147 17:48 <glozow> In order for dust to enter the utxo set this way, a miner basically has to modify their node so they can mine a 0 fee tx on its own. seems not impossible, but pretty unlikely
148 17:48 <instagibbs> If they're being paid out of band, the user could just as easily spend the EA and add fees themselves
149 17:48 <instagibbs> that's the whole point!
150 17:48 <instagibbs> 11) Why does this new output type use OP_TRUE?
151 17:49 <michaelfolkson> There could be a tx with an ephemeral anchor output and other outputs that pays a non zero fee?
152 17:50 <LarryRuane> more general question, there seem to be many policy (standardness) restrictions that are not consensus restrictions... is that mainly because if it's consensus, then we can't remove the restriction (should it be discovered to be necessary) without needed a hardfork?
153 17:50 <michaelfolkson> In which case it would need to be caught by policy, otherwise it would be propagated
154 17:51 <instagibbs> LarryRuane yes making something (non)standard first is a typical step to making something have additional consensus meaning
155 17:52 <instagibbs> This question is mostly asking why that particular script and not something else? We already talked about wsh(OP_TRUE) being possible today, half answered at least
156 17:54 <instagibbs> Answer being: Spending the output requires no witness data, and no scriptSig data, making the input as small as possible
157 17:54 <instagibbs> 12) What benefits does this PR get from requiring V3 transactions? What properties of V3 does it rely on, if any?
158 17:55 <michaelfolkson> Assuming policy changes are adopted gradually rather than instantly there would be a window where these transactions/package with an ephemeral anchor wouldn't be propagated until adoption had lift-off
159 17:55 <instagibbs> michaelfolkson correct, as with any policy relaxation, you'll need some large minority of the network plus some miners to update to accept it
160 17:55 <michaelfolkson> So Lightning protocol changes to take advantage of these changes would probably wait until sufficient adoption
161 17:55 <michaelfolkson> Ok
162 17:55 <instagibbs> not only that, but for LN, all old channels would have to be upgraded, hitting the chain
163 17:56 <instagibbs> otherwise old states could still be broadcasted!
164 17:56 <instagibbs> time for one more question only I think so jumping to end.
165 17:56 <instagibbs> 15) What is the bitcoin-inquisition PR doing differently? Why?
166 17:57 <glozow> So iiuc you're skirting around package relay by having mempool validation prioritise the parent at 1sat/vB automatically?
167 17:57 <glozow> feerate configurable using ephemeraldelta
168 17:58 <instagibbs> correct
169 17:58 <instagibbs> everything except the "is this spent in the same package" is checked
170 17:58 <instagibbs> due to lack of package relay
171 17:58 <glozow> ok and whats the usage of -blockmintxfee? Just to exercise the logic that the parent needs to be bumped? So ephemeral delta takes care of minrelay, and then blockmintxfee stops it from getting mined before the child comes in?
172 18:00 <instagibbs> IIRC it allows the miner to allow them into mempool, yet not mine them, with special config
174 18:00 <instagibbs> #endmeeting
175 18:00 <instagibbs> thanks everyone for coming!
176 18:00 <glozow> ok hm. i kinda need to get rid of blockmintxfee for pakcage relay tho 🤣
177 18:01 <instagibbs> well.... if you get relay in, bitcoin-inquisition will rebase :D
178 18:01 <instagibbs> problem solved
179 18:01 <glozow> tru tru
181 18:01 <glozow> thanks for hosting!!!
182 18:01 <instagibbs> please reach out if things didnt make sense or you have nagging questions
183 18:01 <michaelfolkson> Thanks instagibbs
184 18:03 <LarryRuane> thanks @instagibbs and all!
185 18:04 <lightlike> thanks instagibbs!
186 18:05 <michaelfolkson> It would be nice to get all the required eltoo policy changes in with sufficient adoption before a APO soft fork was considered. With the lag in adoption n all
187 18:07 <instagibbs> you really need ~10% uptake or so, plus some miners. I think the lead time would be plenty. Still lots of policy work being done
188 18:08 <instagibbs> I'm very much intersted in improving mempool policy/relay long before consensus changes that require them to be safe :)