📅 Original date posted:2020-04-27
📝 Original message:"David A. Harding via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> writes:
> To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults
> require each replacement pay a feerate of 10 nBTC/vbyte over an existing
> transaction or package, and the defaults also allow transactions or
> packages up to 100,000 vbytes in size (~400,000 bytes). So, without
> enforcement of BIP125 rule 3, an attacker starting at the minimum
> default relay fee also of 10 nBTC/vbyte could do the following:
>
> - Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total
> fee)
>
> - Replace that transaction with 400,000 new bytes at a feerate of 20
> nBTC/vbyte (2 mBTC total fee)
>
> - Perform 998 additional replacements, each increasing the feerate by 10
> nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes
> (including the original transaction and first replacement) to
> ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte
> (1 BTC total fee)
>
> - Perform one final replacement of the latest 400,000 byte transaction
> with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays
> a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee)
To be fair, if the feerate you want is 100x the minimum permitted, you
can always use 100x as much bandwidth as necessary without extra cost.
If everyone (or some major tx producers) were to do that, it would suck.
To fix this properly, you really need to agressively delay processing
(thus propagation) of transactions which aren't likely to be in the next
(few?) blocks. This is a more miner incentive compatible scheme.
However, I realize this is a complete rewrite of bitcoind's logic, and
I'm not volunteering to do it!
Cheers,
Rusty,
Rusty Russell [ARCHIVE] /
npub1zw…hkhpx
2023-06-07 18:23:50
in reply to nevent1q…2ggf
Author Public Key
npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxPublished at
2023-06-07 18:23:50Event JSON
{
"id": "ce74774d725275851a2552c56bfc385beef02950caa24d1293f90201c3bc5120",
"pubkey": "13bd8c1c5e3b3508a07c92598647160b11ab0deef4c452098e223e443c1ca425",
"created_at": 1686162230,
"kind": 1,
"tags": [
[
"e",
"4ae4536f68de8a4b2a3c31c933a85764eb760980581a5d60fc0bd50434d34784",
"",
"root"
],
[
"e",
"64224237bd117912f83befed454ba4a251596da78280482b1193abb5236082ff",
"",
"reply"
],
[
"p",
"d3574a24208f4e3d0821bb4a69a0c3ae842043d444fa5c4a8c49c369918a6fb2"
]
],
"content": "📅 Original date posted:2020-04-27\n📝 Original message:\"David A. Harding via bitcoin-dev\" \u003cbitcoin-dev at lists.linuxfoundation.org\u003e writes:\n\u003e To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults\n\u003e require each replacement pay a feerate of 10 nBTC/vbyte over an existing\n\u003e transaction or package, and the defaults also allow transactions or\n\u003e packages up to 100,000 vbytes in size (~400,000 bytes). So, without\n\u003e enforcement of BIP125 rule 3, an attacker starting at the minimum\n\u003e default relay fee also of 10 nBTC/vbyte could do the following:\n\u003e\n\u003e - Create a ~400,000 bytes tx with feerate of 10 nBTC/vbyte (1 mBTC total\n\u003e fee)\n\u003e\n\u003e - Replace that transaction with 400,000 new bytes at a feerate of 20\n\u003e nBTC/vbyte (2 mBTC total fee)\n\u003e\n\u003e - Perform 998 additional replacements, each increasing the feerate by 10\n\u003e nBTC/vbyte and the total fee by 1 mBTC, using a total of 400 megabytes\n\u003e (including the original transaction and first replacement) to\n\u003e ultimately produce a transaction with a feerate of 10,000 nBTC/vbyte\n\u003e (1 BTC total fee)\n\u003e\n\u003e - Perform one final replacement of the latest 400,000 byte transaction\n\u003e with a ~200-byte (~150 vbyte) 1-in, 1-out P2WPKH transaction that pays\n\u003e a feerate of 10,010 nBTC/vbyte (1.5 mBTC total fee)\n\nTo be fair, if the feerate you want is 100x the minimum permitted, you\ncan always use 100x as much bandwidth as necessary without extra cost.\nIf everyone (or some major tx producers) were to do that, it would suck.\n\nTo fix this properly, you really need to agressively delay processing\n(thus propagation) of transactions which aren't likely to be in the next\n(few?) blocks. This is a more miner incentive compatible scheme.\n\nHowever, I realize this is a complete rewrite of bitcoind's logic, and\nI'm not volunteering to do it!\n\nCheers,\nRusty,",
"sig": "477f7ecdefc02b6a25cc73c7e76b2bd2a0c8ff60027119eda7d6bdedf1c84542aecd2b0b649a1a16752e7180e4676031de8bcd4bd94c635c52071bf1a4ebcf12"
}