Re: [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks
Hi ArmchairCryptologist, Bitcoin is working as expected and I don't see any 'manipulation' attacks in the bidding for block space. Maybe we aren't used to such demand for blockspace on bitcoin. Additionally, fingerprinting based on fee rates and timing to attribute transactions to a single person is inaccurate. Various services, such as unisat, are used for deploying and minting BRC20 tokens based on region, community etc. Consequently, a service broadcasting Bitcoin transactions might appear as a single individual. With regards to UTXO set, IBD for machines with enough RAM seems to be unaffected, however I have not done benchmarking to compare IBD before and after inscriptions with less dbcache. Also the number of full nodes have increased in last one year. > However, in practice, the attack appears to rely on exploiting the inherent > decay used by fee estimation algorithms that are based on historical fee > data. This causes many wallets to create transactions that overpay the > necessarily next-block fee by a significant amount - for example, the morning > after the 700 sat/vB flood on December 16th, Bitcoin Core was still giving a > six-block estimate of 529 sat/vB even though <250 sat/vB transactions were > being mined. Bitcoin Core fee estimation has known issues since years, and I would not recommended it for actual use, except for testing purposes. Related discussion: https://github.com/bitcoin/bitcoin/issues/27995 > My proposed solution to this would be to add partial transaction fee burning. NACK /dev/fd0 floppy disk guy Sent with Proton Mail secure email. On Sunday, December 17th, 2023 at 11:11 AM, ArmchairCryptologist via bitcoin-dev wrote: > ** Motivation ** > As everyone already knows, over the last seven months or so, the size of the > mempool as well as transaction fees of on the bitcoin network have both been > abnormally high. This tend has generally been ascribed to the introduction of > ordinals, and while this may be both technically and actually true, > disregarding the debate of whether ordinals is a "valid use" or the > blockchain or not, the specific patterns we are seeing for some of these > transactions have been making me somewhat suspicious that there could be > other underlying motivations for this trend. > > Crucially, as other people have noted, the dust UTXOs these ordinals > transactions leave behind combined with the fact that consolidation > transactions are being priced out due to persistent high fees is also causing > the size of the UTXO set to blow up. As you can see on the chart below, on > April 30 2023 there were roughly 90M UTXOs, while as of this writing roughly > 7 months later, there are more than 140M. Practically, this means that over > the course of the last year, the chainstate as stored by Bitcoin Core has > increased from ~5GB to ~9GB. > > See https://www.blockchain.com/explorer/charts/utxo-count - the 3Y chart > makes the sudden change in the rate of increase very obvious. More than twice > the number of UTXOs has been added in the last six months than in the > preceding two and a half years. > > While it is certainly not constant, if you watch the fee rates and timing of > when transactions are broadcast using a live view of the mempool like > mempool.space, you can see that especially during periods of low mempool > influx like early mornings on weekends, there tends to be large bursts (often > several hundred kvB worth) of tiny ordinals/BRC-20 transactions with a single > dust UTXO broadcast right after each block is found, with a fee set > moderately higher than the current average of the top of the mempool, which > makes it highly likely that this is done by a single actor. There may of > course be legitimate explanations for these patterns, like that they are > simply taking advantage of the lower fees, but the impression they leave me > is that they seem deliberately timed and priced to pad blocks during such > periods to prevent the mempool from draining, under the guise of "minting" > BRC-20 tokens. > > For example, in the two-minute span between blocks #820562 and #820563 from > Sunday December 10th, over a thousand of these transactions were broadcast: > > https://mempool.space/block/00015d5065ea2ade8bfd0bb9483835c907e34dd969854345 > https://mempool.space/block/1ae267367ade834627df7b119a2710091b3f5d8c1a88 > > Most of these transactions have been in the 30-60 sat/vB range, with > occasional periods of increasingly higher-fee transactions going higher. The > morning of Saturday December 16th is a good example of the latter, where > there was an ~8 hour flood where the fees were pushed all the way up to 700 > sat/vB. These are particularly suspicious, seeing as it would not make much > sense to "take advantage of lower fees" by flooding transactions with fees > increasingly and systematically set this much higher than the best next-bloc
Re: [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks
On Sun, Dec 17, 2023 at 1:47 PM ArmchairCryptologist via bitcoin-dev wrote: > Critically, this means that the higher the ratio of the hashrate is > participating, the lower the cost of the attack. If 100% of miners > participate with a ratio of transactions equal to their hashrate, the cost of > the attack is zero, since every participating miner will get back on average > 100% of the fees they contributed, and 0% of the fees will be lost to honest > miners (of which there are none). It would not be an equilibrium, because each of them can increase his profit by not participating. He can still collect fees from fee-stuffing transactions of others and high fees from transactions of normal users. > Observe also that miners would not have to actively coordinate or share funds > in any way to participate. If a miner with 10% of the participating hashrate > contributes 10% of the fee-stuffing transactions, they would also get back on > average 10% of the total fees paid by transactions that are included in > blocks mined by participating miners, giving them 10% of the profits. As > such, each participating miner would simply have to watch the mempool to > verify that the other participating miners are still broadcasting their > agreed rate/ratio of transactions, the rest should average out over time. He can pretend to have less hashrate and mine some blocks under the table. For example, a miner who has 10% real hash rate could say to other colluding miners that he only has 5%. Another 5% are secretly allocated to a new pool. So his share of costs of fee-stuffing transactions decreases, while he actually collects the same amount of fees using both public and secret parts of his hash rate. Eventually every rational participant of this collusion will do this and the ratio of participating miners will decrease. -- Best regards, Boris Nagaev ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks
On Sun, Dec 17, 2023 at 11:11:10AM +, ArmchairCryptologist via bitcoin-dev wrote: > ** A possible solution, with some caveats ** > > My proposed solution to this would be to add partial transaction fee burning. > If 50% or more of transaction fees were burned, this should effectively > curtail any incentive miners have for padding blocks with junk transactions > in general, as it would both significantly reduce the amount of spent fees > they would be able to recoup, and also reduce the amount of benefit they gain > from the transaction fees being high. The burn rate would however necessarily > have to be less than 100%, otherwise miners would not be incentivized to > include any transactions at all, and might as well be mining empty blocks. Fee-burning solutions are easily bypassed with out-of-band fee payments. If fee-burning was possible, I would have proposed it already as a way to ensure there is always an incentive for miners to mine blocks. Unfortunately, it does not work. > Changing fee estimation algorithms across the board to not take historical > fee data into account, eliminating the long-term decaying fee effects > observed after short-term flooding of high-fee transactions, would of course > significantly help prevent such attacks from being profitable in the first > place without requiring any sort of fork. As such, I believe this should also > be done as a short-term makeshift solution. A less exploitable estimate could > be made by limiting the algorithms to only use the current mempool state and > influx rate, as well as possibly the estimated current blockrate and the > arrival times of recent blocks. Additionally, wallets could pre-sign a number > of replacement transactions spending the same UTXO(s) with gradually > increasing fees up to a maximum specified by the user, and automatically > broadcast them in order as the state of the mempool changed. And I'm sure > there are additional strategies that could be used here as well to make the > ecosystem more fee-optimal in general. Yes, RBF needs to be used a lot more. CPFP is inefficient and wasteful, and estimates are quite often wrong. > Unfortunately, as long as some parties still use historic fee data for their > fee estimation, the attack could still be effective up to a point. Payment > providers like BitPay for example currently specify that you need to use a > historically high fee for the initial transaction for it to be accepted, and > does not recognize replacement transactions that bump the fee. BitPay is just a garbage payment processor. Possibly intentionally so, with the aim of getting big block policies introduced. BTW note how if mining pools are intentionally flooding the network to increase fees, mining pools such as Ocean that filter out fee-paying transactions that are part of the (possible) attack actually contribute to this problem by reducing the cost of the attack. -- https://petertodd.org 'peter'[:-1]@petertodd.org signature.asc Description: PGP signature ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
