rich1.0npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hhttps://nostr.ae/npub17rld56k4365lfphyd8u8kwuejey5xcazdxptserx03wc4jc9g24stx9l2hnjumphttps://nostr.ae📅 Original date posted:2022-10-18 📝 Original message: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