Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) by lists.linuxfoundation.org (Postfix) with ESMTP id D38A5C002D for ; Wed, 19 Oct 2022 03:18:07 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 9E48F409FC for ; Wed, 19 Oct 2022 03:18:07 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 9E48F409FC Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=OU7qpT9K X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.101 X-Spam-Level: X-Spam-Status: No, score=-2.101 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id X7LNKoWTpXcV for ; Wed, 19 Oct 2022 03:18:05 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 128DB40111 Received: from mail-40140.protonmail.ch (mail-40140.protonmail.ch [185.70.40.140]) by smtp2.osuosl.org (Postfix) with ESMTPS id 128DB40111 for ; Wed, 19 Oct 2022 03:18:04 +0000 (UTC) Date: Wed, 19 Oct 2022 03:17:51 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1666149482; x=1666408682; bh=UbpBuSxMkBbKLDroY9+e1EWJwoih1uQQqxqZIGdsHfI=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=OU7qpT9K8RHcyYxNO1nP/08CZbhp5M4nJDU02OBIJzBTo2GCaxtWDnowv3JOGPLAN oEs1MXw9TU3FTkIzarpo3SAuFpJLXR8N1UAMMmsOxBpFFGt/KrSaKvYl09BcSOJEXr dReWMGp9HNm701MNg2pFTPGu0hnVBf5eVIa5z6tV7w9LcX4sZ+VjkPUmY09gsqczYc 41ifkyU+8Zjj577Ry4y2HSiNqWHM5/HB5yDq1upFl0NqQFXrgbcbAilQciB9i+QOYn vdfVbue3RgBHZo1G52b3x5/bi4uQ1f0A2m6ht34s1gzyyt4yPHrZEcXX2FTtWrzqYE ZmN7l53d/ONOA== To: Anthony Towns From: alicexbt Message-ID: In-Reply-To: References: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net> Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Wed, 19 Oct 2022 11:31:59 +0000 Cc: Bitcoin Protocol Discussion Subject: Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 19 Oct 2022 03:18:07 -0000 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, recom= mendations etc. about mempool policies. If these policies are kept for user= s to change based on their needs, why force anything or change defaults ign= oring 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? Optio= n 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 w= e going to remove all the options to switch RBF policies in future because = fullrbf has been suggested by leading technical experts? Is there a possibi= lity 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 alt= hough 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 ex= perts 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 coinj= oin implementations that are claimed to be impacted by opt-in RBF making an= y 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 w= rote: >=20 > > > 1) Continue supporting and encouraging accepting unconfirmed "on-chai= n" > > > 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 throu= gh > > > #25353 + #25600 wasn't making the assumption the enablement itself wo= uld > > > reach agreement of the economic majority or unanimity. >=20 >=20 > 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. >=20 > 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. >=20 > > Without denying that such equilibrium would be unstable, it was designe= d to > > remove the responsibility of the Core project itself to "draw a hard li= ne" > > on the subject. >=20 >=20 > Removing responsibility from core developers seems like it's very much > optimising for the wrong thing to me. >=20 > 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? >=20 > 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. >=20 > 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]. >=20 > [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-May/00= 3033.html > [1] https://github.com/bitcoin/bitcoin/pull/25353 > [2] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020= 557.html >=20 > 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". >=20 > 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"). >=20 > [3] https://bitcoinops.org/en/newsletters/2022/06/22/ > [4] https://bitcoinops.org/en/newsletters/2022/07/13/ >=20 > 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. >=20 > 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. >=20 > > Moreover, relying on node operators turning on the setting > > provides a smoother approach offering time to zero-conf services to rea= ct > > in consequence. >=20 >=20 > 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. >=20 > > So the current path definitely belongs more to a 3) approach. >=20 > > > 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 >=20 >=20 > 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. >=20 > 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= . >=20 > 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. >=20 > (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) >=20 > > While this > > way cannot be denied to be a zero-risk deployment for business acceptin= g > > unconfirmed transactions, it should be weighed in face of multi-party > > contracting protocols encumbering an annoying pinning vector. >=20 >=20 > 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? >=20 > > Since Dario's mail, I think we have learnt new data points, a) on the l= ong > > 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. >=20 >=20 > 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"). >=20 > 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. >=20 > 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. >=20 > 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. >=20 > > 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 proce= ss, >=20 >=20 > Doing something like #26323 only after 24.0 is out does nothing to > mitigate whatever immediate risk there is to bitcoin businesses/users... >=20 > 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? >=20 > 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. >=20 > But saying "we don't want them to be in danger" and also refusing to do > anything to avoid it? >=20 > Cheers, > aj >=20 > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev