Advertise `NODE_REPLACE_BY_FEE` and connect to 1 outbound full-rbf peer if `mempoolfullrbf` sets (p2p)

Host: mzumsande  -  PR author: ariard

The PR branch HEAD was 703d9257db at the time of this review club meeting.


  • Bitcoin Core’s RBF policy enables unconfirmed transactions to be replaced by conflicting transactions (“double spends”) under certain conditions. If these conditions are met, nodes will replace the transaction in their mempool and relay the replacement transaction to their peers.

  • The default policy requires opt-in BIP 125 signaling: Only original transactions that signal replaceability (using the nSequence field on one of its inputs) are subject to replacement. If the original transaction didn’t signal replaceability, the replacement transaction will be neither accepted nor relayed.

  • For L2 protocols, the necessity to opt-in to RBF poses DoS problems, see this mailing list post for a summary of research. Therefore, it has been suggested to make full-RBF possible (removing the necessity to opt in).

  • As a first step, PR #25353 added an optional -mempoolfullrbf parameter to Bitcoin Core, which is disabled by default. If the node operator enables this, the node will ignore the signaling (but will still adhere to other RBF rules).

  • This PR goes one step further by implementing a preferential peering solution for peers that have -mempoolfullrbf enabled. These peers would now advertise a full-RBF policy using service flags and make additional automatic outbound connections to peers that also support full-RBF.


  1. Did you review the PR? Concept ACK, approach ACK, tested ACK, or NACK?

  2. What network-level conditions must be fulfilled for full-RBF to “work”, i.e., facilitate the propagation of transactions that replace others not signaling BIP 125? Is it necessary that every node or the majority of nodes need to support it?

  3. This PR currently suggests to make 4 additional connections to full-RBF peers (1 in an earlier version). What should be considered when picking this number? What are the downsides of having too few / too many connections?

  4. What happens if service flags (such as NODE_REPLACE_BY_FEE) a peer tells us in their version message are different from the service flags we had saved in AddrMan? Is the logic different when we learn from an addr message instead from the peer themselves? Does it matter if the updated entry has less or more service flags than the old one? (Hint: Look at AddrMan::AddSingle and AddrMan::SetServices_)

  5. With this in mind, do you think that false signaling of a NODE_REPLACE_BY_FEE service flag could be problem? Could it be detected and punished?

  6. Which of the following ways to proceed do you prefer and why:

    • Preferential peering (this PR)

    • Changing the default to -mempoolfullrbf = 1

    • Status quo (leave it up to users to actively pick -mempoolfullrbf = 1)

    • Something else?

