path: root/01/7fcc76ad4217d3a4ef689ea422d28b407d1000

Return-Path: <alicexbt@protonmail.com>
Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 73D77C0037
 for <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <bitcoin-dev@lists.linuxfoundation.org>;
 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 <ArmchairCryptologist@protonmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <XwBIMrHjY7N3DkEDVgxTHI3W3BRhijP7d4Lr7jUiR6E_fPxxPF0YyeKXwwsFiKBNjvM9NVSHrCwXwZhLr69hsYxVDkT_NUXzyN6NvQjM6FE=@protonmail.com>
In-Reply-To: <e5QWFNC21ZBNRZ_k0IJTSjTMm_7tvu8eu9seo84N4X87niVTfsDMv3I5l7YZgZ7zSXqNIlsGk-necWsDXsMd9AG8wnEBappboXMVsqygmiM=@protonmail.com>
References: <e5QWFNC21ZBNRZ_k0IJTSjTMm_7tvu8eu9seo84N4X87niVTfsDMv3I5l7YZgZ7zSXqNIlsGk-necWsDXsMd9AG8wnEBappboXMVsqygmiM=@protonmail.com>
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"
 <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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, 
 <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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 <bitcoin-dev@lists.linuxfoundation.org> 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