📅 Original date posted:2022-01-31
📝 Original message: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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220131/0d66162d/attachment.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 23:03:06
in reply to nevent1q…ns9d
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 23:03:06Event JSON
{
"id": "6681374caed55f4341a354c66e3611bd0076f4b0d357b1843f77d89dd87617b9",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686178986,
"kind": 1,
"tags": [
[
"e",
"4cb9afdaae5463701f38986687e55bd331ddabd9bd760b8e43eaa1fe303aa32b",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2022-01-31\n📝 Original message:Gloria Zhao wrote:\n\n\u003e\n\u003e This post discusses limitations of current Bitcoin Core RBF policy and\n\u003e attempts to start a conversation about how we can improve it,\n\u003e summarizing some ideas that have been discussed. Please reply if you\n\u003e have any new input on issues to be solved and ideas for improvement!\n\u003e\n\nIs it still verboten to acknowledge that RBF is normal behavior and\ndisallowing it is the feature, and that feature is mostly there to appease\nsome people's delusions that zeroconf is a thing? It seems a bit overdue to\ndisrespect the RBF flag in the direction of always assuming it's on.\n\n\n\u003e - **Incentive Compatibility**: Ensure that our RBF policy would not\n\u003e accept replacement transactions which would decrease fee profits\n\u003e of a miner. In general, if our mempool policy deviates from what is\n\u003e economically rational, it's likely that the transactions in our\n\u003e mempool will not match the ones in miners' mempools, making our\n\u003e fee estimation, compact block relay, and other mempool-dependent\n\u003e functions unreliable. Incentive-incompatible policy may also\n\u003e encourage transaction submission through routes other than the p2p\n\u003e network, harming censorship-resistance and privacy of Bitcoin payments.\n\u003e\n\nThere are two different common regimes which result in different\nincentivized behavior. One of them is that there's more than a block's\nbacklog in the mempool in which case between two conflicting transactions\nthe one with the higher fee rate should win. In the other case where there\nisn't a whole block's worth of transactions the one with higher total value\nshould win. It would be nice to have consolidated logic which handles both,\nit seems the issue has to do with the slope of the supply/demand curve\nwhich in the first case is gentle enough to keep the one transaction from\nhitting the rate but in the second one is basically infinite.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220131/0d66162d/attachment.html\u003e",
"sig": "ec58689c27d9f4cd1681e9989002ec0dc026af2e16007e74e6e151dadc9c642b8abc791e3fa14f2e5b219a0758f04b7e43458d93659b01d1267dad5ce18f1256"
}