From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id 968D1C002D for ; Thu, 13 Oct 2022 04:35:33 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 60CF683E76 for ; Thu, 13 Oct 2022 04:35:33 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 60CF683E76 X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: 0.599 X-Spam-Level: X-Spam-Status: No, score=0.599 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, LOTS_OF_MONEY=0.001, MONEY_NOHTML=2.499, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=0.001] autolearn=no autolearn_force=no Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GnVPNONzKP_G for ; Thu, 13 Oct 2022 04:35:32 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp1.osuosl.org 2DC2283E69 Received: from azure.erisian.com.au (azure.erisian.com.au [172.104.61.193]) by smtp1.osuosl.org (Postfix) with ESMTPS id 2DC2283E69 for ; Thu, 13 Oct 2022 04:35:32 +0000 (UTC) Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) by azure.erisian.com.au with esmtpsa (Exim 4.92 #3 (Debian)) id 1oipwM-0001o8-Lz; Thu, 13 Oct 2022 14:35:28 +1000 Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); Thu, 13 Oct 2022 14:35:22 +1000 Date: Thu, 13 Oct 2022 14:35:22 +1000 From: Anthony Towns To: Pieter Wuille , Bitcoin Protocol Discussion Message-ID: References: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0hpdGx-1WbZdG31xaMXGHKTCjJ2-0eB5aIXUdsp3bqI1MlCx6TMZWROwpl1TVI5irrBqRN2-ydM6hmf3M5L-7ZQfazbx66oameiWTHayr6w=@wuille.net> X-Spam-Score-int: -18 X-Spam-Bar: - 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: Thu, 13 Oct 2022 04:35:33 -0000 On Wed, Oct 12, 2022 at 04:11:05PM +0000, Pieter Wuille via bitcoin-dev wrote: > In my view, it is just what I said: a step towards getting full RBF > on the network, by allowing experimentation and socializing the notion > that developers believe it is time. We "believe it is time" for what exactly, though? (a) To start deprerecating accepting zeroconf txs on mainnet, over the next 6, 12 or 18 months; or (b) to start switching mainnet mining and relay nodes over to full RBF? As far as experimentation goes, I don't really see this option as being very likely to help: the default for this option is still false, so it's likely going to be difficult to get non-opt-in RBF txs relayed or mined anywhere, even on testnet or signet, no? (Maybe that's a difficulty that's resolved by an addnode, but it's still a difficulty) If experimentation's the goal, making the default be true for testnet/signet at least seems like it would be pretty useful at least. Meaningful experimentation is probably kind of difficult in the first place while fees are low and there's often no backlog in the mempool, as well; something that perhaps applies more to test nets than mainnet even. If we're trying to socialise the idea that zeroconf deprecation is happening and that your business now has a real deadline for migrating away from accepting unconfirmed txs if the risk of being defrauded concerns you, then enabling experimentation on test nets and not touching mainnet until a later release seems fairly fine to me -- similar to activating soft forks on test nets prior to activating it on mainnet. > So I have a hard time imagining how it > would change anything *immediately* on the network at large (without > things like default on and/or preferential peering, ...), but I still > believe it's an important step. If we're instead trying to socialise the idea that relaying and mining full RBF txs on mainnet should be starting now, then I think that's exactly how this *would* change things almost immediately on the network at large. I think all it would take in practice to be able to repeatedly defraud businesses accepting unconfirmed txs is perhaps 5% or 10% of blocks to include full RBF txs [0] [1], and knowing some IP addresses to addnode so that your txs relayed to those miners. And if core devs are advocating that full RBF is ready now [2], and a patch to easily enable it is included in a bitcoin core release, why wouldn't some small pools start trying it out, leading to exactly that situation? If most of the network doesn't relay your full-rbf txs, then that's annoying for protocol developers who'd like to rely on it, but it's fine for an attacker: it just means the business you're trying to trick has less chance of noticing the attack before it's too late, because they'll be less likely to see the conflicting tx via both their own node or public explorers. Cheers, aj [0] A few months ago, Peter Todd reported switching an OTS calendar to do non-opt-in RBF, and didn't observe bumped txs being mined, which seems to indicate there's not much hash power currently mining full RBF. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020592.html [1] Also why I remain surprised that accepting zeroconf is safe enough in practice for anyone to do it. I suppose 5% of hashpower is perhaps $100M+ investment in ASICs and $900k/day in revenue, and perhaps all the current ways of enabling full RBF are considered too risky to mess around with at that level. [2] Antoine Riard's mail from June (that Peter's mail above was in reply to) announced such a public node, and encouraged miners to start adoption: "If you're a mining operator looking to increase your income, you might be interested to experiment with full-rbf as a policy." Presuming the IRC channel "##uafrbf" stands for "user-activated full rbf", that also seems in line with the goal being to socialise doing full RBF on mainnet immediately... https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-June/020557.html