public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
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.


  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 [bitcoin-dev] [PROPOSAL] Emergency RBF (BIP 125) 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.com.au \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=dave@dtrt.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
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