From: Jeremy <jlrubin@mit•edu>
To: Gloria Zhao <gloriajzhao@gmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Improving RBF Policy
Date: Thu, 27 Jan 2022 17:35:11 -0800 [thread overview]
Message-ID: <CAD5xwhj=yc5g0NBG0ScNvNs-8pUWDFoGn1GZkqezX1_5e+4LKg@mail.gmail.com> (raw)
In-Reply-To: <CAFXO6=LGbaur6XQrE+6a6mAAHXduOCXoWPTgPosxAG59ZkK6Gg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3717 bytes --]
Gloria,
This is a brilliant post! Great job systematizing many of the issues. Quite
a lot to chew on & I hope other readers of this list digest the post fully.
Three things come to mind as partial responses:
under:
- **DoS Protection**: Limit two types of DoS attacks on the node's
> mempool: (1) the number of times a transaction can be replaced and
> (2) the volume of transactions that can be evicted during a
> replacement.
I'd more simply put it:
Limiting the amount of work that must be done to consider the replacement
We don't particularly care about goal (1) or goal (2), we care about how
much it costs to do (1) or (2). And there are scenarios where the (1) or
(2) might not be particularly high, but the total work still might be. I
can give you some examples to consider if needed. There are also scenarios
where (1) and (2) might be high, but the cost is low overall. Therefore it
makes sense to be a little more general with what the anti-DoS goal is.
An issue I'd like to toss into the mix is that of iterative / additive
batching. E.g., https://bitcoinops.org/en/cardcoins-rbf-batching/
This is where an business puts a txn in the mempool that pays to N users,
and as they see additional requests for payouts the update it to N+2,
N+2... N+M payouts. This iterative batching can be highly efficient because
the number of transactions per business per 10 minutes is 1 (with variable
number of outputs).
One issue with this approach today is that because of the feerate rule, if
you go from N to N+1 you need to pay 1 sat/byte over the whole txn. Applied
M times, and you have to increase fees quadratically for this approach.
Therefore the less efficient long-chain of batches model ends up being
'rational' with respect to mempool policy and irrational with respect to
"optimally packing blocks with transactions".
If the absolute fee rule is dropped, but feerate remains, one thing you
might see is businesses doing iterative batches with N+2M outputs whereby
they drop 2 outputs for every input they add, allowing the iterative batch
to always increase the fee-rate but possibly not triggering the quadratic
feerate issue since the transaction gets smaller over time.
Another possible solution to this would be to allow relaying "txdiffs"
which only require re-relay of signatures + new/modified outputs, and not
the entire tx.
I think this iterative batching is pretty desirable to support, and so I'd
like to see a RBF model which doesn't make it "unfairly" expensive.
(I'll spare everyone the details on how CTV batching also solves this, but
feel free to ask elsewhere.)
A counterargument to additive batching is that if you instead do non
iterative batches every minute, and you have 100 txns that arrive
uniformly, you'd end up with 10 batches of size 10 on average. The bulk of
the benefit under this model is in the non-batched to batched transition,
and the iterative part only saves on space/fees marginally after that point.
A final point is that a verifiable delay function could be used over, e.g.,
each of the N COutpoints individually to rate-limit transaction
replacement. The VDF period can be made shorter / eliminated depending on
the feerate increase. E.g., always consider a much higher feerate txn
whenever available, for things of equal feerate only consider 1 per minute.
A VDF is like proof-of-work that doesn't parallelize, in case you are
unfamiliar, so no matter how many computers you have it would take about
the same amount of time (you could parallelize across N outputs, of course,
but you're still bound minimally to the time it takes to replace 1 output,
doing all outputs individually just is the most flexible option).
Cheers,
Jeremy
[-- Attachment #2: Type: text/html, Size: 9089 bytes --]
next prev parent reply other threads:[~2022-01-28 1:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-27 13:42 Gloria Zhao
2022-01-28 1:35 ` Jeremy [this message]
2022-01-30 22:53 ` Antoine Riard
2022-01-31 15:57 ` Bastien TEINTURIER
2022-02-01 1:56 ` Anthony Towns
2022-02-05 13:21 ` Michael Folkson
2022-02-07 10:22 ` Bastien TEINTURIER
2022-02-07 11:16 ` Gloria Zhao
2022-02-08 4:58 ` Anthony Towns
2022-03-09 15:09 ` Gloria Zhao
2022-03-11 16:22 ` Billy Tetrud
2022-03-12 8:18 ` Billy Tetrud
2022-03-14 10:29 ` Gloria Zhao
2022-03-15 1:43 ` Billy Tetrud
2022-03-17 2:02 ` Antoine Riard
2022-03-17 15:59 ` Billy Tetrud
[not found] <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-01-31 22:54 ` [bitcoin-dev] Improving RBF policy Bram Cohen
2022-02-01 0:08 ` Eric Voskuil
2022-02-01 8:32 ` Bram Cohen
2022-02-01 19:44 ` Eric Voskuil
2022-02-01 0:42 ` Antoine Riard
2022-02-01 2:47 [bitcoin-dev] Improving RBF Policy Prayank
2022-02-01 9:30 ` Bastien TEINTURIER
2022-02-02 10:21 ` Anthony Towns
2022-02-09 17:57 lisa neigut
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='CAD5xwhj=yc5g0NBG0ScNvNs-8pUWDFoGn1GZkqezX1_5e+4LKg@mail.gmail.com' \
--to=jlrubin@mit$(echo .)edu \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=gloriajzhao@gmail$(echo .)com \
/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