rich1.0npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxhttps://nostr.ae/npub1zw7cc8z78v6s3grujfvcv3ckpvg6kr0w7nz9yzvwyglyg0qu5sjsqhkhpxnjumphttps://nostr.ae📅 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,