š
Original date posted:2022-11-07
š Original message:On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>AJ/Antoine et al
>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>
>Assuming Alice is a well funded advisory, with enough resources to spam the network so that enough nodes see her malicious transaction first, how does full-rbf solve this vs. opt-in rbf?
First of all, to make things clear, remember that the attacks were talking about are aimed at _preventing_ a transaction from getting mined. Alice wants to cheaply broadcast something with low fees that won't get mined soon (if ever), that prevents a protocol from making forward progress.
With full-rbf, who saw what transaction first doesn't matter: the higher fee paying transaction will always(*) replace the lower fee one. With opt-in RBF, spamming the network can beat out the alternative.
*) So what's the catch? Well, due to limitations in today's mempool implementation, sometimes we can't fully evaluate which tx pays the higher fee. For example, if Alice spams the network with very _large_ numbers transactions spending that input, the current mempool code doesn't even try to figure out if a replacement is better.
But those limitations are likely to be fixable. And even right now, without fixing them, Alice still has to use a lot more money to pull off these attacks with full-rbf. So full-rbf definitely improves the situation even if it doesn't solve the problem completely.
Peter Todd [ARCHIVE] /
npub1m2ā¦a2np2
2023-06-07 23:16:18
in reply to nevent1qā¦m7r7
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 23:16:18Event JSON
{
"id": "29ccfb70375914902218d02d96c02d27a6b0b5c3a2419734935eb60b0e0df2be",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686179778,
"kind": 1,
"tags": [
[
"e",
"da6b9abb4324405cd4b243e228b3f24914204671328c740ca96b666c4bff2a5c",
"",
"root"
],
[
"e",
"2ec5cd521edd358d942cd61e01b55c0332bc7b60b6ac17c22742fc5f3363e628",
"",
"reply"
],
[
"p",
"19f735f6839e45d8f2405e2dc16b67cc1fb630408d338f32b3147e0297f170bf"
]
],
"content": "š
Original date posted:2022-11-07\nš Original message:On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev \u003cbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003eAJ/Antoine et al\n\u003e\n\u003e\u003e What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to\n\u003e\u003e solve that problem if they have only opt-in RBF available?\n\u003e\n\u003eAssuming Alice is a well funded advisory, with enough resources to spam the network so that enough nodes see her malicious transaction first, how does full-rbf solve this vs. opt-in rbf?\n\nFirst of all, to make things clear, remember that the attacks were talking about are aimed at _preventing_ a transaction from getting mined. Alice wants to cheaply broadcast something with low fees that won't get mined soon (if ever), that prevents a protocol from making forward progress.\n\nWith full-rbf, who saw what transaction first doesn't matter: the higher fee paying transaction will always(*) replace the lower fee one. With opt-in RBF, spamming the network can beat out the alternative.\n\n*) So what's the catch? Well, due to limitations in today's mempool implementation, sometimes we can't fully evaluate which tx pays the higher fee. For example, if Alice spams the network with very _large_ numbers transactions spending that input, the current mempool code doesn't even try to figure out if a replacement is better.\n\nBut those limitations are likely to be fixable. And even right now, without fixing them, Alice still has to use a lot more money to pull off these attacks with full-rbf. So full-rbf definitely improves the situation even if it doesn't solve the problem completely.",
"sig": "42ef53b13977ec427356563f39f1abdc66dfa7343c3ad3d800a67e002d3250476fbe95cc3a14cec5d5f312cb5047f876084dcd8aed0801d39978c92ac6027a6c"
}