From: Rusty Russell <rusty@rustcorp•com.au>
To: "David A. Harding" <dave@dtrt•org>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125)
Date: Fri, 14 Jun 2019 15:20:17 +0930 [thread overview]
Message-ID: <874l4spvfq.fsf@rustcorp.com.au> (raw)
In-Reply-To: <20190609140334.upcqalp24zrecwye@ganymede>
"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.
next prev parent reply other threads:[~2019-06-14 5:50 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-06-02 4:41 Rusty Russell
2019-06-03 1:49 ` rhavar
2019-06-03 9:48 ` Matt Corallo
2019-06-06 5:16 ` Rusty Russell
2019-06-09 14:07 ` David A. Harding
2019-06-10 16:34 ` rhavar
2019-06-14 5:50 ` Rusty Russell [this message]
2019-06-03 12:56 ` Russell O'Connor
2019-06-06 3:08 ` Rusty Russell
2019-06-09 4:21 ` Russell O'Connor
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=874l4spvfq.fsf@rustcorp.com.au \
--to=rusty@rustcorp$(echo .)com.au \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=dave@dtrt$(echo .)org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox