📅 Original date posted:2022-01-31
📝 Original message:> On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
…
> 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.
What flag?
>> - **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.
These are not distinct scenarios. The rational choice is the highest fee block-valid subgraph of the set of unconfirmed transactions, in both cases (within the limits of what is computationally feasible of course).
When collecting pooled txs the only issue is DoS protection, which is simply a question of what any given miner is willing to pay, in terms of disk space, to archive conflicts for the opportunity to optimize block reward.
> 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/1aafa200/attachment.html>;
Eric Voskuil [ARCHIVE] /
npub1sg…ppx3c
2023-06-07 23:03:07
in reply to nevent1q…s9as
Author Public Key
npub1sgs97fe0n9wehe6zw7drcxdz4cy9yt9pfqjv8gasz5jlk4zezc0quppx3cPublished at
2023-06-07 23:03:07Event JSON
{
"id": "d1c078cbcaedb8de1931686da373b79f537cbf229f2225780738df30c7e091d5",
"pubkey": "82205f272f995d9be742779a3c19a2ae08522ca14824c3a3b01525fb5459161e",
"created_at": 1686178987,
"kind": 1,
"tags": [
[
"e",
"d8711fa4ba073b35b1bbf55d59a5b990a5dd76dd0f3350a38e07558b3cc8ccf2",
"",
"reply"
],
[
"p",
"a23dbf6c6cc83e14cc3df4e56cc71845f611908084cfe620e83e40c06ccdd3d0"
]
],
"content": "📅 Original date posted:2022-01-31\n📝 Original message:\u003e On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\n…\n\n\u003e 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.\n\nWhat flag?\n\n\u003e\u003e - **Incentive Compatibility**: Ensure that our RBF policy would not\n\u003e\u003e accept replacement transactions which would decrease fee profits\n\u003e\u003e of a miner. In general, if our mempool policy deviates from what is\n\u003e\u003e economically rational, it's likely that the transactions in our\n\u003e\u003e mempool will not match the ones in miners' mempools, making our\n\u003e\u003e fee estimation, compact block relay, and other mempool-dependent\n\u003e\u003e functions unreliable. Incentive-incompatible policy may also\n\u003e\u003e encourage transaction submission through routes other than the p2p\n\u003e\u003e network, harming censorship-resistance and privacy of Bitcoin payments.\n\u003e \n\u003e 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.\n\nThese are not distinct scenarios. The rational choice is the highest fee block-valid subgraph of the set of unconfirmed transactions, in both cases (within the limits of what is computationally feasible of course).\n\nWhen collecting pooled txs the only issue is DoS protection, which is simply a question of what any given miner is willing to pay, in terms of disk space, to archive conflicts for the opportunity to optimize block reward.\n\n\u003e 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.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220131/1aafa200/attachment.html\u003e",
"sig": "9c2a22d6e5fbadcdb7160dfa6919e8d0c14932751bffedd9fc9938c6d0d7b06874462f06ffd6713d9ec63bf8f971e3d2f4e9cd7939cabbe75a6553c1dde4a482"
}