Meeting Log

  117:00 <lightlike> #startmeeting
  217:00 <stickies-v> hi
  317:00 <lightlike> hi!
  417:00 <b_101> hi
  517:00 <ishaanam[m]> hi
  617:00 <theStack> hi!
  717:00 <BlueMoon> Hello!!
  817:00 <ariard> hi!
  917:00 <michaelfolkson> hi
 1017:00 <lightlike> Welcome to the review club - anyone here for the first time?
 1117:01 <Kaizen_Kintsugi_> Hi
 1217:01 <stratospher[m]> hi
 1317:02 <lightlike> Today's meeting is about #25600 by ariard. Notes and questions are at
 1417:02 <larryruane_> hi
 1517:02 <brunoerg> hi
 1617:02 <lightlike> Maybe to start, can someone summarize the changes of this PR?
 1717:03 <Kaizen_Kintsugi_> Giving an option and nodes to prefer rbf
 1817:03 <larryruane_> we already have fullrbf functionality; this PR lets us have a better chance to connect to other fullrbf peers (instead of it being just luck)
 1917:04 <BlueMoon> An optional -mempoolfullrbfa Bitcoin Core parameter was added
 2017:04 <larryruane_> if we send a replacement tx to a non-fullrbf peer, it will ignore it, which isn't very useful
 2117:04 <lightlike> oh, and I almost forgot this - who got a chance to review this? (y/n)
 2217:04 <larryruane_> BlueMoon: I think that was added in an earlier PR
 2317:05 <larryruane_> y
 2417:05 <b_101> y
 2517:05 <davidjumberj> n
 2617:05 <theStack> y
 2717:05 <Kaizen_Kintsugi_> n
 2817:05 <BlueMoon> y
 2917:05 <stickies-v> n, just read the PR conversation, here to lurk & learn
 3017:05 <juancama> hi everyone
 3117:06 <stratospher[m]> y
 3217:06 <lightlike> Kaizen_Kintsugi_: larryruane_ : yes!
 3317:06 <ishaanam[m]> I didn't review the code very carefully, I did more conceptual review
 3417:07 <larryruane_> there's not much code in this one! the hard part is all conceptual! lots of game theory kind of stuff, very interesting!
 3517:07 <theStack> concept ACK, given the assumption that full-rbf is important (didn't go over the mailing posts explaining the exact reasons for the need in detail...)
 3617:07 <BlueMoon> Thanks larryruane_ I didn't know it was in a previous one.
 3717:07 <lightlike> yes, the parameter was already added in #25353 - this PR goes one step further.
 3817:08 <b_101> larryruane: +1
 3917:08 <larryruane_> theStack: similar for me, I could not follow the complex reasoning in the mailing list, and a lot of what's on the PR
 4017:08 <lightlike> yes, I think for this PR the conceptual discussion is at least as important and difficult as the actual implementation.
 4117:08 <larryruane_> i'm just glad there are so many amazingly smart people working on this stuff who do!
 4217:09 <lightlike> So let's jump into the questions:
 4317:10 <lightlike> What network-level conditions must be fulfilled for full-RBF to “work”, i.e., facilitate the propagation of transactions that replace others not signaling BIP 125? Is it necessary that every node or the majority of nodes need to support it?
 4417:11 <larryruane_> I think the answer to Q2 is definitely no, but I don't know to quantify it .. it's like 6 degrees of Kevin Bacon kind of thing
 4517:11 <theStack> not sure if this was the intention of the question, but one of my initial thoughts was, that at the very least the miners have to support it, otherwise the replaced txs will never end up in blocks
 4617:11 <theStack> (of course, they have an incentive to do full-rbf, so that shouldn't be a problem)
 4717:11 <larryruane_> you don't have to have that many nodes that enable fullrbf to still get a lot of propagation
 4817:11 <stickies-v> a sufficient amount of nodes in the network need to have at least 1 full-RBF-route to a sufficient amount of miners, so definitely no need to have majority of nodes required
 4917:12 <Kaizen_Kintsugi_> I think the majority, if you are surrounded by nodes that aren't doing RBF, your transaction wouldn't be propagated by them, correct? I believe this would open up a subtle eclipse attack vector with enough plausable deniability.
 5017:12 <b_101> concept ACK, couldn't figure out from the discussions if the approach is safe
 5117:12 <glozow> oops hi! sorry i’m late
 5217:13 <Kaizen_Kintsugi_> hi
 5317:13 <lightlike> theStack: yes, at least some miners need to support it. Not necessarily every miner though.
 5417:13 <larryruane_> did someone do some simulation? that would be helpful -- IF you have a realistic model of network topology (that's the hard part I would think)
 5517:13 <brunoerg> stickies-v: +1
 5617:13 <stickies-v> theStack: yeah true need enough miners supporting it, however they're also directly incentivised for enabling it though
 5717:15 <instagibbs> if a miner somehow misses the "first" version, it may also make it through
 5817:15 <stickies-v> larryruane_: lightlike mentioned doing a simulation in
 5917:15 <Kaizen_Kintsugi_> Someone did do a simulation
 6017:15 <larryruane_> perhaps a subtle (or incorrect!) point: if the miners _always_ accept higher feerate replacements, always, then would they be setting themselves up to be DoSed?
 6117:15 <Kaizen_Kintsugi_> ah yes I was just going to paste that, thanks stickies
 6217:15 <lightlike> yes, I'd say that from a network perspective, all full-RBF connecting nodes (including the miner's nodes) should form a cluster, so that there is some path from each node to a miner.
 6317:16 <lightlike> * full-RBD supporting nodes
 6417:16 <larryruane_> stickies-v: Kaizen_Kintsugi_ +1 thanks
 6517:16 <ariard> larryruane: there is the rbf penalty increased rule required for each replacement for that, rbf rule 4 in bip 125 parlance?
 6617:16 <stickies-v> larryruane_: that's assuming we know which nodes are miners?
 6717:16 <lightlike> yes, I did some simulations to get a feeling how many nodes would need to support full-RBF without any preferential peering.
 6817:16 <larryruane_> ariard: +1 good point
 6917:17 <glozow> larryruane_: this is related to signaling *only*, it doesn't apply to other RBF rules.
 7017:18 <larryruane_> glozow: +1
 7117:18 <glozow> i suppose this can also be achieved if people in the community running full RBF nodes connect to each other manually, and at least 1 of these nodes is a miner
 7217:19 <lightlike> glozow: yes, that's possible too.
 7317:19 <BlueMoon> glozow +1
 7417:19 <b_101> glozow: +1
 7517:20 <glozow> of course not very robust or privacy-preserving but if you're desperate to replace something, maybe worth it?
 7617:20 <larryruane_> sorry if I'm getting ahead, but would this PR be considered just a step along the path to eventual default fullrbf?
 7717:20 <glozow> not really tbh, because it still requires users to turn it on. default is still off.
 7817:20 <ariard> glozow: there is also a centralization effect of the full-rbf topology as you're likely to rely on a social communication channel like irc, reddit, a gist, ...
 7917:21 <Kaizen_Kintsugi_> as an aside, it is surprising to me that this behaviour isn't default. But I am noob.
 8017:21 <lightlike> so in my simulations I got the result that without any preferential peering ~10-15% of supporting nodes would be necessary (which is not a lot, my intuition was expecting more like 30-40%).
 8117:22 <lightlike> It seems unrealistic to me that that many users would choose an optional flag (at least without some big social media campaign or something...)
 8217:22 <glozow> ariard: yeah for sure. but also, you can probably trust your buddy on irc to run a "true" full rbf node more than you can trust a peer on the p2p network advertising NODE_FULL_RBF
 8317:22 <Kaizen_Kintsugi_> Hey lightlike, do you have a link to your simulation code? I'm curious of how a sim is built in bitcoin. Do you just use the functional testing framework?
 8417:22 <instagibbs> Interesting to note that it doesn't necessarily preferentially "Activate" based on a node's economic footprint.... which means sybils may be tempting...
 8517:22 <b_101> lightlike: agree
 8617:23 <instagibbs> To be clear, I'm against Sybiling the network, just noting how it's different from consensus changes
 8717:23 <sipa> i have a question: is the goal of this PR to (a) make "signal-less RBF" work for people who turn on the option, so they themselves can perform such transactions (b) to have the network "ease into" full-RBF relay if people turn it on, so it's easier to later argue that fullrbf can be made default, or something else?
 8817:23 <lightlike> Kaizen_Kintsugi_: Not right now, I can upload it later.
 8917:23 <sipa> And if it's just (a), why can't the people who we expect to turn this on not just signal RBF?
 9017:23 <Kaizen_Kintsugi_> no worries or rush, thx for indulging my curiousity
 9117:23 <ariard> glozow: yeah depends how you construct the social communication channel, if the full-rbf peers listed are comming from web-of-trust (and there i agree with you) or it's super liberal in listing
 9217:23 <larryruane_> Kaizen_Kintsugi_: I *think* the reason it wasn't always default is that it makes unconfirmed transactions less reliable ... the receiver can't know if it will be replaced, so doesn't trust it as much ... without RBF, the receiver can have a little more confidence that the tx will get mined
 9317:24 <sipa> (I haven't really followed all the discussions, feel free to point me somewhere if this was discussed before)
 9417:24 <larryruane_> (but I think the answer to what i said is that people shouldn't rely on mempool tx anyway!)
 9517:24 <BlueMoon> lightlike I would also like to see it :)
 9617:25 <b_101> lightlike: I'm akso interested in your work if you can share, thx
 9717:25 <ariard> sipa: so yes for a) the goal is to make "signal-less RBF" work for node opeators, without the additional work to do manual discovery of other full-rbf peers
 9817:25 <Kaizen_Kintsugi_> Thanks larry, that logic is a surprise to me as I always assume unconfirmed transactions are always unreliable.
 9917:25 <sipa> ariard: So in that case, why can't the people who care about this just set the RBF flag?
10017:26 <sipa> (or expect those who pay them to do so)
10117:26 <ariard> sipa: this is what this PR is actually achieving, activating service bit 26 for them
10217:26 <instagibbs> sipa, defining "work" in (a) to mean "path from me to miner who opts in exists" imo
10317:26 <Kaizen_Kintsugi_> Can you set the RBF flag and just drop replacement transactions just to be a jerk?
10417:26 <instagibbs> ariard, why preferntial peering I think he means
10517:26 <sipa> ariard: By RBF flag I mean the BIP125 opt-in.
10617:26 <sipa> Not a P2P service flag.
10717:26 <instagibbs> oh!
10817:26 <larryruane_> sipa: I think the problem is that in LN, an *attacker* can *not* set the RBF flag, so then the good guy can't replace an evil tx
10917:27 <larryruane_> (just got that impression from ML discussion but i don't really know)
11017:27 <Kaizen_Kintsugi_> ah thanks for clearing that up larry
11117:27 <ariard> about b) there is the idea of actually letting the network of nodes, and each individual operator, express a preferrence for full-rbf or not, without the project turning on a default
11217:27 <Kaizen_Kintsugi_> thats what I was wondering
11317:27 <Kaizen_Kintsugi_> I really like this preferential peering acctually
11417:28 <ariard> sipa: by the people who care you mean, the ones who cares about zero-conf transactions or the ones who care about full-rbf?
11517:28 <Kaizen_Kintsugi_> kind of a soft vote on network behaviour
11617:28 <sipa> ariard: Those who care about the ability to replace transactions.
11717:28 <instagibbs> imagine a coinjoin, Alice races all other joiners with a non-signaling tx double-spending said coinjoin, now you might get stuck without seeing why, and replacements don't seem to work(except sending coin "back to self" to cancel)
11817:28 <_aj_> ariard, sipa: i think the scenario is that you post a pre-signed commitment tx A, with low or 0 fees, and then an attacker announces a non-RBF tx B that supplies some fees (enabling relay) but not enough to get mined; at which point you can't replace A (because you don't have a different version of it) and can't replace B (because it's not RBF-opt-in, and doesn't inherit A's RBF-ness)?
11917:28 <glozow> sipa: I think one scenario is a zeroconf LN funding, where they broadcast something conflicting with your channel open tx.
12017:28 <lightlike> sipa: if only people who care set the flag, and that number is in the low % of nodes, their transactions probably won't get relayed to a miner.
12117:28 <ariard> larryruane_: yes, you can DoS the funding phase of a bunch of use-cases, at minimal cost (just have to pay over minimal mempool fee)
12217:29 <lightlike> I'd assume most users don't care either way, but since the default no-full-RBF they will jsut go with it.
12317:29 <ariard> sipa: so since #25353, those who care about the ability to replace transactions can do it so, however for the replacement to be effective on the p2p network wise, I think you need propagation paths to the miners, and a subset of them turning on the option too
12417:29 <larryruane_> _aj_: thanks, ariard: thanks, very helpful explanations
12517:30 <instagibbs> its a tricky DoS attack which shows that "opt in" isn't a free lunch, imo
12617:31 <ariard> _aj_: yes this is the correct description of the issue, and affecting LN dual-funded, coinjoins, coinswaps, etc
12717:31 <michaelfolkson> This PR feels like a stepping stone to turning on the default. Is there a strong enough argument for needing this stepping stone? I'm not sure
12817:31 <ariard> note, the propagation of non-RBF tx B should be anterior to the pre-signed commitment tx A, which I believe is achievable by an attacker by mass-connecting and bypassing the privacy-preserving relay timers
12917:31 <glozow> _aj_: in that case adding a child to A and using package RBF should work, yes?
13017:32 <instagibbs> glozow, no, B isn't "allowing" replacement
13117:32 <sipa> TBH, my preference is just to make -mempoolrbf default at some point.
13217:32 <ariard> glozow: depends if package RBF overrides the replacement signaling flag, can't remember the state of the package RBF design?
13317:33 <instagibbs> michaelfolkson, my take:
13417:33 <glozow> V3 must be replaced by V3, and V3 signals replaceability. also sorry, totally going off topic
13517:33 <_aj_> glozow: not sure. add the constraint that only one of A's outputs is spendable immediately, and all the others have a "1 CSV" delay, perhaps
13617:33 <lightlike> Next question (it's ok to continue the conceptual discussion in parallel):
13717:33 <ariard> glozow: yeah so here you might have a conflict issue between the attacker fully-malleable transaction being V2 and your V3 package
13817:34 <lightlike> This PR currently suggests to make 4 additional connections to full-RBF peers (1 in an earlier version). What should be considered when picking this number? What are the downsides of having too few / too many connections?
13917:34 <larryruane_> this is really a tough one!
14017:35 <sipa> I'm not sure why that number is acceptable. If 12 outbound connections is acceptable, we should always make them. If they're not, we shouldn't make them with or without -mempoolfullrbf.
14117:35 <larryruane_> one obvious downside of too many connections is higher resource usage
14217:35 <ariard> michaelfolkson: sure, we might have a number of node operators wishing to stay on opt-in RBF as a default, the idea of having automatic preferential peering you let of community of nodes operators express their own prefs
14317:36 <glozow> ariard: yeah still screwed if it's e.g. a channel open and they get there first with a V2 non-BIP125
14417:36 <instagibbs> sipa, for segwit pref peering, was it just making sure N were with segwit aware?
14517:36 <instagibbs> when segwit was deploying, Core did preferential peering to segwit peers. So long ago I don't recall details.
14617:36 <ariard> without the project contributors assuming what should be the default "a priori" and collecting more data points
14717:36 <sipa> instagibbs: yes
14817:36 <larryruane_> sipa: that makes sense to me as well
14917:37 <glozow> ariard: have you considered something like not mutually exclusive with this PR
15017:37 <ariard> sipa: i think you have two questions, a) what should be the sufficient number of automatic outbound connections to have efficient propagation paths and b) is that sufficient number acceptable from a inbound slots resources consumptions viewpoint?
15117:38 <lightlike> I think one problem with everyone making 12 connections is that we don't have enough inbound capacity for that. If just a few nodes (say <5%) have fullmempoolrbf enabled and do this, it might be less of a problem.
15217:38 <sipa> I can see the rationale for ␝adding␏ connections rather than just preferential peering, as this means you don't get reduced connectivity to the rest of the network... but I don't think it's acceptable to just increase load on the network because of this.
15317:39 <sipa> ariard: I don't have a strong opinion on the number 4, or how this peering is done. But I don't think we should just increase the number of connections just because. If 4 extra connections (or whatever you pick, even 1) is acceptable, why not make them always?
15417:39 <ariard> glozow: yeah it was suggested to me last year by harding, iirc it didn't fix the DoS issue as the replacement timeout is in fact the DoS delay offered to the attacker
15517:39 <_aj_> sipa: devil's advocate: you're only increasing load on the network that opts in to full rbf signalling?
15617:39 <Kaizen_Kintsugi_> Is it reasonable to set a parameter that specifies a percentage of the operators connections to be of their preference, in this case full-rbf.
15717:40 <sipa> _aj_: Unless some evil node on the network relays ADDR messages with the flag forcefully OR'ed in...?
15817:40 <ariard> _aj_: i think this is how it should work, as you only connect to service bit 26 peers, if the node operators are okay with this usage of their inbound slots
15917:41 <sipa> There is no way a node can prove that it's a full RBF peer, so you can't disconnect them if they turn out to not be a full RBF node while you though they would be.
16017:41 <_aj_> sipa: hmm, either way, would be smart to disconnect if you want a peer that's full rbf, and you connect and it turns out it's not
16117:41 <lightlike> sipa: that (false signaling) is actually my next 2 questions :)
16217:41 <glozow> ariard: that's true. they just grief you for N time instead of forever. but a reasonable step towards full rbf as default?
16317:41 <lightlike> What happens if service flags (such as NODE_REPLACE_BY_FEE) a peer tells us in their version message are different from the service flags we had saved in AddrMan? Is the logic different when we learn from an addr message instead from the peer themselves?
16417:42 <ariard> sipa: so if I understand correclty your point, the full-rbf peers should be deduce from the overall outbound connections budget we already have (the 8 outbound full-relay and the 2 outbound block-relay-only) ?
16517:42 <_aj_> sipa: if they claim they're not a full-rbf peer (even if they're lying), that's a good enough reason to disconnect though?
16617:42 <glozow> yeah exactly, our outbound slots are precious, so I'm not sure how i feel about preferring a type of outbound connection that we can't verify is legit
16717:43 <sipa> Hmm, yes, if it's the case that we disconnect when we attempt to connect to fullrbf, but the peer then tells us they're not fullrbf somehow, then _aj_'s devil's advocate argument works.
16817:43 <_aj_> sipa: that said, saying "connect to 4 random peers, 2 blocks-only peers, and the remaing 4 outbound connections must be full-rbf" seems like a better policy?
16917:43 <sipa> Because in that case it is indeed so that -mempoolfullrbf is just opting in to both more extra outbound, AND extra inbound connections.
17017:44 <Kaizen_Kintsugi_> Isn't falseified service flags solved with thompson sampling?
17117:44 <ariard> sipa: well you could have automated replacement probing logic with GETDATA(replacement_txid), though somehow are we already doing assumptions by "trusting" the version announced by our peers, and the service supported?
17217:44 <ariard> like I could announce bip152 and never actually send you compact blocks
17317:44 <instagibbs> _aj_, increased risk of eclipse attacks when number of rbf peers are low... in Segwit case, you REALLY WANT to connect to segwit outbound
17417:44 <larryruane_> lightlike: "Is the logic different ..." yes, If we receive a version message from a node directly, we simply set our cache of its service bits directly.... if we hear about the node indirectly (addrman), we OR in the service bits
17517:44 <larryruane_> I think that makes sense because the addr message that we receive could be out of date, so treat it as if it MIGHT have the flag enabled; we'll find out for sure when we connect
17617:45 <_aj_> instagibbs: user-resisted-policy-change where everyone announces full-rbf-support but doesn't actually do it?
17717:45 <ariard> glozow: well as it doesn't remove the grief, the full-rbf node operators wouldn't have an incentive to turn it on, I think it make it harder to build economic majority
17817:45 <glozow> ariard: but probing doesn't work either, what if they increased their incremental relay feerate and rejected the tx for a fee reason? we can't go around disconnecting peers for not having the same txns as us
17917:45 <lightlike> larryruane_: exactly!
18017:45 <ariard> at least full-rbf node operators interested to be protected against the multi-party funded transaction DoS thing
18117:46 <lightlike> Next q: With this in mind, do you think that false signaling of a NODE_REPLACE_BY_FEE service flag could be problem? Could it be detected and punished?
18217:46 <sipa> ariard: tx relay policy being unenforcable is a reason to not bother with any of this and just making -mempoolfullrbf default at some point, IMHO. It's weird to have a service flag for just a relay policy. Using this approach as a stepping stone to appease politics "but look it's already deployed and works" doesn't mean much: *of course* it'll work for nodes that turn this on. Doing this just to create effectively a secondary P2P network with fullrbf
18317:46 <sipa> semantics isn't as useful as the real thing.
18417:46 <instagibbs> _aj_, sybil group spins up signaling nodes :shrug:
18517:46 <Kaizen_Kintsugi_> noob question: nodes don't advertise their relay fee rate?
18617:46 <instagibbs> whoever these evil people are
18717:47 <instagibbs> maybe they actually relay double spends, but they're also slowing down blocks
18817:47 <instagibbs> Kaizen_Kintsugi_, they advertise a mempool minfee, "fee filter"
18917:47 <sipa> Kaizen_Kintsugi_: Yes, BIP133. But that's the other way around: it is telling other nodes "don't bother sending me txn with fee below Y, because I'll just discard them anyway".
19017:47 <sipa> It's a courtesy bandwidth optimization.
19117:47 <Kaizen_Kintsugi_> ty insta & spia
19217:48 <Kaizen_Kintsugi_> *sipa
19317:48 <ariard> _aj_: from petertodd exp, apparently there wasn't evil full-rbf back in the days of 2015/2016 when actually that change was far more contentious
19417:48 <larryruane_> sipa: does that enable fingerprinting attacks?
19517:48 <lightlike> I think there are different ways of false signaling: Nodes that don't want full-RBF to work should (game-theoretically) false signal full-RBF, so that others looking for preferential peers will connect to them.
19617:49 <sipa> game-theoretically, I think nodes should enable -mempoolfullrbf exactly based on 1 criterion: whether miners also do.
19717:49 <instagibbs> lightlike, the response to this is mass-connecting to nodes to gossip double-spends :(
19817:49 <ariard> glozow: sure, i think we can never have absolute certainty of transaction acceptance at equivalent policy and resources setting (same mempool size) just becaouse you might have seen transactions, not seen on my side
19917:49 <sipa> Oh, other kind of problem. Yeah, I agree with lightlike's point as well.
20017:49 <ariard> we might at best increase the certainty
20117:49 <glozow> larryruane_: the fee filter is not exact, so not really
20217:50 <sipa> yeah the fee filter has some deliberate rounding in it to avoid being a huge fingerprinting vector.
20317:51 <ariard> sipa: IMHO, this is where I'm differing in the sense that might have in the future controversial or not-clear-best-trade-off policy rules, adopting the release practice of offering options to node operators let us better accomodate an increasing variety of Bitcoin applications like L2, with different requirements
20417:51 <larryruane_> sipa: glozow: thanks, so it's a way to somewhat increase the anonymity set
20517:51 <_aj_> so if the idea is "have a service bit, so that we can see how many people turn this feature on" and then say "oh, it's reached x% of the network and miners are mining it, we'll make it the default" -- there's less incentive for opponents to false signal support
20617:51 <lightlike> also, there is the possibility of someone spamming the node with existing legit addrs, but adding the FULLRBF service bit to the existing legitimate sevice flags (so other nodes would add it in therir addrman). If that happens, nodes might have problems to find legitimate full-RBF peers because everyone is full-RBF.
20717:52 <lightlike> (I think that's what sipa said before)
20817:52 <sipa> ariard: Operators already have that option, they can run other software. We should make software that works best for our users.
20917:52 <davidjumberj> What are the concerns about full-RBF by default that make having an intermediate step beneficial?
21017:53 <Kaizen_Kintsugi_> @_aj_: yea I like the idea of these softvotes
21117:53 <glozow> _aj_: not sure if that's the idea? that's pretty sybil-able?
21217:53 <ariard> sipa: and what are our users? a dynamic answer in function of new types of applications deployed
21317:53 <instagibbs> davidjumberj, perhaps everyone in this room is mistaken, and all users actively reject the idea? status quo reigns
21417:53 <sipa> If miners are permitting fullrbf, then so should bitcoin core.
21517:54 <sipa> Whether that's the case today, I don't know.
21617:54 <larryruane_> davidjumberj: that's a great question, the only thing I can think of is in case there's some attack or DoS that no one anticipated, so may be better to go slowly?
21717:54 <ariard> _aj_: yes this is the idea, being able to observe in Y time how many X% of the network have turn it on, without us enforcing a default on our users, not necessarily matching their application requirements
21817:54 <sipa> The point of the mempool is being a prediction for what will be mined. We should use all knowledge available to us to form that prediction.
21917:54 <_aj_> sipa: (i'm confused: doesn't the VERSION message include the service bits, so you could verify if the addr was misleading/outdated that way?)
22017:54 <ariard> instagibbs: exactly, perhaps all users or a strong set of them actively reject the idea
22117:55 <_aj_> sipa: "If miners are permitting fullrbf," -- speedy trial time? :-P
22217:55 <instagibbs> If an opt-in system goes forward and double-spending because easy(we can measure this?), then to me that's a non-rejection of the idea, and can become standard
22317:55 <lightlike> sipa: is it known if miners actually have an opinion on this? I'm afraids some might just lazily permit full-RBF as a reaction of bitcoin core making it the default?
22417:55 <instagibbs> Maybe that's too cautious
22517:55 <instagibbs> but that's an argument
22617:55 <sipa> _aj_: Yes, that's what made me agree above with your devil's advocate argument. If the code does drop connections to intended fullrbf peers, which turn out to not be fullrbf peers (by their own claims), then my argument about increased resource usage goes away.
22717:56 <glozow> if we told miners "hey, you can earn more fees if you use -mempoolfullrbf," would they not turn it on?
22817:56 <Kaizen_Kintsugi_> I think they would
22917:56 <sipa> I'd hope so, but I don't know.
23017:56 <Kaizen_Kintsugi_> Does it impose a cost to them to do so?
23117:56 <_aj_> sipa: aha, you said "tells us they're not fullrbf somehow" which i took to mean implying a new "FULLRBF" p2p message or something
23217:56 <larryruane_> we don't really have a way to tell the miners anything, do we?
23317:57 <BlueMoon> I also believe they would.
23417:57 <ariard> _aj_: even if you enforce correspondence between version and addr service bits, the actual service offered by the service bits might be silently dropped or buggy by your peer
23517:57 <instagibbs> larryruane_, in an ideal case we would never know who miners are and they would never know about protocol updates :P
23617:57 <sipa> ariard: "silently dropped" how? Buggy... yes, peers can be buggy, we don't need to serve them when they are.
23717:58 <_aj_> glozow: the problem is others might say "fullrbf means our business will effectively shut down, and there'll be less bitcoin tx volume, so you'll make less money"
23817:58 <ariard> glozow: yeah advocating the economic advantages of full-rbf to miners, something part of the full-rbf release process i think
23917:59 <glozow> _aj_: I agree that's a concern, but think there are fewer and fewer businesses who absolutely cannot survive without relying on zeroconf. Or at least hope so 😅
24017:59 <sipa> _aj_: It could be a separate message, or looking at the service bits they send in VERSION. I'm not sure if the latter is always reliable (do we always set them? even when we think we're not reachable etc)?
24117:59 <ariard> instagibbs: "they would never know about protocol updates", well in the future miners might run multiple mempool, one for each RBF policy designable, as the economic efficiency of a RBF policy can be function of the transaction order of acceptance, i think
24218:00 <lightlike> ok, wrapping up - (my last question was already discussed anyway)
24318:00 <lightlike> thanks everyone - great discussion!
24418:00 <lightlike> #endmeeting