From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 44E602C for ; Sun, 9 Jun 2019 03:59:58 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from ozlabs.org (ozlabs.org [203.11.71.1]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 020C267F for ; Sun, 9 Jun 2019 03:59:55 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 45M2bF2PJ0z9s7h; Sun, 9 Jun 2019 13:59:53 +1000 (AEST) From: Rusty Russell To: Matt Corallo In-Reply-To: References: <871s0c1tvg.fsf@rustcorp.com.au> Date: Thu, 06 Jun 2019 14:46:54 +0930 Message-ID: <871s07nvi1.fsf@rustcorp.com.au> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 09 Jun 2019 08:18:41 +0000 Cc: Bitcoin Dev Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125) X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 09 Jun 2019 03:59:58 -0000 Matt Corallo writes: > I think this needs significantly improved motivation/description. A few areas I'd like to see calculated out: > > 1) wrt rule 3, for this to be obviously-incentive-compatible-for-the-next-miner, I'd think no evicted transactions would be allowed to be in the next block range. This would probably require some significant additional tracking in today's mempool logic. This is a good question, which is why I really wanted to look into the implementation details. There are some approximations possible wrt. pre- and post- tx bundle feerate, but they have to be examined closely. > 2) wrt rule 4, I'd like to see a calculation of worst-case free relay. I think we're already not in a great place, but maybe it's worth it or maybe there is some other way to reduce this cost (intuitively it looks like this proposal could make things very, very, very bad). I *think* you can currently create a tx at 1 sat/byte, have it propagate, then RBF it to 2 sat/byte, 3... and do that a few thousand times before your transaction gets mined. If that's true, I don't think this proposal makes it worse. >> 3) wrt rule 5, I'd like to see benchmarks, it's probably a pretty nasty DoS attack, but it may also be the case that is (a) not worse than other fundamental issues or (b) sufficiently expensive. I thought we still meet rule 5 in practice since bitcoind will never even accept a tree of unconfirmed txs which is > 100 txs? That would still stand, it's just that we'd still consider a replacement. > 4) As I've indicated before, I'm generaly not a fan of such vague > protections for time-critical transactions such as payment channel > punishment transactions. The bitcoin network offers no propagation guarantees; it's all best effort anyway. This makes it no worse, and we can tunnel txs through the lightning network if we have to. > At a high-level, in this context your counterparty's transactions (not to mention every other transaction in everyone's mempool) are still involved in the decision about whether to accept an RBF, in contrast to previous proposals, which makes it much harder to reason about. As a specific example, if an attacker exploits mempool policy differences they may cause your concept of "top 4M weight" to be bogus for a subeset of nodes, causing propogation to be limited. If miners have a conflicting tx in the top 4MSipa, you don't have a problem. So an attacker needs to limit propagation in a way which isolates the miners from either the new tx or the conflicting one, which is much harder. > Obviously there is also a ton more client-side knowledge required and complexity to RBF decisions here than other previous, more narrowly-targeted proposals. Define client-side here? I'd say from the lightning side it's as simple as a normal RBF policy until you get within a few blocks of a deadline, then you increase the fees until it's well within reach of the next block. You can even approximate this by looking at fees on the previous block, with some care for outliers. > (I don't think this one use-case being not optimal should prevent such a proposal, i agree it's quite nice for some other cases). I like that it's conceptually simple and inventive-robust, and doesn't really rely on bitcoind's internal policy mechanics of RBF. I think in the longer term we're going to need other mechanisms for restricting abusive propagation anyway, but that's a bit out-of-scope. Thanks! Rusty.