rich1.0npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddhttps://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8ddnjumphttps://nostr.ae📅 Original date posted:2022-10-19 📝 Original message:> 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. Yes, this has been the crux of the conceptual discussion in #25600. > 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. In the present case, I don't think there is a real concern of a frivolous or half-baked lawsuit. My concern is rather the pretension to omniscience that we would adopt as Core devs w.r.t policy changes, as far from being a more closed, hermetic system like the p2p stack, it's interfacing with the operations of a number of Bitcoin applications and second-layer contracting protocols. As of today, I think this is still a relatively short process to analyze the implications of any policy changes on the major Bitcoin applications flows and L2s of the day (i.e mainly Lightning and coinjoins). I'm not sure this statement will stay true in a future with a growing fauna of L2s (i.e vaults, DLC-over-channel, peerswaps, etc), each presenting unique characteristics. How do we minimize the odds of policy-based disruptions for current Bitcoin softwares and users ? I don't have strong ideas, though I wish for the Core project to adopt a more open-ended and smooth approach to release context-rich policy changes. I aimed with #25353 and #25600 to experiment with such a smoother approach advocated for (rather than the last year proposal of turning on by default full-rbf, that was a wrong and missing context). I hope at least one good outcome of this gradual process has been to give time to Dario to publish a thoughtful standpoint for 0conf operators, of which at least I learnt a few interesting elements on the UX of such applications. > 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"). Yeah, I'm still valuing the mailing list as a kind of "broadcast-all" communication channel towards all the community stakeholders, though this is the perspective of a developer and I'm not sure business/services operators have the same communication habits. There is definitely a reflection to hold, if we, as Core devs, we should follow a better communication standard when we propose significant policy changes. And go the full-tour of Reddit AMA, podcasts and newsletters as suggested in my reply to Dario. It's hard to know if lack of vocal reactions on the mailing list or to the publication of optech newsletter signifies a lack of opposition, a lack of negatively impacted users or lack of interest from the wider community. Maybe we should have a formalized, bulletpoints -based for future policy changes, with clear time buffers and actions items, I don't know. > 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. In the present case, it's more a lack of feedback showing up until we start doing rcs, rather than a pretty closed-off way of doing things. That we should amend expected and already-merged changes in the function of feedback, I'm all for it in principle. The hard question is the set of decision heuristics to converge on to qualify such feedback as worthy to react on. Again in this case, we're doing some risk arbitrage (which I really dislike as a situation) between 0conf applications and multi-party funding flows of contracting protocols. Correcting our release process isn't free of implications as we're removing the risk burden on some class of use-case to pour it on a second class, in my opinion. Moreover, assuming we have to bind to reasonable communication standards which is an open question, I'm also worried we would also normalize the publication of very late feedback from community stakeholders. > 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. First, without more visibility brought back on the 0confs operations necessary to adapt their operations, two months might be considered as enough. 8 weeks is sensibly the release schedule followed by few open-source projects in the ecosystem. Second, the communication machine behind softforks activation sounds to be far more fine-tuned, or at least gather spontaneously community self-coordination than policy changes, and it would be reasonable to expect things to be slower with policy changes. However, I would agree you can have a quick adoption a day from another with one single well-crafted meme buzzing on Twitter. Social phenomenas don't offer the same degree of predictability than system engineering. How we cope up with that, as core devs, I don't know. > 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. I'm not sure if it has been established clearly, though as I announced on IRC two weeks ago, Dario reached out to me offline before publishing his mail. My recommendation to him have been immediately to adjoin 0confs services examples impacted, if possible with numbers on users affected and evaluation of engineering and operational effort if would request to adapt their use-cases, and inviting to publish on this venue, as business operators might not be used to with open-source process (I can disclose the correspondence if requested and with Dario approval). Goal was to collect the maximum of data points in our community decision-making process about full-rbf. Now this doesn't relieve us of finding a common ground on what should be a minimal bar to accept those points, how to value those data points, if we should take operators on their raw numbers or request the publication of "light" proofs like on-chain transactions, lightning invoices (everyone in business would take the happy measure showing the most active users possible). The question of what signals we should collect, and how we process them is a hard question in a decentralized and trust-minimized process like the Bitcoin development one, from my perspective. I don't have strong ideas there. Though speaking for myself, and not for other contributors, I've raised the warnings about potential impacts of full-rbfs in both my June 2021 [0] and June 2022 [1] mails, so I find the qualification of disingenuous is a bit ungrounded. Overall, I would remind all that it's better to keep patience in face of complex changes in Core, rather than to fall quickly in a blame ascription position. [0] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html (I don't deny "blame-and-reward" assignments can be worthy a posteriori, once we're out of the "hot" discussion phase, especially to introspect on how we can improve our engineering process, though in the middle of a discussion... I don't know, it sounds premature and noisy). > (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) I can share the sentiment about mainstream economics and the way risk-management impacts large-range of human beings is completely shrug on... Though again in the present case, I think it would be more productive to describe what engineering needs or standards expectations of you are not fulfilled rather than to fallback on the pure expression of an uncomfortableness and how as a community of contributors we could improve on that. Though to object, speaking of risk appreciation, not hardening the funding phase of multi-party funding protocols also lets the door open to DoS attacks by deanonymizing attackers targeting things like coinjoin. > 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? I agree. I would like to observe that "reasonable time to react" and "adequate risk statement" is more an art than a science. > 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"). About John Carvalho disagreeing about full-rbf, I think he voiced a concern during the summer on one of the PR introducing a full-rbf setting and I did invite to voice his concerns on the ML, invitation stayed without follow-up until the recent days [2] [3]. I would have loved to spend time back then arguing on the full-rbf and miners incentives compatibility. [2] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654 [3] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163815017 I know we all have busy agendas and a short timeline to react to all the changes happening in the Bitcoin ecosystem... I think I replied to John Carvalho answer on this thread, inviting him to develop his argumentation further and I'm staying available to discuss with any full-rbf opponents, in a calm and respectful fashion [4]. [4] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021027.html > 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. Yeah I mean this could have been a forward process before Dario published his thoughts. Achieving 5%-20% hashpower and full-rbf relay paths would have assumed landing #25600 _and_ actually reach out to few mining pools to inform them about the potential economic benefits. Now, I think the best process is to keep listening to more feedback from the community, lay out all the deployment options in code we have done and think more before committing to something. > 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 think this might be the point where I could say we're diverging. In principle, I agree we should listen to negative feedback raising harmful disruptions risks for users and services. The more open, practical question to me is more how we collect, qualify and sanitize such negative feedback in a way which is acceptable for the community at large. Giving concrete bounds to the immediate dangers in a consensual way, and asserting this danger results from a lack of communication of the Core project, I'm still wondering on those subjects. And note again, I didn't deny the option 3) approach as you laid out was zero-risk for 0conf operators. All that said, if we think as a project we should offer a "zero-risk" process towards 0conf operators w.r.t full-rbf, at the detriment of the risk encumbered by contracting protocols, I think it can be wise to resurrect #26287. Best, Antoine Le mar. 18 oct. 2022 à 03:00, Anthony Towns <aj at erisian.com.au> a écrit : > 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 > > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/f492c8c2/attachment-0001.html>