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 95F96D0A for ; Fri, 14 Jun 2019 05:50:30 +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 95DAEE5 for ; Fri, 14 Jun 2019 05:50:29 +0000 (UTC) Received: by ozlabs.org (Postfix, from userid 1011) id 45Q8pW1X4Wz9sND; Fri, 14 Jun 2019 15:50:27 +1000 (AEST) From: Rusty Russell To: "David A. Harding" , Bitcoin Protocol Discussion In-Reply-To: <20190609140334.upcqalp24zrecwye@ganymede> References: <871s0c1tvg.fsf@rustcorp.com.au> <871s07nvi1.fsf@rustcorp.com.au> <20190609140334.upcqalp24zrecwye@ganymede> Date: Fri, 14 Jun 2019 15:20:17 +0930 Message-ID: <874l4spvfq.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: Fri, 14 Jun 2019 06:25:50 +0000 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: Fri, 14 Jun 2019 05:50:30 -0000 "David A. Harding" writes: > On Thu, Jun 06, 2019 at 02:46:54PM +0930, Rusty Russell via bitcoin-dev wrote: >> If that's true, I don't think this proposal makes it worse. > > Here's a scenario that I think shows it being at least 20x worse. [ Snip ] Indeed :( To be fair, if I have a transaction of median size (250 bytes) and I use the current estimatefee 2 of '0.00068325' I get to replace is 68 times; that's $0 for an additional 1GB across all nodes. So, I don't think the current rules are sufficient. But I understand the desire not to make things worse. I'll roll in some changes and re-propose. > It's already hard for wallet software to determine whether or not its > transactions have successfully been relayed. As the deadline approaches, a lightning wallet would RBF with increasing desparation until it gets into a block. It doesn't really matter *why* the tx isn't going through, there's nothing else it can do. > This proposal requires LN > wallets not only be able to guess where the next-block feerate boundary > is in other nodes' individual mempools (now and in the future for the > time it takes the transaction to propagate to ~100% of miners), but it > possibly requires that under the condition that the LN wallet can't > guess too low because it might not get another chance for relay in the > limited time available before contract expiration. I think you mean any proposal which relies on a deadline? If so, that bus has already left. When you see a block you can guess the fees required for the next block. You need some smoothing to avoid wild spikes, but in practice you can start this "desperation mode" 10 blocks before your deadline. Without RBF changes, it needs to assume that it needs to replace a 400kSipa tx @ feerate-for-next-block. With some RBF change, it need only replace @feerate-for-next-block. > Considered that way, I worry that these constraints produce a recipe for > paying extremely high feerates. If that's an actual risk, is that > actually significantly better than dealing with the existing transaction > pinning issue where one needs to pay a high total fee in order to evict > a bunch of junk descendents? Paying lots of fees may not be the optimal > solution to the problem of having to pay lots of fees. :-) I don't understand this at all, sorry. Cheers, Rusty.