Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 73D77C0037 for ; Mon, 18 Dec 2023 06:26:58 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 3BFA940377 for ; Mon, 18 Dec 2023 06:26:58 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 3BFA940377 Authentication-Results: smtp2.osuosl.org; dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com header.a=rsa-sha256 header.s=protonmail3 header.b=kpFig7FP X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.8 X-Spam-Level: X-Spam-Status: No, score=-0.8 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, PDS_OTHER_BAD_TLD=1.999, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2bTT2Gm-gVc4 for ; Mon, 18 Dec 2023 06:26:55 +0000 (UTC) Received: from mail-0301.mail-europe.com (mail-0301.mail-europe.com [188.165.51.139]) by smtp2.osuosl.org (Postfix) with ESMTPS id ED6FF4010C for ; Mon, 18 Dec 2023 06:26:54 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org ED6FF4010C DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail3; t=1702880806; x=1703140006; bh=2IoC6AMjTn/CNJXs8pqIM7FHC0bg6aaZVv1IY7Zypdc=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=kpFig7FPhVNN8eSd0w+DXJzUrPGtVBFPB2aNNqOTiBgBVxj0QWNgjTn1N0YN8XlIP nwBw8la6+ZiLVcWKzn366NXEOtl+2DCpW1d1ainGNN1CnVoNOzBCv2pqnlyWmcou0U EysSX3US1/u/On20d/Cdrz+I+59YLycbE9vkXoKFtw5g1DdIjrH/ZUc0tPXbrOX5H5 KS68mE2gcWn79QmAsCBPkNAV1CjeIRH8EGUw3xRByGlJ/inOX5lmQpKM5+gLveC+TL Dwt2NWAPw7i4G882GZFktkVDKQciYNW5PUZyDiLB85qA+xzgJ9Wv7KrpKMNiMRhWnC caQtpbJmKYkOg== Date: Mon, 18 Dec 2023 06:26:28 +0000 To: ArmchairCryptologist From: alicexbt Message-ID: In-Reply-To: References: Feedback-ID: 40602938:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Mailman-Approved-At: Mon, 18 Dec 2023 09:19:13 +0000 Cc: "bitcoin-dev@lists.linuxfoundation.org" Subject: Re: [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Dec 2023 06:26:58 -0000 Hi ArmchairCryptologist, Bitcoin is working as expected and I don't see any 'manipulation' attacks i= n the bidding for block space. Maybe we aren't used to such demand for bloc= kspace on bitcoin. Additionally, fingerprinting based on fee rates and timi= ng to attribute transactions to a single person is inaccurate. Various serv= ices, such as unisat, are used for deploying and minting BRC20 tokens based= on region, community etc. Consequently, a service broadcasting Bitcoin tra= nsactions might appear as a single individual. With regards to UTXO set, IBD for machines with enough RAM seems to be unaf= fected, however I have not done benchmarking to compare IBD before and afte= r inscriptions with less dbcache. Also the number of full nodes have increa= sed in last one year. > However, in practice, the attack appears to rely on exploiting the inhere= nt decay used by fee estimation algorithms that are based on historical fee= data. This causes many wallets to create transactions that overpay the nec= essarily 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 wer= e being mined.=20 Bitcoin Core fee estimation has known issues since years, and I would not r= ecommended 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 burn= ing.=20 NACK /dev/fd0 floppy disk guy Sent with Proton Mail secure email. On Sunday, December 17th, 2023 at 11:11 AM, ArmchairCryptologist via bitcoi= n-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 introdu= ction of ordinals, and while this may be both technically and actually true= , disregarding the debate of whether ordinals is a "valid use" or the block= chain or not, the specific patterns we are seeing for some of these transac= tions have been making me somewhat suspicious that there could be other und= erlying motivations for this trend. >=20 > Crucially, as other people have noted, the dust UTXOs these ordinals tran= sactions leave behind combined with the fact that consolidation transaction= s 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 mont= hs later, there are more than 140M. Practically, this means that over the c= ourse of the last year, the chainstate as stored by Bitcoin Core has increa= sed from ~5GB to ~9GB. >=20 > 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 twi= ce the number of UTXOs has been added in the last six months than in the pr= eceding two and a half years. >=20 > 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 m= empool.space, you can see that especially during periods of low mempool inf= lux like early mornings on weekends, there tends to be large bursts (often = several hundred kvB worth) of tiny ordinals/BRC-20 transactions with a sing= le dust UTXO broadcast right after each block is found, with a fee set mode= rately higher than the current average of the top of the mempool, which mak= es it highly likely that this is done by a single actor. There may of cours= e be legitimate explanations for these patterns, like that they are simply = taking advantage of the lower fees, but the impression they leave me is tha= t 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. >=20 > For example, in the two-minute span between blocks #820562 and #820563 fr= om Sunday December 10th, over a thousand of these transactions were broadca= st: >=20 > https://mempool.space/block/000000000000000000015d5065ea2ade8bfd0bb948383= 5c907e34dd969854345 > https://mempool.space/block/000000000000000000001ae267367ade834627df7b119= a2710091b3f5d8c1a88 >=20 > Most of these transactions have been in the 30-60 sat/vB range, with occa= sional periods of increasingly higher-fee transactions going higher. The mo= rning of Saturday December 16th is a good example of the latter, where ther= e 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 se= nse to "take advantage of lower fees" by flooding transactions with fees in= creasingly and systematically set this much higher than the best next-block= fee at this time of the week. There are many blocks during this period wit= h noticeable large clusters of these high-fee BRC-20 transactions - for exa= mple, see #821428 and #821485: >=20 > https://mempool.space/block/000000000000000000011dd74372ff2d5fdec5e743134= 0a160b0304f3f145e82 > https://mempool.space/block/00000000000000000000653a2389a42549943c859e414= f451f86944ac60b411b >=20 > You would think that if someone were in fact making a large volume of tra= nsactions specifically to inflate the transaction fees, they would eventual= ly run out of funds to do so. In other words, considering how long this tre= nd has been going on, they would either need to have exceptionally deep poc= kets, or directly profit from the transaction fees being high. This line of= thought lead me to consider the possibility that such patterns could be in= dicative of ongoing fee manipulation by either a large miner or a consortiu= m of miners, and whether such manipulation could be practically profitable,= even with a minority hashrate. While miners have always had the ability to= pad their own blocks with junk transactions, it seems to be generally assu= med that at the very least there would be an opportunity cost of doing so, = and that it would therefore would be unprofitable. The general ability to p= ad all blocks with junk transactions would of course both be much more seve= re and much less obvious. So if this were the case, I believe it would brea= k a fundamental assumption to the design of Bitcoin - seeing as transaction= fees are central to prevent DoS attacks on the blockchain, if such an atta= ck could be done in a way where both the base costs and opportunity costs a= re fully (or more than) recouped, we have a problem. >=20 > Just to be clear - I'm not saying with any certainty that such an attack = is currently ongoing, has taken place in the past, or will take place in th= e future. Providing hard evidence of such would be difficult or impossible,= so this should be considered pure conjecture based on circumstantial evide= nce. As such, seeing as conspiracy theories are generally unhelpful, I will= ultimately only consider whether an attack such as this could be theoretic= ally profitable. All the transactions observed may very well be "legit" in = the sense that they have nothing to do with fee manipulation, but for the s= ake of argument we will run some numbers under the hypothesis that this is = the ultimate goal, even if it is in fact coincidental. >=20 >=20 > ** A short analysis, of the napkin kind ** >=20 > Simply put, and trivially, such an attack would be profitable if the net = fees the participating miners spend on fee-stuffing transactions is less th= an the increase in fees the participating miners can collect from "real" tr= ansactions. >=20 > The cost for carrying out the attack primarily has three factors: the rat= io of participating miners, the ratio of fee-stuffing transactions required= to maintain full blocks with a high fee level, and the per-transaction fee= s required for these. >=20 > The ratio of participating miners is important since it determines how mu= ch of the spent fees are lost to miners that do not participate in the atta= ck. If 20% of the hashrate participates, on average 20% of blocks will be m= ined by these miners, recouping these fees. Which means the net amount of f= ees spent on the attack in this case is 80% of the gross fees spent on the = creating these transactions - the remaining fraction of the fees would be c= ollected by the honest miners instead. >=20 > Critically, this means that the higher the ratio of the hashrate is parti= cipating, the lower the cost of the attack. If 100% of miners participate w= ith 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). >=20 > The ratio of fee-stuffing transactions required to maintain full blocks w= ith a high fee level and their required fees would vary over time - weekend= s have fewer transactions, for example, and consistently high fees would li= kely reduce the number of people attempting to use the blockchain at all. N= ote however that in the degenerate case where all miners are participating,= these two factors would be much less important, since all spent fees are r= ecouped anyway, so it would only affect the absolute number of fees spent f= or real transactions. >=20 >=20 > If all real transactions were fee-optimal, using low-balled fees based on= the current mempool only and actively using fee bumping to barely squeak i= nto a block, the total cost of the attack per block could be easily approxi= mated as: (ratio of fee-stuffing transactions lost to honest miners) * (rat= io of fee-stuffing transactions to real transactions) * (total block transa= ction fees) >=20 > However, in practice, the attack appears to rely on exploiting the inhere= nt decay used by fee estimation algorithms that are based on historical fee= data. This causes many wallets to create transactions that overpay the nec= essarily 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 wer= e being mined. This means that the actual cost would likely be much lower. = Seeing as this would be difficult to model, we would need to estimate the a= bsolute cost to maintain a 100% block fillrate with high fees over time bas= ed on observations and some guesswork. Looking at the bursts of transaction= s we have seeing over the last few months during low-influx periods, most o= f them are in the 40-60 sat/vB range, so it seems reasonable to conclude th= at you can maintain this high fee level with transactions averaging ~50 sat= /vB. >=20 > The increase in fees that can be collected from real transactions is also= difficult to model. There is an opportunity cost for participating miners = from mining their own fee-stuffing transactions instead of legitimate trans= actions, and it would depend greatly both on how many transactions are will= ing to outbid the fee-stuffing transactions at a particular fee level, the = decay rate used by fee-estimation algorithms, as well as the cascading fee-= related effects of blocks being full 100% of the time, leading to low-fee t= ransactions never being mined. Due to the non-homogeneous nature of the eco= system, estimating these factors individually would require a lot of (weak)= assumptions, but we can make some higher-level estimates based on real-wor= ld data by comparing the fees collected from mined transactions today compa= red to fees collected a year ago. >=20 > See https://www.blockchain.com/explorer/charts/transaction-fees - if we u= se the 30D average, we were at around 20 BTC/day a year ago compared to aro= und 150 BTC/day when this was written. With 144 blocks per day, this is app= roximately 0.14 BTC/block a year ago, and 1.05 BTC/block right now. >=20 > The gross profit for the attack would then simply be: ( (total average bl= ock transaction fees with attack) - (total average block transaction fees w= ithout attack) ) * (ratio of blocks mined by participating miners) >=20 > Using these numbers, the cost of a hypothetical attack would have to be o= n average less than 0.9 BTC per block mined by participating miners to be p= rofitable. >=20 > So let's plug in some hypothetical numbers, using these assumptions toget= her with the current real-world data under the hypothesis that such an atta= ck is currently taking place, and that the current fee spike can be explain= ed by it. >=20 > If we assume that 20% of miners participate in the attack and they need t= o fill on average 20% of each block (200 kvB) with an average transaction f= ee of 50 sat/vB to effectively maintain high fees: >=20 > The average cost per block would be 50 sat/vB * 200000 vB =3D 0.1 BTC >=20 > The gross profit would be 0.9 BTC * 0.2 =3D 0.18 BTC averaged per block >=20 > This gives a net profit of 0.18 BTC - 0.1 BTC =3D 0.08 BTC averaged per b= lock >=20 > Which would result in an average daily net profit shared among the partic= ipating miners of 144 * 0.08 =3D 11.52 BTC, or around US$ 500K at today's p= rice. (Non-participating miners would of course profit as well.) >=20 > Just to emphasize - the profits are averaged over all blocks mined on the= network, not just the ones mined by participating miners, since the cost i= s incurred on every block regardless of who mines it. With these numbers, t= hese participating miners would have a loss of 0.1 BTC per block they did n= ot mine, and a gain of 0.8 BTC for every block they did mine, with 20% of t= he hashrate obviously averaging 1 in every 5 blocks - or somewhat restated,= 4 * -0.1 + 0.8 =3D 5 * 0.08 =3D 0.4 BTC per 5 blocks. >=20 > If you keep the other hypothetical factors constant, the break-even numbe= rs in this example would be an average fee-stuffing transaction fee of 90 s= at/B, 11.1% participating miners, or 36% required fill rate. > Observe also that miners would not have to actively coordinate or share f= unds in any way to participate. If a miner with 10% of the participating ha= shrate contributes 10% of the fee-stuffing transactions, they would also ge= t back on average 10% of the total fees paid by transactions that are inclu= ded 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. >=20 > In short, I believe this is a real problem. The premise of this analysis = is based on conjecture and casual observation which is vulnerable to confir= mation bias, and obviously cannot be considered proof that anything fishy i= s going on at present. However, regardless of the intent of these transacti= ons, their existence and effect on the fee is obvious for everyone to see, = so I feel relatively safe to conclude that under certain conditions where b= locks are mostly full most of the time, a small-ish minority hashrate could= potentially manipulate the network fees for a significant profit with no a= ctive coordination. As we are seeing, this would cause both unnecessarily h= igh fees for people wanting to use the blockchain, and long-term issues wit= h a bloated UTXO set that affects both fully archiving and pruning Bitcoin = Core nodes as well as all other software that needs to keep a record of uns= pent transactions. In my opinion, it is necessary to address this. >=20 >=20 > ** A possible solution, with some caveats ** >=20 > My proposed solution to this would be to add partial transaction fee burn= ing. If 50% or more of transaction fees were burned, this should effectivel= y curtail any incentive miners have for padding blocks with junk transactio= ns in general, as it would both significantly reduce the amount of spent fe= es 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 nec= essarily have to be less than 100%, otherwise miners would not be incentivi= zed to include any transactions at all, and might as well be mining empty b= locks. >=20 > While this change by itself could be implemented with a soft fork, miners= would be (highly) unlikely to accept such a change, since it would directl= y reduce the profits even for honest miners. However, this solution could e= ffectively complement arguments made by Peter Todd and others regarding the= future of block subsidy, which in short go along the lines that block subs= idy halvings should be stopped at some point with a hard fork, leaving a pe= rpetual fixed subsidy per block. By itself this would arguably make Bitcoin= into an inflationary currency, which many people object to, but if you com= bine it with partial fee burning, it could very well become deflationary in= stead depending on how the fee market develops, while still providing a gua= ranteed minimum reward per block. This would effectively alleviate the dang= er of a deficient fee market compromising the security of the blockchain du= e to low miner rewards at some point in the future, while only adding an "a= bout" to the statement "there will only ever be 21 million coins". >=20 > For example, if the collected fees in the year prior to such a hard fork = being implemented were on average 1 BTC per block, and it was decided to bu= rn 50% of the fees, the subsidy could be increased by a fixed 0.5 BTC which= would not be affected by halvings. In other words, when the current subsid= y starts approaching zero, we would be left with a perpetual static subsidy= of 0.5 BTC and change per block, without drastically affecting the total c= oin supply. Worst case, if fees collapsed entirely we would have an inflati= on of ~0.1% per year=C2=A0(0.5 BTC/block * 144 blocks/day * 365 days/year = =3D 26280 BTC/year) not taking permanently lost coins into account, while o= n the other hand, if fees went higher still then the deflation would not ha= ve a fixed limit, unless an absolute limit for burned fees per block was ad= ded. >=20 >=20 > I did briefly consider the possibility of doing this with a soft fork ins= tead, where the "burned" fees were instead transferred into a special "subs= idy fund address" that would be drawn from by miners to effectively increas= e the block subsidy, but seeing as this would not remove the correlation be= tween intentionally inflating fees and increasing miner rewards, I don't be= lieve this would actually address this attack. For the same reason, adding = a dynamic subsidy based on historic fee rates would have the same problem, = so it would necessarily have to be a fixed additional subsidy. >=20 > It is important to emphasize that if the goal is to fully address this ty= pe of miner attack in general, increasing the blocksize would NOT be a viab= le solution by itself. If the blocksize increase is large enough and the fr= action of participating miners is low enough, then yes, it would probably t= hwart it, but if the majority (or all) miners participated, it would have l= ittle (or no) effect unless the blocksize was unbounded, which does not see= m like a good idea. While the absolute amount of fees the miners would need= to spend for fee stuffing would of course increase, the fraction of spent = fees miners would recoup would not change, so if 100% of miners participate= d, 100% of fees used in the attack would still be recouped regardless of th= e absolute number of transactions it would take to fill a block. Furthermor= e, the absolute number of transactions willing to outbid them would not cha= nge, so the extra fees gathered from the attack would remain the same as we= ll. >=20 > Additionally, if the attack continued, the rate of increase of the size o= f the UTXO set would likely increase by a similar factor as the blocksize i= ncrease. As such, any blocksize increase at all would in my opinion necessa= rily have to be combined with partial fee burning - possibly dynamic, based= on the size of each block - to prevent exacerbating potential attacks that= excessively and unnecessarily bloat the size of the UTXO set. It would how= ever be natural add a modest and scaling increase as part of the same fork,= seeing as the fee burning change would resolve the main argument against i= t, since adding data to the blockchain would now always have a guaranteed c= ost even for miners. >=20 > Changing fee estimation algorithms across the board to not take historica= l fee data into account, eliminating the long-term decaying fee effects obs= erved after short-term flooding of high-fee transactions, would of course s= ignificantly help prevent such attacks from being profitable in the first p= lace without requiring any sort of fork. As such, I believe this should als= o be done as a short-term makeshift solution. A less exploitable estimate c= ould be made by limiting the algorithms to only use the current mempool sta= te 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 graduall= y 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 t= here are additional strategies that could be used here as well to make the = ecosystem more fee-optimal in general. >=20 >=20 >=20 > Unfortunately, as long as some parties still use historic fee data for th= eir fee estimation, the attack could still be effective up to a point. Paym= ent providers like BitPay for example currently specify that you need to us= e a historically high fee for the initial transaction for it to be accepted= , and does not recognize replacement transactions that bump the fee. >=20 >=20 > If you made it this far, thanks for reading my wall. Please let me know i= f you find any serious mistakes in my assumptions and/or math that invalida= te the whole premise, so I can stop thinking about it. >=20 > -- > Sincerely, > ArmchairCryptologist