Hi Antoine,
>
I'm interested if you can propose a formal or mathematical definition of what constitute
> an in-topic of off-topic comments on a matters like full RBF, which has been controversial
> for like a decade.
I will quote _willcl-ark_'s last comment as I do not have enough permissions in bitcoin core repository to moderate comments:
"However the comments section here has become difficult to follow due to numerous off-topic comments, a few personal disagreements, and repetition of arguments. In the interest of having a more productive and focused technical and philosophical discussion we are going to close and lock this PR."
A new pull request should help reviewers. If you do not agree with it, feel free to discuss it with moderators in bitcoin core IRC channel.
>
Again, I'm interested if you can propose a formal or mathematical definition of what constitute
> a reasonable bitcoin core vulnerability handling policy and that way give more ground on qualifying
> if a present situation is falling out of this reasonable guidelines and that can be qualified more
> objectively as "politics".
> I think we have a mailing list to favorize textual long format and encourage a more self-reflexive
> mode of reasoning in the conduct of bitcoin engineering discussions. I believe comments not bringing
> new factual information or pointing to past experiences or concrete piece of information are better
> left to twitter / nostr / reddit, whatever other communication channel where the scientific and
> ethics of conversation standards are less stringent.
Ironically, this is exactly how moderation works in bitcoin core pull requests and some comments were marked off-topic..
/dev/fd0
floppy disk guy
On Saturday, July 20, 2024 at 12:01:12 AM UTC Antoine Riard wrote:
Hi /dev/fd0
> The last comment in the pull request suggests opening a new pull request to enable full RBF by default, referencing the one closed due to off-topic comments.
I'm interested if you can propose a formal or mathematical definition of what constitute
an in-topic of off-topic comments on a matters like full RBF, which has been controversial
for like a decade. I can only think such definition could make future conversations about
the boundaries of what is in / off bitcoin engineering topic more objective.
> It seems that you are the one trying to politicize this issue.
Let's be realistic on the state of bitcoin core security issues handling in the recent words of
a group of some active contributors:
"The project has historically done a poor job at publicly disclosing security-critical bugs, whether
externally reported or found by contributors. This has led to a situation where a lot of users perceive
Bitcoin Core as never having bugs. This perception is dangerous and, unfortunately, not accurate." [0].
[0] https://groups.google.com/g/bitcoindev/c/Q2ZGit2wF7w
Again, I'm interested if you can propose a formal or mathematical definition of what constitute
a reasonable bitcoin core vulnerability handling policy and that way give more ground on qualifying
if a present situation is falling out of this reasonable guidelines and that can be qualified more
objectively as "politics".
I think we have a mailing list to favorize textual long format and encourage a more self-reflexive
mode of reasoning in the conduct of bitcoin engineering discussions. I believe comments not bringing
new factual information or pointing to past experiences or concrete piece of information are better
left to twitter / nostr / reddit, whatever other communication channel where the scientific and
ethics of conversation standards are less stringent.
All that said, I'm thinking to agree that the usage of all political rhethoric is a fallacy better
left for expressions on other communication channels and this is note wise to bundle it with novel
technical information, as from the outset it does not favor to concentrate the discussion on the fact
and logical reasoning themselves. Even more, political rhetoric very easily downgrade in moralistic
contest among protagonists on who has the monopole of the good / truth. Somehow bitcoin is beyond
good and evil (-- under some long-term and abstract perspective).
Best,
Antoine
ots hash: 3088507ecfb55ed301bb0defce9fb490daa6bb9594e96d57336d603556a8fdab
Le vendredi 19 juillet 2024 à 19:27:36 UTC+1, /dev /fd0 a écrit :
Hi Peter,
> I didn't get a substantive
> response from Bitcoin Core, other than Core closing the my pull-req enabling
> full-RBF by default that would fix this specific vulnerability.
The last comment in the pull request suggests opening a new pull request to enable full RBF by default, referencing the one closed due to off-topic comments.
> But read on, this is quite an odd case of Core politics, and the story is not
> as simple as Core refusing to fix a vulnerability.
It seems that you are the one trying to politicize this issue.
/dev/fd0
floppy disk guy
On Thursday, July 18, 2024 at 4:04:26 PM UTC Peter Todd wrote:
# Summary
This is a public disclosure of a vulnerability that I previously disclosed to
the bitcoin-security mailing list. It's an easy vulnerability to fix. Although
as with other "free" relay attacks I've disclosed, I didn't get a substantive
response from Bitcoin Core, other than Core closing the my pull-req enabling
full-RBF by default that would fix this specific vulnerability.
But read on, this is quite an odd case of Core politics, and the story is not
as simple as Core refusing to fix a vulnerability. Also, I've including a fun
homework problem at the end: figure out how TRUC/V3 transactions itself creates
a "free" relay attack.
# Background
This is just one of a few "free" relay attacks that I have recently disclosed,
including, but not limited to:
"A Free-Relay Attack Exploiting RBF Rule #6" - Mar 18th 2024
https://groups.google.com/g/bitcoindev/c/EJYoeNTPVhg
"A Free-Relay Attack Exploiting Min-Relay-Fee Differences" - Mar 31st 2024
https://groups.google.com/g/bitcoindev/c/3XqfIOYzXqo
The term "free relay attack" simply refers to any mechanism where transaction
data can be broadcast at unusually low cost; the "free" in "free relay" is a
misnomer as all these attacks do in fact have some cost.
This particular attack isn't significantly different than the other attacks
I've disclosed. With one important exception: unlike those other attacks,
fixing this particular attack would be quite easy, by enabling full-rbf by
default. So I disclosed it to the bitcoin-security mailing list as a test: does
Bitcoin Core actually care about free relay attacks? My hypothesis is that Core
does not, as they know full well that "free" relay is an unavoidable problem;
I've received absolutely no feedback from any Bitcoin Core members for the
other disclosed attacks, beyond achow using my disclosure of the RBF Rule #6
attack as an excuse to remove me from the bitcoin-security mailing list.
The fact that Core doesn't actually care about "free" relay attacks is relevant
to TRUC/V3 Transactions. As per BIP-431:
"The primary problem with [RBFR proposals] is the potential for free relay and DDoS attacks.
Removing Rule 3 and 4 in general would allow free relay [27]."
https://github.com/bitcoin/bips/blob/812907c2b00b92ee31e2b638622a4fe14a428aee/bip-0431.mediawiki#user-content-Alternatives_replace_by_feerate
I believe the authors of that BIP are fully aware of the fact that "free" relay
is an unavoidable problem, making their rational for TRUC/V3 bogus, and don't
want to admit that they've wasted a large amount of engineering time on a bad
proposal. I will be submitting a pull-req to get BIP-431 corrected, as the many
"free" relay attacks I've disclosed clearly show that claiming RBFR would
"allow" free relay is simply not true.
Notably, full-RBF is _itself_ a transaction pinning fix for many use-cases;
part of the TRUC/V3 standard is to force full-RBF behavior for V3 transactions.
So Core closing my full-RF pull-req is doubling down on TRUC/V3 in a second
way, and TRUC/V3 proponents were the ones who tried to get the full-RBF option
removed from Core in the first place. If not for this dumb bit of Core
politics, I'm sure my year-old pull-req to enable full-RBF by default would
have been merged many months ago, as almost all hashpower has adopted full-RBF
making objections based on "zeroconf" absurd.
# The Attack
If you're a competent Bitcoin engineer, familiar with how mempools work, you've
probably figured it out already based on the title: obviously, if a high
percentage of miners are adopting a policy that Bitcoin Core nodes are not, you
can cheaply consume transaction relay bandwidth by simply relaying transations
that miners are rejecting.
Specifically, do the following:
1. Broadcast a small, low-fee-rate, tx A with BIP-125 opt-in disabled.
2. Broadcast a full-RBF double-spend of A, A2, with a higher fee-rate.
3. Spend the outputs of A in a large, low fee-rate, transaction B with BIP-125
opt-in enabled. ~100% of miners will reject B, as it spends an input not in
their mempools. However Bitcoin Core nodes will waste bandwidth propagating
B.
4. (Optional) Double-spend B repeatedly. Again, Bitcoin Core nodes will waste
bandwidth propagating Bn's that ~100% of miners are ignoring.
5. Double-spend A2 to recover your funds and do it all over again (or if A2 had
a high enough fee-rate, just wait for it to be mined).
The cost to relay each B transaction depends on the fee-rate of B. Since
Bitcoin Core defaults to a fairly large mempool, the minimum relay fee-rate is
typically well below the economic fee-rate required for miners to actually mine
a transaction; Core accepts transactions that are uneconomical for miners to
mine for the forseeable future.
For example, at the moment typical mempools require transactions to pay at
least 1sat/vB, while there are hundreds of MvB worth of transactions paying
4sat/vB, the minimum economical fee-rate. Thus, transactions paying less than
4sat/VB are extremely unlikely to get mined in the nearish future.
Concretely, broadcasting B transactions at 1sat/vB, 2sat/vB, and 3sat/vB would
have almost zero cost as the probability of those transactions getting mined is
nearly zero. This is true _regardless_ of what % of miners are mining full-RBF!
As long as you can get at least one miner to mine the A double-spend, the
attack only costs what it cost to get A mined.
If B's are broadcast at a higher fee-rate than the minimum economical fee-rate,
then the % of full-RBF miners matters. For example, if only 99% of miners mine
full-RBF, the chance of a B transaction getting mined per block is about 1%, so
the amortized cost of broadcasting B is about 1% of whatever total fee the
highest fee-rate variant of B pays.
For an attacker who does not need any B to be broadcast, the cost savings to
use of relay bandwidth is approximately the ratio of the difference in size
between B and and A. With a maximum standard transaction size of 100KvB, or
400KB serialized size, this ratio is on the order of 5000:1, times the total
number of B variants broadcast, and the % chance of each B being mined; it's a
few orders of magnitude.
Of course, as mentioned above, this is just one of *many* "free" relay attacks,
so fixing this particular issue doesn't change much.
# Attackers Who Benefit From B Getting Mined
Some attackers actually need B to get mined. For example, imagine an exchange
who needs to do large consolidation transactions. They could use this attack
(and some attacks like it) as a way to goad users and miners into mining
consolidation transactions for them at low cost. In this variant of the attack,
the attacker would pad the size of B with consolidation spends that they needed
to do anyway. Someone who tried to stop the attack by getting B mined (eg via
mempool.space's transaction accellerator) would simply be paying the attacker's
fees for them.
Obviously, this strategy is only relevant for B's below the economic fee-rate.
However, the weaker version of this strategy is to parallize the attack, and do
your consolidation with the _A_ double-spends to reduce the # of bytes used per
full-rbf double-spend.
# TRUC/V3 Creates a Free Relay Attack
I'll leave the details of this as a homework problem. But obviously, the
introduction of TRUC/V3 transactions *itself* creates a free relay attack very
similar to the above! Just like full-RBF, not all miners will mine V3
transactions. So you can do the exact same type of attack by taking advantage
of this difference in mining policy.
--
https://petertodd.org 'peter'[:-1]@petertodd.org