From: Peter Todd <pete@petertodd•org>
To: ArmchairCryptologist <ArmchairCryptologist@protonmail•com>,
Bitcoin Protocol Discussion
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Addressing the possibility of profitable fee manipulation attacks
Date: Sun, 17 Dec 2023 17:56:16 +0000 [thread overview]
Message-ID: <ZX82QKJCLLPMfHXl@petertodd.org> (raw)
In-Reply-To: <e5QWFNC21ZBNRZ_k0IJTSjTMm_7tvu8eu9seo84N4X87niVTfsDMv3I5l7YZgZ7zSXqNIlsGk-necWsDXsMd9AG8wnEBappboXMVsqygmiM=@protonmail.com>
[-- Attachment #1: Type: text/plain, Size: 2959 bytes --]
On Sun, Dec 17, 2023 at 11:11:10AM +0000, 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
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2023-12-17 17:56 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-12-17 11:11 ArmchairCryptologist
2023-12-17 17:56 ` Peter Todd [this message]
2023-12-18 0:30 ` Nagaev Boris
2023-12-18 6:26 ` alicexbt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZX82QKJCLLPMfHXl@petertodd.org \
--to=pete@petertodd$(echo .)org \
--cc=ArmchairCryptologist@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox