Hi aj, > I mean, I guess I can understand wanting to reduce that responsibility > for maintainers of the github repo, even if for no other reason than to > avoid frivolous lawsuits, but where do you expect people to find better > advice about what things are a good/bad idea if core devs as a whole > are avoiding that responsibility?
Bitcoin Core contributors and maintainers should provide the options, recommendations etc. about mempool policies. If these policies are kept for users to change based on their needs, why force anything or change defaults ignoring feedback? > Core devs are supposedly top technical experts at bitcoin -- which means > they're the ones that should have the best understanding of all the > implications of policy changes like this. Why even provide options for users to change RBF policy in that case? Option to disable was already [removed][1] ignoring NACKs and MarcoFalke prefers users try the [workaround][2] if there is ever a need to disable it. Are we going to remove all the options to switch RBF policies in future because fullrbf has been suggested by leading technical experts? Is there a possibility of experts going wrong and has it ever happened in past? > It's a bit disappointing that the people that's a problem for didn't > engage earlier -- though looking back, I guess there wasn't all that > much effort made to reach out, either. To be fair, John Carvalho did [comment][3] about this in a pull request although it was wrong PR and never going to be merged. > And I mean: all this is only about drawing a line in sand; if people > think core devs are wrong, they can still let that line blow away in > the wind, by running different software, configuring core differently, > patching core, or whatever else. I think this is the best option for users at this point. Keep running older versions of Core and use Knots or other implementations until technical experts in core repository, other bitcoin projects and users are on the same page. > And the > impression I got from the PR review club discussion more seemed like > devs making assumptions about businesses rather than having talked to > them (eg "[I] think there are fewer and fewer businesses who absolutely > cannot survive without relying on zeroconf. Or at least hope so"). Even I noticed this since I don't recall the developers of the 3 main coinjoin implementations that are claimed to be impacted by opt-in RBF making any remarks. [1]: https://github.com/bitcoin/bitcoin/pull/16171 [2]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1157846575 [3]: https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654 /dev/fd0 Sent with Proton Mail secure email. ------- Original Message ------- On Tuesday, October 18th, 2022 at 12:30 PM, Anthony Towns via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote: > On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev wrote: > > > > 1) Continue supporting and encouraging accepting unconfirmed "on-chain" > > > payments indefinitely > > > 2) Draw a line in the sand now, but give people who are currently > > > accepting unconfirmed txs time to update their software and business > > > model > > > 3) Encourage mainnet miners and relay nodes to support unconditional > > > RBF immediately, no matter how much that increases the risk to > > > existing businesses that are still accepting unconfirmed txs > > > To give more context, the initial approach of enabling full RBF through > > > #25353 + #25600 wasn't making the assumption the enablement itself would > > > reach agreement of the economic majority or unanimity. > > > Full RBF doesn't need a majority or unanimity to have an impact; it needs > adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of > a 10MvB mempool can be replaced before being mined naturally), and some > way of finding a working path to relay txs to that hashrate. > > Having a majority of nodes/hashrate support it makes the upsides better, > but doesn't change the downsides to the people who are relying on it > not being available. > > > Without denying that such equilibrium would be unstable, it was designed to > > remove the responsibility of the Core project itself to "draw a hard line" > > on the subject. > > > Removing responsibility from core developers seems like it's very much > optimising for the wrong thing to me. > > I mean, I guess I can understand wanting to reduce that responsibility > for maintainers of the github repo, even if for no other reason than to > avoid frivolous lawsuits, but where do you expect people to find better > advice about what things are a good/bad idea if core devs as a whole > are avoiding that responsibility? > > Core devs are supposedly top technical experts at bitcoin -- which means > they're the ones that should have the best understanding of all the > implications of policy changes like this. Is opt-in RBF only fine? If > you look at the network today, it sure seems like it; it takes a pretty > good technical understanding to figure out what problems it has, and > an even better one to figure out whether those problems can be solved > while keeping an opt-in RBF regime, or if full RBF is needed. > > At that point, the technical experts should be coming up with a > specific recommendation, and, personally, I think that's exactly what > happened with [0] [1] and [2]. > > [0] > https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html > [1] https://github.com/bitcoin/bitcoin/pull/25353 > [2] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html > > That did draw hard line in the sand: it said "hey, opt-in RBF had a good > run, but it's time to switch over to full RBF, for these reasons". > > It's a bit disappointing that the people that's a problem for didn't > engage earlier -- though looking back, I guess there wasn't all that > much effort made to reach out, either. There were two mentions in the > optech newsletter [3] [4] but it wasn't called out as an "action item" > (maybe those aren't a thing anymore), so it may have been pretty missable, > especially given RBF has been discussed on and off for so long. And the > impression I got from the PR review club discussion more seemed like > devs making assumptions about businesses rather than having talked to > them (eg "[I] think there are fewer and fewer businesses who absolutely > cannot survive without relying on zeroconf. Or at least hope so"). > > [3] https://bitcoinops.org/en/newsletters/2022/06/22/ > [4] https://bitcoinops.org/en/newsletters/2022/07/13/ > > If we're happy to not get feedback until we start doing rcs, that's fine; > but if we want to say "oops, we're into release candidates, you should > have something earlier, it's too late now", that's a pretty closed-off > way of doing things. > > And I mean: all this is only about drawing a line in sand; if people > think core devs are wrong, they can still let that line blow away in > the wind, by running different software, configuring core differently, > patching core, or whatever else. > > > Moreover, relying on node operators turning on the setting > > provides a smoother approach offering time to zero-conf services to react > > in consequence. > > > I don't think that's remotely true: take a look at taproot activation: > it took two months between releasing code that supported signalling and > having 98% of hashrate signalling; with 40% of blocks signalling within > the first two weeks. > > > So the current path definitely belongs more to a 3) approach. > > > > 3) Encourage mainnet miners and relay nodes to support unconditional > > > RBF immediately, no matter how much that increases the risk to > > > existing businesses that are still accepting unconfirmed txs > > > Yes, that's how it appears to me, too. It's not my preference (giving > people clear warning of changes seems much better to me), but I can > certainly live with it. > > But if the line in the sand is "we're doing this, no matter how much that > increases the risk to existing businesses that weren't expecting it" then > it seems very disingenuous not to make those risks very clear so that > people who weren't expecting it actually take action to avoid those risks. > > That is, it seems to me that Dario was exactly right in titling this > thread "Zero-conf apps in immediate danger", and our co-developers who > are dismissing the risk by saying things along the lines of "probably > nothing will change anytime soon" are exactly wrong. > > (More generally, that's similar to one of the things I've hated > watching in mainstream economics over the past few years: "doing this > will cause massive inflation" "no it won't, there's no inflation risk" > "oops, inflation magically appeared, how did that happen? oh well, too > bad, we have to live with it now". This looks pretty similar to me: "do > something risky, deny the risk, make sure nobody can hold us accountable > when the risk eventuates later" so it makes me really uncomfortable) > > > While this > > way cannot be denied to be a zero-risk deployment for business accepting > > unconfirmed transactions, it should be weighed in face of multi-party > > contracting protocols encumbering an annoying pinning vector. > > > Sure; that's a fine reason to draw the line in the sand. But it's not > a good reason to have it happen immediately, rather than giving people > time to react, and it's not a good reason to understate the risk of > it happening now. Maybe there are good reasons for either or both of > those, though? > > > Since Dario's mail, I think we have learnt new data points, a) on the long > > term full RBF to align miner incentives is acknowledged and b) a clear > > timeline based on e.g a block height is favored over the pollination > > deployment. > > > Using the passive voice there doesn't seem helpful. Who learnt these > things? You, I and Dario all seem to agree with (a), but John Carvalho > certainly appears not to, for instance. I'm not sure who agrees with > (b) -- I know I do, and I think Dario does; but multiple people seem > opposed to the clear timeline offered in #26323, and your #26305 seems > more likely to encourage a "pollination" approach rather than discourage > it ("oh, this will be the default option for 25.0, might as well enable > it now like all the cool kids are"). > > For what it's worth, my guess is that releasing core with full rbf > support and having you and Murch and others advocating for people to > try it out, will mean that full RBF is usable on mainnet within two > or three months, supported by perhaps 5%-20% hashpower, but probably > still requiring special effort to actually find a peer that can relay > full rbf txs to that hashpower (probably doing an addnode, despite the > privacy implications). Even if that happens, I'm not super confident > that it would mean people would actively steal from zeroconf businesses > in any volume, though. It's not something I'd risk happening to me, > but accepting zeroconf from strangers isn't something I'd risk anyway. > > Slowing that down from January-ish to May seems like it ought to be a > big win for anyone who has been doing zeroconf, and having it be easy > to find a path to miners when it is supported seems like a big win even > given a cost of a few months delay. > > OTOH, if we're really not expecting full rbf to be available for many > months, then I would have expected the "disable this for mainnet, > reconsider after the release" PR (#26287) to have gone ahead already. > > > Tie-breaking between > > both, I believe I would favor something like #26323 though only post 24.0 > > to avoid introducing a bikeshedding precedent in terms of release process, > > > Doing something like #26323 only after 24.0 is out does nothing to > mitigate whatever immediate risk there is to bitcoin businesses/users... > > And if the choice is between "bikeshedding" and "merge a PR, then ignore > feedback that it's harmful", I'd much rather the bikeshedding. What's > the point of having rcs if you're going to ignore negative feedback? > > I mean, if you think the feedback is wrong, that's different: maybe we > shouldn't care that zeroconf apps are in immediate danger, and maybe > bitcoin would be better if any that don't adapt immediately all die > horribly as a lesson to others not to make similarly bad assumptions. > > But saying "we don't want them to be in danger" and also refusing to do > anything to avoid it? > > Cheers, > aj > > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
