{"type":"rich","version":"1.0","author_name":"npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","author_url":"https://nostr.ae/npub1vjzmc45k8dgujppapp2ue20h3l9apnsntgv4c0ukncvv549q64gsz4x8dd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2022-10-19\n📝 Original message:\u003e Full RBF doesn't need a majority or unanimity to have an impact; it needs\n\u003e adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of\n\u003e a 10MvB mempool can be replaced before being mined naturally), and some\n\u003e way of finding a working path to relay txs to that hashrate.\n\nYes, this has been the crux of the conceptual discussion in #25600.\n\n\u003e I mean, I guess I can understand wanting to reduce that responsibility\n\u003e for maintainers of the github repo, even if for no other reason than to\n\u003e avoid frivolous lawsuits, but where do you expect people to find better\n\u003e advice about what things are a good/bad idea if core devs as a whole\n\u003e are avoiding that responsibility?\n\u003e\n\u003e Core devs are supposedly top technical experts at bitcoin -- which means\n\u003e they're the ones that should have the best understanding of all the\n\u003e implications of policy changes like this. Is opt-in RBF only fine? If\n\u003e you look at the network today, it sure seems like it; it takes a pretty\n\u003e good technical understanding to figure out what problems it has, and\n\u003e an even better one to figure out whether those problems can be solved\n\u003e while keeping an opt-in RBF regime, or if full RBF is needed.\n\nIn the present case, I don't think there is a real concern of a frivolous\nor half-baked lawsuit. My concern is rather the pretension to omniscience\nthat we would adopt as Core devs w.r.t policy changes, as far from being a\nmore closed, hermetic system like the p2p stack, it's interfacing with the\noperations of a number of Bitcoin applications and second-layer contracting\nprotocols. As of today, I think this is still a relatively short process to\nanalyze the implications of any policy changes on the major Bitcoin\napplications\nflows and L2s of the day (i.e mainly Lightning and coinjoins). I'm not sure\nthis statement will stay true in a future with a growing fauna of L2s (i.e\nvaults, DLC-over-channel, peerswaps, etc), each presenting unique\ncharacteristics.\n\nHow do we minimize the odds of policy-based disruptions for current Bitcoin\nsoftwares and users ? I don't have strong ideas, though I wish for the Core\nproject to adopt a more open-ended and smooth approach to release\ncontext-rich policy changes. I aimed with #25353 and #25600 to experiment\nwith such a smoother approach advocated for (rather than the last year\nproposal of turning on by default full-rbf, that was a wrong and missing\ncontext). I hope at least one good outcome of this gradual process has been\nto give time to Dario to publish a thoughtful standpoint for 0conf\noperators, of which at least I learnt a few interesting elements on the UX\nof such applications.\n\n\u003e It's a bit disappointing that the people that's a problem for didn't\n\u003e engage earlier -- though looking back, I guess there wasn't all that\n\u003e much effort made to reach out, either. There were two mentions in the\n\u003e optech newsletter [3] [4] but it wasn't called out as an \"action item\"\n\u003e (maybe those aren't a thing anymore), so it may have been pretty missable,\n\u003e especially given RBF has been discussed on and off for so long. And the\n\u003e impression I got from the PR review club discussion more seemed like\n\u003e devs making assumptions about businesses rather than having talked to\n\u003e them (eg \"[I] think there are fewer and fewer businesses who absolutely\n\u003e cannot survive without relying on zeroconf. Or at least hope so\").\n\nYeah, I'm still valuing the mailing list as a kind of \"broadcast-all\"\ncommunication channel towards all the community stakeholders, though this\nis the perspective of a developer and I'm not sure business/services\noperators have the same communication habits. There is definitely a\nreflection to hold, if we, as Core devs, we should follow a better\ncommunication standard when we propose significant policy changes. And go\nthe full-tour of Reddit AMA, podcasts and newsletters as suggested in my\nreply to Dario. It's hard to know if lack of vocal reactions on the mailing\nlist or to the publication of optech newsletter signifies a lack of\nopposition, a lack of negatively impacted users or lack of interest from\nthe wider community. Maybe we should have a formalized, bulletpoints -based\nfor future policy changes, with clear time buffers and actions items, I\ndon't know.\n\n\u003e If we're happy to not get feedback until we start doing rcs, that's fine;\n\u003e but if we want to say \"oops, we're into release candidates, you should\n\u003e have something earlier, it's too late now\", that's a pretty closed-off\n\u003e way of doing things.\n\u003e\n\u003e And I mean: all this is only about drawing a line in *sand*; if people\n\u003e think core devs are wrong, they can still let that line blow away in\n\u003e the wind, by running different software, configuring core differently,\n\u003e patching core, or whatever else.\n\nIn the present case, it's more a lack of feedback showing up until we start\ndoing rcs, rather than a pretty closed-off way of doing things. That we\nshould amend expected and already-merged changes in the function of\nfeedback, I'm all for it in principle. The hard question is the set of\ndecision heuristics to converge on to qualify such feedback as worthy to\nreact on. Again in this case, we're doing some risk arbitrage (which I\nreally dislike as a situation) between 0conf applications and multi-party\nfunding flows of contracting protocols. Correcting our release process\nisn't free of implications as we're removing the risk burden on some class\nof use-case to pour it on a second class, in my opinion. Moreover, assuming\nwe have to bind to reasonable communication standards which is an open\nquestion, I'm also worried we would also normalize the publication of very\nlate feedback from community stakeholders.\n\n\u003e I don't think that's remotely true: take a look at taproot activation:\n\u003e it took two months between releasing code that supported signalling and\n\u003e having 98% of hashrate signalling; with 40% of blocks signalling within\n\u003e the first two weeks.\n\nFirst, without more visibility brought back on the 0confs operations\nnecessary to adapt their operations, two months might be considered as\nenough. 8 weeks is sensibly the release schedule followed by few\nopen-source projects in the ecosystem. Second, the communication machine\nbehind softforks activation sounds to be far more fine-tuned, or at least\ngather spontaneously community self-coordination than policy changes, and\nit would be reasonable to expect things to be slower with policy changes.\nHowever, I would agree you can have a quick adoption a day from another\nwith one single well-crafted meme buzzing on Twitter. Social phenomenas\ndon't offer the same degree of predictability than system engineering. How\nwe cope up with that, as core devs, I don't know.\n\n\u003e But if the line in the sand is \"we're doing this, no matter how much that\n\u003e increases the risk to existing businesses that weren't expecting it\" then\n\u003e it seems *very* disingenuous not to make those risks very clear so that\n\u003e people who weren't expecting it actually take action to avoid those risks.\n\nI'm not sure if it has been established clearly, though as I announced on\nIRC two weeks ago, Dario reached out to me offline before publishing his\nmail. My recommendation to him have been immediately to adjoin 0confs\nservices examples impacted, if possible with numbers on users affected and\nevaluation of engineering and operational effort if would request to adapt\ntheir use-cases, and inviting to publish on this venue, as business\noperators might not be used to with open-source process (I can disclose the\ncorrespondence if requested and with Dario approval).\n\nGoal was to collect the maximum of data points in our community\ndecision-making process about full-rbf. Now this doesn't relieve us of\nfinding a common ground on what should be a minimal bar to accept those\npoints, how to value those data\npoints, if we should take operators on their raw numbers or request the\npublication of \"light\" proofs like on-chain transactions, lightning\ninvoices (everyone in business would take the happy measure showing the\nmost active users possible). The question of what signals we should\ncollect, and how we process them is a hard question in a decentralized and\ntrust-minimized process like the Bitcoin development one, from my\nperspective. I don't have strong ideas there.\n\nThough speaking for myself, and not for other contributors, I've raised the\nwarnings about potential impacts of full-rbfs in both my June 2021 [0] and\nJune 2022 [1] mails, so I find the qualification of disingenuous is a bit\nungrounded. Overall, I would remind all that it's better to keep patience\nin face of complex changes in Core, rather than to fall quickly in a blame\nascription position.\n\n[0]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-June/019074.html\n[1]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html\n\n(I don't deny \"blame-and-reward\" assignments can be worthy a posteriori,\nonce we're out of the \"hot\" discussion phase, especially to introspect on\nhow we can improve our engineering process, though in the middle of a\ndiscussion... I don't know, it sounds premature and noisy).\n\n\u003e (More generally, that's similar to one of the things I've hated\n\u003e watching in mainstream economics over the past few years: \"doing this\n\u003e will cause massive inflation\" \"no it won't, there's no inflation risk\"\n\u003e \"oops, inflation magically appeared, how did that happen? oh well, too\n\u003e bad, we have to live with it now\". This looks pretty similar to me: \"do\n\u003e something risky, deny the risk, make sure nobody can hold us accountable\n\u003e when the risk eventuates later\" so it makes me really uncomfortable)\n\nI can share the sentiment about mainstream economics and the way\nrisk-management impacts large-range of human beings is completely shrug\non... Though again in the present case, I think it would be more productive\nto describe what engineering\nneeds or standards expectations of you are not fulfilled rather than to\nfallback on the pure expression of an uncomfortableness and how as a\ncommunity of contributors we could improve on that. Though to object,\nspeaking of risk appreciation, not hardening the funding phase of\nmulti-party funding protocols also lets the door open to DoS attacks by\ndeanonymizing attackers targeting things like coinjoin.\n\n\u003e Sure; that's a fine reason to draw the line in the sand. But it's not\n\u003e a good reason to have it happen immediately, rather than giving people\n\u003e time to react, and it's not a good reason to understate the risk of\n\u003e it happening now. Maybe there are good reasons for either or both of\n\u003e those, though?\n\nI agree. I would like to observe that \"reasonable time to react\" and\n\"adequate risk statement\" is more an art than a science.\n\n\u003e Using the passive voice there doesn't seem helpful. Who learnt these\n\u003e things? You, I and Dario all seem to agree with (a), but John Carvalho\n\u003e certainly appears not to, for instance. I'm not sure who agrees with\n\u003e (b) -- I know I do, and I think Dario does; but multiple people seem\n\u003e opposed to the clear timeline offered in #26323, and your #26305 seems\n\u003e more likely to encourage a \"pollination\" approach rather than discourage\n\u003e it (\"oh, this will be the default option for 25.0, might as well enable\n\u003e it now like all the cool kids are\").\n\nAbout John Carvalho disagreeing about full-rbf, I think he voiced a concern\nduring the summer on one of the PR introducing a full-rbf setting and I did\ninvite to voice his concerns on the ML, invitation stayed without follow-up\nuntil the recent days [2] [3]. I would have loved to spend time back then\narguing on the full-rbf and miners incentives compatibility.\n\n[2] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163422654\n[3] https://github.com/bitcoin/bitcoin/pull/25373#issuecomment-1163815017\n\nI know we all have busy agendas and a short timeline to react to all the\nchanges happening in the Bitcoin ecosystem... I think I replied to John\nCarvalho answer on this thread, inviting him to develop his argumentation\nfurther and I'm staying available to discuss with any full-rbf opponents,\nin a calm and respectful fashion [4].\n\n[4]\nhttps://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021027.html\n\n\u003e For what it's worth, my guess is that releasing core with full rbf\n\u003e support and having you and Murch and others advocating for people to\n\u003e try it out, will mean that full RBF is usable on mainnet within two\n\u003e or three months, supported by perhaps 5%-20% hashpower, but probably\n\u003e still requiring special effort to actually find a peer that can relay\n\u003e full rbf txs to that hashpower (probably doing an addnode, despite the\n\u003e privacy implications). Even if that happens, I'm not super confident\n\u003e that it would mean people would actively steal from zeroconf businesses\n\u003e in any volume, though. It's not something I'd risk happening to me,\n\u003e but accepting zeroconf from strangers isn't something I'd risk anyway.\n\nYeah I mean this could have been a forward process before Dario published\nhis thoughts. Achieving 5%-20% hashpower and full-rbf relay paths would\nhave assumed landing #25600 _and_ actually reach out to few mining pools to\ninform them about the potential economic benefits. Now, I think the best\nprocess is to keep listening to more feedback from the community, lay out\nall the deployment options in code we have done and think more before\ncommitting to something.\n\n\u003e And if the choice is between \"bikeshedding\" and \"merge a PR, then ignore\n\u003e feedback that it's harmful\", I'd much rather the bikeshedding. What's\n\u003e the point of having rcs if you're going to ignore negative feedback?\n\nI think this might be the point where I could say we're diverging. In\nprinciple, I agree we should listen to negative feedback raising harmful\ndisruptions risks for users and services. The more open, practical question\nto me is more how we collect, qualify and sanitize such negative feedback\nin a way which is acceptable for the community at large. Giving concrete\nbounds to the immediate dangers in a consensual way, and asserting this\ndanger results from a lack of communication of the Core project, I'm still\nwondering on those subjects. And note again, I didn't deny the option 3)\napproach as you laid out was zero-risk for 0conf operators.\n\nAll that said, if we think as a project we should offer a \"zero-risk\"\nprocess towards 0conf operators w.r.t full-rbf, at the detriment of the\nrisk encumbered by contracting protocols, I think it can be wise to\nresurrect #26287.\n\nBest,\nAntoine\n\nLe mar. 18 oct. 2022 à 03:00, Anthony Towns \u003caj at erisian.com.au\u003e a écrit :\n\n\u003e On Mon, Oct 17, 2022 at 05:41:48PM -0400, Antoine Riard via bitcoin-dev\n\u003e wrote:\n\u003e \u003e \u003e  1) Continue supporting and encouraging accepting unconfirmed\n\u003e \"on-chain\"\n\u003e \u003e \u003e     payments indefinitely\n\u003e \u003e \u003e  2) Draw a line in the sand now, but give people who are currently\n\u003e \u003e \u003e     accepting unconfirmed txs time to update their software and\n\u003e business\n\u003e \u003e \u003e     model\n\u003e \u003e \u003e  3) Encourage mainnet miners and relay nodes to support unconditional\n\u003e \u003e \u003e     RBF immediately, no matter how much that increases the risk to\n\u003e \u003e \u003e     existing businesses that are still accepting unconfirmed txs\n\u003e \u003e To give more context, the initial approach of enabling full RBF through\n\u003e \u003e #25353 + #25600 wasn't making the assumption the enablement itself would\n\u003e \u003e reach agreement of the economic majority or unanimity.\n\u003e\n\u003e Full RBF doesn't need a majority or unanimity to have an impact; it needs\n\u003e adoption by perhaps 10% of hashrate (so a low fee tx at the bottom of\n\u003e a 10MvB mempool can be replaced before being mined naturally), and some\n\u003e way of finding a working path to relay txs to that hashrate.\n\u003e\n\u003e Having a majority of nodes/hashrate support it makes the upsides better,\n\u003e but doesn't change the downsides to the people who are relying on it\n\u003e not being available.\n\u003e\n\u003e \u003e Without denying that such equilibrium would be unstable, it was designed\n\u003e to\n\u003e \u003e remove the responsibility of the Core project itself to \"draw a hard\n\u003e line\"\n\u003e \u003e on the subject.\n\u003e\n\u003e Removing responsibility from core developers seems like it's very much\n\u003e optimising for the wrong thing to me.\n\u003e\n\u003e I mean, I guess I can understand wanting to reduce that responsibility\n\u003e for maintainers of the github repo, even if for no other reason than to\n\u003e avoid frivolous lawsuits, but where do you expect people to find better\n\u003e advice about what things are a good/bad idea if core devs as a whole\n\u003e are avoiding that responsibility?\n\u003e\n\u003e Core devs are supposedly top technical experts at bitcoin -- which means\n\u003e they're the ones that should have the best understanding of all the\n\u003e implications of policy changes like this. Is opt-in RBF only fine? If\n\u003e you look at the network today, it sure seems like it; it takes a pretty\n\u003e good technical understanding to figure out what problems it has, and\n\u003e an even better one to figure out whether those problems can be solved\n\u003e while keeping an opt-in RBF regime, or if full RBF is needed.\n\u003e\n\u003e At that point, the technical experts *should* be coming up with a\n\u003e specific recommendation, and, personally, I think that's exactly what\n\u003e happened with [0] [1] and [2].\n\u003e\n\u003e [0]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/003033.html\n\u003e [1] https://github.com/bitcoin/bitcoin/pull/25353\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html\n\u003e\n\u003e That did draw hard line in the sand: it said \"hey, opt-in RBF had a good\n\u003e run, but it's time to switch over to full RBF, for these reasons\".\n\u003e\n\u003e It's a bit disappointing that the people that's a problem for didn't\n\u003e engage earlier -- though looking back, I guess there wasn't all that\n\u003e much effort made to reach out, either. There were two mentions in the\n\u003e optech newsletter [3] [4] but it wasn't called out as an \"action item\"\n\u003e (maybe those aren't a thing anymore), so it may have been pretty missable,\n\u003e especially given RBF has been discussed on and off for so long. And the\n\u003e impression I got from the PR review club discussion more seemed like\n\u003e devs making assumptions about businesses rather than having talked to\n\u003e them (eg \"[I] think there are fewer and fewer businesses who absolutely\n\u003e cannot survive without relying on zeroconf. Or at least hope so\").\n\u003e\n\u003e [3] https://bitcoinops.org/en/newsletters/2022/06/22/\n\u003e [4] https://bitcoinops.org/en/newsletters/2022/07/13/\n\u003e\n\u003e If we're happy to not get feedback until we start doing rcs, that's fine;\n\u003e but if we want to say \"oops, we're into release candidates, you should\n\u003e have something earlier, it's too late now\", that's a pretty closed-off\n\u003e way of doing things.\n\u003e\n\u003e And I mean: all this is only about drawing a line in *sand*; if people\n\u003e think core devs are wrong, they can still let that line blow away in\n\u003e the wind, by running different software, configuring core differently,\n\u003e patching core, or whatever else.\n\u003e\n\u003e \u003e Moreover, relying on node operators turning on the setting\n\u003e \u003e provides a smoother approach offering time to zero-conf services to react\n\u003e \u003e in consequence.\n\u003e\n\u003e I don't think that's remotely true: take a look at taproot activation:\n\u003e it took two months between releasing code that supported signalling and\n\u003e having 98% of hashrate signalling; with 40% of blocks signalling within\n\u003e the first two weeks.\n\u003e\n\u003e \u003e So the current path definitely belongs more to a 3) approach.\n\u003e\n\u003e \u003e \u003e  3) Encourage mainnet miners and relay nodes to support unconditional\n\u003e \u003e \u003e     RBF immediately, no matter how much that increases the risk to\n\u003e \u003e \u003e     existing businesses that are still accepting unconfirmed txs\n\u003e\n\u003e Yes, that's how it appears to me, too. It's not my preference (giving\n\u003e people clear warning of changes seems much better to me), but I can\n\u003e certainly live with it.\n\u003e\n\u003e But if the line in the sand is \"we're doing this, no matter how much that\n\u003e increases the risk to existing businesses that weren't expecting it\" then\n\u003e it seems *very* disingenuous not to make those risks very clear so that\n\u003e people who weren't expecting it actually take action to avoid those risks.\n\u003e\n\u003e That is, it seems to me that Dario was exactly right in titling this\n\u003e thread \"Zero-conf apps in immediate danger\", and our co-developers who\n\u003e are dismissing the risk by saying things along the lines of \"probably\n\u003e nothing will change anytime soon\" are exactly wrong.\n\u003e\n\u003e (More generally, that's similar to one of the things I've hated\n\u003e watching in mainstream economics over the past few years: \"doing this\n\u003e will cause massive inflation\" \"no it won't, there's no inflation risk\"\n\u003e \"oops, inflation magically appeared, how did that happen? oh well, too\n\u003e bad, we have to live with it now\". This looks pretty similar to me: \"do\n\u003e something risky, deny the risk, make sure nobody can hold us accountable\n\u003e when the risk eventuates later\" so it makes me really uncomfortable)\n\u003e\n\u003e \u003e While this\n\u003e \u003e way cannot be denied to be a zero-risk deployment for business accepting\n\u003e \u003e unconfirmed transactions, it should be weighed in face of multi-party\n\u003e \u003e contracting protocols encumbering an annoying pinning vector.\n\u003e\n\u003e Sure; that's a fine reason to draw the line in the sand. But it's not\n\u003e a good reason to have it happen immediately, rather than giving people\n\u003e time to react, and it's not a good reason to understate the risk of\n\u003e it happening now. Maybe there are good reasons for either or both of\n\u003e those, though?\n\u003e\n\u003e \u003e Since Dario's mail, I think we have learnt new data points, a) on the\n\u003e long\n\u003e \u003e term full RBF to align miner incentives is acknowledged and b) a clear\n\u003e \u003e timeline based on e.g a block height is favored over the pollination\n\u003e \u003e deployment.\n\u003e\n\u003e Using the passive voice there doesn't seem helpful. Who learnt these\n\u003e things? You, I and Dario all seem to agree with (a), but John Carvalho\n\u003e certainly appears not to, for instance. I'm not sure who agrees with\n\u003e (b) -- I know I do, and I think Dario does; but multiple people seem\n\u003e opposed to the clear timeline offered in #26323, and your #26305 seems\n\u003e more likely to encourage a \"pollination\" approach rather than discourage\n\u003e it (\"oh, this will be the default option for 25.0, might as well enable\n\u003e it now like all the cool kids are\").\n\u003e\n\u003e For what it's worth, my guess is that releasing core with full rbf\n\u003e support and having you and Murch and others advocating for people to\n\u003e try it out, will mean that full RBF is usable on mainnet within two\n\u003e or three months, supported by perhaps 5%-20% hashpower, but probably\n\u003e still requiring special effort to actually find a peer that can relay\n\u003e full rbf txs to that hashpower (probably doing an addnode, despite the\n\u003e privacy implications). Even if that happens, I'm not super confident\n\u003e that it would mean people would actively steal from zeroconf businesses\n\u003e in any volume, though. It's not something I'd risk happening to me,\n\u003e but accepting zeroconf from strangers isn't something I'd risk anyway.\n\u003e\n\u003e Slowing that down from January-ish to May seems like it ought to be a\n\u003e big win for anyone who has been doing zeroconf, and having it be easy\n\u003e to find a path to miners when it is supported seems like a big win even\n\u003e given a cost of a few months delay.\n\u003e\n\u003e OTOH, if we're really not expecting full rbf to be available for many\n\u003e months, then I would have expected the \"disable this for mainnet,\n\u003e reconsider after the release\" PR (#26287) to have gone ahead already.\n\u003e\n\u003e \u003e Tie-breaking between\n\u003e \u003e both, I believe I would favor something like #26323 though only post 24.0\n\u003e \u003e to avoid introducing a bikeshedding precedent in terms of release\n\u003e process,\n\u003e\n\u003e Doing something like #26323 only after 24.0 is out does nothing to\n\u003e mitigate whatever immediate risk there is to bitcoin businesses/users...\n\u003e\n\u003e And if the choice is between \"bikeshedding\" and \"merge a PR, then ignore\n\u003e feedback that it's harmful\", I'd much rather the bikeshedding. What's\n\u003e the point of having rcs if you're going to ignore negative feedback?\n\u003e\n\u003e I mean, if you think the feedback is wrong, that's different: maybe we\n\u003e shouldn't care that zeroconf apps are in immediate danger, and maybe\n\u003e bitcoin would be better if any that don't adapt immediately all die\n\u003e horribly as a lesson to others not to make similarly bad assumptions.\n\u003e\n\u003e But saying \"we don't want them to be in danger\" and also refusing to do\n\u003e anything to avoid it?\n\u003e\n\u003e Cheers,\n\u003e aj\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221018/f492c8c2/attachment-0001.html\u003e"}