📅 Original date posted:2019-06-06
📝 Original message:"Russell O'Connor" <roconnor at blockstream.io> writes:
> Hi Rusty,
>
> On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The new "emergency RBF" rule:
>>
>> 6. If the original transaction was not in the first 4,000,000 weight
>> units of the fee-ordered mempool and the replacement transaction is,
>> rules 3, 4 and 5 do not apply.
>>
>> This means:
>>
>> 3. This proposal does not open any significant new ability to RBF spam,
>> since it can (usually) only be used once. IIUC bitcoind won't
>> accept more that 100 descendents of an unconfirmed tx anyway.
>>
>
> Is it not possible for Alice to grief Bob's node by alternating RBFing two
> transactions, each one placing itself at the bottom of Bob's top 4,000,000
> weight mempool which pushes the other one below the top 4,000,000 weight,
> and then repeating with the other transaction? It might be possible to
> amend this proposal to partially mitigate this.
Good point. This will cost Alice approximately one tx every block, but
that may still be annoying. My intuition says it's hard to play these
games across swathes of non-direct peers, since mempools are in constant
flux and propagation is a bit random.
What mitigations were you thinking?
Cheers,
Rusty.
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-07 18:18:33
in reply to nevent1q…jc53
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-07 18:18:33Event JSON
{
"id": "7e8141ab33b1fbd17487638b722b6dfb5b037e4c182c2712942ddc0ba0ae4d7e",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686161913,
"kind": 1,
"tags": [
[
"e",
"4ed6b3bfac83a99a462d959ed4b694df66ad2dfbc9892c6468b3b5ef5318cefd",
"",
"root"
],
[
"e",
"d5bac3372dd3b42bb49dd5979ecb3cd40a39ac3932b130ceeb8eecfe74658c84",
"",
"reply"
],
[
"p",
"6b8e77368804013d7126ba4b77c7963bcfeff909135791531097d7a0f03ca85d"
]
],
"content": "📅 Original date posted:2019-06-06\n📝 Original message:\"Russell O'Connor\" \u003croconnor at blockstream.io\u003e writes:\n\u003e Hi Rusty,\n\u003e\n\u003e On Sun, Jun 2, 2019 at 9:21 AM Rusty Russell via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e The new \"emergency RBF\" rule:\n\u003e\u003e\n\u003e\u003e 6. If the original transaction was not in the first 4,000,000 weight\n\u003e\u003e units of the fee-ordered mempool and the replacement transaction is,\n\u003e\u003e rules 3, 4 and 5 do not apply.\n\u003e\u003e\n\u003e\u003e This means:\n\u003e\u003e\n\u003e\u003e 3. This proposal does not open any significant new ability to RBF spam,\n\u003e\u003e since it can (usually) only be used once. IIUC bitcoind won't\n\u003e\u003e accept more that 100 descendents of an unconfirmed tx anyway.\n\u003e\u003e\n\u003e\n\u003e Is it not possible for Alice to grief Bob's node by alternating RBFing two\n\u003e transactions, each one placing itself at the bottom of Bob's top 4,000,000\n\u003e weight mempool which pushes the other one below the top 4,000,000 weight,\n\u003e and then repeating with the other transaction? It might be possible to\n\u003e amend this proposal to partially mitigate this.\n\nGood point. This will cost Alice approximately one tx every block, but\nthat may still be annoying. My intuition says it's hard to play these\ngames across swathes of non-direct peers, since mempools are in constant\nflux and propagation is a bit random.\n\nWhat mitigations were you thinking?\n\nCheers,\nRusty.",
"sig": "3fed71de9428daa960af77c2a6665627f94e36bc66f1b1e6d9f892ccbd5a37c9849a744929e45a53a7eca3e65f142a7b11d24e525a88071225808b63ffeead21"
}