From: Bram Cohen <bram@chia•net>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists•linuxfoundation.org>
Subject: [bitcoin-dev] Improving RBF policy
Date: Mon, 31 Jan 2022 14:54:10 -0800 [thread overview]
Message-ID: <CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com> (raw)
In-Reply-To: <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
[-- Attachment #1: Type: text/plain, Size: 1857 bytes --]
Gloria Zhao wrote:
>
> This post discusses limitations of current Bitcoin Core RBF policy and
> attempts to start a conversation about how we can improve it,
> summarizing some ideas that have been discussed. Please reply if you
> have any new input on issues to be solved and ideas for improvement!
>
Is it still verboten to acknowledge that RBF is normal behavior and
disallowing it is the feature, and that feature is mostly there to appease
some people's delusions that zeroconf is a thing? It seems a bit overdue to
disrespect the RBF flag in the direction of always assuming it's on.
> - **Incentive Compatibility**: Ensure that our RBF policy would not
> accept replacement transactions which would decrease fee profits
> of a miner. In general, if our mempool policy deviates from what is
> economically rational, it's likely that the transactions in our
> mempool will not match the ones in miners' mempools, making our
> fee estimation, compact block relay, and other mempool-dependent
> functions unreliable. Incentive-incompatible policy may also
> encourage transaction submission through routes other than the p2p
> network, harming censorship-resistance and privacy of Bitcoin payments.
>
There are two different common regimes which result in different
incentivized behavior. One of them is that there's more than a block's
backlog in the mempool in which case between two conflicting transactions
the one with the higher fee rate should win. In the other case where there
isn't a whole block's worth of transactions the one with higher total value
should win. It would be nice to have consolidated logic which handles both,
it seems the issue has to do with the slope of the supply/demand curve
which in the first case is gentle enough to keep the one transaction from
hitting the rate but in the second one is basically infinite.
[-- Attachment #2: Type: text/html, Size: 2326 bytes --]
next parent reply other threads:[~2022-01-31 22:54 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.19693.1643292568.8511.bitcoin-dev@lists.linuxfoundation.org>
2022-01-31 22:54 ` Bram Cohen [this message]
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-09 17:57 [bitcoin-dev] Improving RBF Policy lisa neigut
-- strict thread matches above, loose matches on Subject: below --
2022-02-01 2:47 Prayank
2022-02-01 9:30 ` Bastien TEINTURIER
2022-02-02 10:21 ` Anthony Towns
2022-01-27 13:42 Gloria Zhao
2022-01-28 1:35 ` Jeremy
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
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=CAHUJnBA7AtX_osJUJQyKmc5QBknH5U0TKU3hiyxzpPv4TN88JQ@mail.gmail.com \
--to=bram@chia$(echo .)net \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.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