diff options
| author | alicexbt <alicexbt@protonmail.com> | 2022-10-19 03:17:51 +0000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2022-10-19 03:18:07 +0000 |
| commit | 27097fb7c5dd7eb8d3c36393c9d44e26699fa887 (patch) | |
| tree | 2fc2c485ee0206207e42b7470b2d2d48d39b0471 | |
| parent | 69e9ebfcb285e293f6ea7e67376f139e97f184a1 (diff) | |
| download | pi-bitcoindev-27097fb7c5dd7eb8d3c36393c9d44e26699fa887.tar.gz pi-bitcoindev-27097fb7c5dd7eb8d3c36393c9d44e26699fa887.zip | |
Re: [bitcoin-dev] [Opt-in full-RBF] Zero-conf apps in immediate danger
| -rw-r--r-- | 59/bc94971914dee69584f4ac82407dd6a86ac544 | 351 |
1 files changed, 351 insertions, 0 deletions
diff --git a/59/bc94971914dee69584f4ac82407dd6a86ac544 b/59/bc94971914dee69584f4ac82407dd6a86ac544 new file mode 100644 index 000000000..ac80b34eb --- /dev/null +++ b/59/bc94971914dee69584f4ac82407dd6a86ac544 @@ -0,0 +1,351 @@ +Return-Path: <alicexbt@protonmail.com> +Received: from smtp2.osuosl.org (smtp2.osuosl.org [IPv6:2605:bc80:3010::133]) + by lists.linuxfoundation.org (Postfix) with ESMTP id D38A5C002D + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <aj@erisian.com.au> +From: alicexbt <alicexbt@protonmail.com> +Message-ID: <PC-7ALULc67cy0mTKzk_uj-pbCcwDoMuJQmmevzLPexK32B11vuzCusGSrx1wNCQ5YtMqfQeI1N5AmdemvfHEJNJ5VmZxAeaWS6E3tNZxIs=@protonmail.com> +In-Reply-To: <Y05PHYtrNmA0vg7U@erisian.com.au> +References: <Y0ZTtlRSBihNN9+v@erisian.com.au> + <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net> + <Y0d/e2sEoNRgD7KP@erisian.com.au> <Y0u8Ee2Ao375z8UD@erisian.com.au> + <CALZpt+GSYBFxajSyZS19sQi4_6zHjkA5sP00V-pR=_NEVVUnkg@mail.gmail.com> + <Y05PHYtrNmA0vg7U@erisian.com.au> +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 <bitcoin-dev@lists.linuxfoundation.org> +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 <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 + |