📅 Original date posted:2018-05-21
📝 Original message:On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote:
> Jim Posen <jim.posen at gmail.com> writes:
> > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF
> > on the spending tx?
>
> Marco points out that if the parent is RBF, this child inherits it, so
> we're actually good here.
>
> However, Matt Corallo points out that you can block RBF will a
> large-but-lowball tx, as BIP 125 points out:
>
> will be replaced by a new transaction...:
>
> 3. The replacement transaction pays an absolute fee of at least the sum
> paid by the original transactions.
>
> I understand implementing a single mempool requires these kind of
> up-front decisions on which tx is "better", but I wonder about the
> consequences of dropping this heuristic? Peter?
We've discussed this before: that rule prevents bandwidth usage DoS attacks on
the mempool; it's not a "heuristic". If you drop it, an attacker can repeatedly
broadcast and replace a series of transactions to use up tx relay bandwidth for
significantly lower cost than otherwise.
Though these days with relatively high minimum fees that may not matter.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180520/838d855d/attachment.sig>;
Peter Todd [ARCHIVE] /
npub1m2…a2np2
2023-06-07 18:11:59
in reply to nevent1q…syj8
Author Public Key
npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2Published at
2023-06-07 18:11:59Event JSON
{
"id": "4576890a2e07289722b51b81edd992919dbde0a81c2508d857cdb1915764a76a",
"pubkey": "daa2fc676a25e3b5b45644540bcbd1e1168b111427cd0e3cf19c56194fb231aa",
"created_at": 1686161519,
"kind": 1,
"tags": [
[
"e",
"caee4e3828cad70a0aa9bfba9569480bc6157a528d4896eeab11f571613a9d97",
"",
"root"
],
[
"e",
"33600aa57c9522ceb70bf217f07545f37fa981fa8ae177f42a7491f81fc9ecbe",
"",
"reply"
],
[
"p",
"13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425"
]
],
"content": "📅 Original date posted:2018-05-21\n📝 Original message:On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote:\n\u003e Jim Posen \u003cjim.posen at gmail.com\u003e writes:\n\u003e \u003e I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF\n\u003e \u003e on the spending tx?\n\u003e \n\u003e Marco points out that if the parent is RBF, this child inherits it, so\n\u003e we're actually good here.\n\u003e \n\u003e However, Matt Corallo points out that you can block RBF will a\n\u003e large-but-lowball tx, as BIP 125 points out:\n\u003e \n\u003e will be replaced by a new transaction...:\n\u003e \n\u003e 3. The replacement transaction pays an absolute fee of at least the sum\n\u003e paid by the original transactions.\n\u003e \n\u003e I understand implementing a single mempool requires these kind of\n\u003e up-front decisions on which tx is \"better\", but I wonder about the\n\u003e consequences of dropping this heuristic? Peter?\n\nWe've discussed this before: that rule prevents bandwidth usage DoS attacks on\nthe mempool; it's not a \"heuristic\". If you drop it, an attacker can repeatedly\nbroadcast and replace a series of transactions to use up tx relay bandwidth for\nsignificantly lower cost than otherwise.\n\nThough these days with relatively high minimum fees that may not matter.\n\n-- \nhttps://petertodd.org 'peter'[:-1]@petertodd.org\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 488 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20180520/838d855d/attachment.sig\u003e",
"sig": "d159f3a8b976fe8ee3073fb78d705538c672fcb55cf0fc1d513211ca5e3d414f7e0e48a8096106d4ff4edce89f48dc4e10e13b3cc5c6f29460abb8e4349ce714"
}