diff options
| author | Rusty Russell <rusty@rustcorp.com.au> | 2019-06-14 15:20:17 +0930 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2019-06-14 05:50:30 +0000 |
| commit | cc11020782a486541e0a1639135fe0b34c5d06c7 (patch) | |
| tree | f8e00a0b932011ee26bf09f48665bc1954597509 | |
| parent | 4f50e08c62d2817840c1ea935a12b928f5939f73 (diff) | |
| download | pi-bitcoindev-cc11020782a486541e0a1639135fe0b34c5d06c7.tar.gz pi-bitcoindev-cc11020782a486541e0a1639135fe0b34c5d06c7.zip | |
Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
| -rw-r--r-- | 2f/6cba1501c4fcafca92a5beff6b39234c4592e8 | 100 |
1 files changed, 100 insertions, 0 deletions
diff --git a/2f/6cba1501c4fcafca92a5beff6b39234c4592e8 b/2f/6cba1501c4fcafca92a5beff6b39234c4592e8 new file mode 100644 index 000000000..302801e01 --- /dev/null +++ b/2f/6cba1501c4fcafca92a5beff6b39234c4592e8 @@ -0,0 +1,100 @@ +Return-Path: <rusty@ozlabs.org> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 95F96D0A + for <bitcoin-dev@lists.linuxfoundation.org>; + 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 <bitcoin-dev@lists.linuxfoundation.org>; + 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 <rusty@rustcorp.com.au> +To: "David A. Harding" <dave@dtrt.org>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +In-Reply-To: <20190609140334.upcqalp24zrecwye@ganymede> +References: <871s0c1tvg.fsf@rustcorp.com.au> + <F252D824-5BE6-4B03-B59D-D40EAFBAEE84@mattcorallo.com> + <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 <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: Fri, 14 Jun 2019 05:50:30 -0000 + +"David A. Harding" <dave@dtrt.org> 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. + |