📅 Original date posted:2022-02-01
📝 Original message:On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil <eric at voskuil.org> wrote:
>
>
> 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?
>
The opt-in RBF flag in transactions.
> 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).
>
It's weird because which of two or more conflicting transactions should win
can oscillate back and forth depending on other stuff going on in the
mempool. There's already a bit of that with child pays but this is stranger
and has more oddball edge cases about which transactions to route.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220201/3f148e34/attachment-0001.html>;
Bram Cohen [ARCHIVE] /
npub1ld…t8ur6
2023-06-07 23:03:08
in reply to nevent1q…7lsm
Author Public Key
npub1ldcq03p2qe58u0xnlwa35wchjuhz49y6ueu5ghmtjetez9xstnvsmt8ur6Published at
2023-06-07 23:03:08Event JSON
{
"id": "a3ccdb7ebf127e81e21d58ab0269073c9396ce5af360b0fd29fd32648f92490e",
"pubkey": "fb7007c42a06687e3cd3fbbb1a3b17972e2a949ae679445f6b96579114d05cd9",
"created_at": 1686178988,
"kind": 1,
"tags": [
[
"e",
"d8711fa4ba073b35b1bbf55d59a5b990a5dd76dd0f3350a38e07558b3cc8ccf2",
"",
"root"
],
[
"e",
"7b77eac9e789760b65757629fba753991c95f52d9bf0b7472627f5455737d717",
"",
"reply"
],
[
"p",
"6485bc56963b51c9043d0855cca9f78fcbd0ce135a195c3f969e18ca54a0d551"
]
],
"content": "📅 Original date posted:2022-02-01\n📝 Original message:On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil \u003ceric at voskuil.org\u003e wrote:\n\n\u003e\n\u003e\n\u003e On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e Is it still verboten to acknowledge that RBF is normal behavior and\n\u003e disallowing it is the feature, and that feature is mostly there to appease\n\u003e some people's delusions that zeroconf is a thing? It seems a bit overdue to\n\u003e disrespect the RBF flag in the direction of always assuming it's on.\n\u003e\n\u003e What flag?\n\u003e\n\nThe opt-in RBF flag in transactions.\n\n\n\u003e There are two different common regimes which result in different\n\u003e incentivized behavior. One of them is that there's more than a block's\n\u003e backlog in the mempool in which case between two conflicting transactions\n\u003e the one with the higher fee rate should win. In the other case where there\n\u003e isn't a whole block's worth of transactions the one with higher total value\n\u003e should win.\n\u003e\n\u003e These are not distinct scenarios. The rational choice is the highest fee\n\u003e block-valid subgraph of the set of unconfirmed transactions, in both cases\n\u003e (within the limits of what is computationally feasible of course).\n\u003e\n\nIt's weird because which of two or more conflicting transactions should win\ncan oscillate back and forth depending on other stuff going on in the\nmempool. There's already a bit of that with child pays but this is stranger\nand has more oddball edge cases about which transactions to route.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20220201/3f148e34/attachment-0001.html\u003e",
"sig": "7b308d961fbcc38b46ace554fb72d61b616a6440a98ea3f89f049727111e70d46d32107ae30f48710bdc89ce0210fd672902679996528bae3076914b7c70de7d"
}