Miners Are Spamming Bitcoin’s Network to Increase TX Fees

This write-up is going to take a deeper look at RBF transactions than perhaps many have taken up to this point. Specifically, we’re going to look at how an augmentation to RBF transaction fees (replace-by-fee), via BIP125 ended up serving as the perfect weapon for mining pools looking to keep revenues consistent whenever the price of Bitcoin drops (and sometimes as it increases too).

Digging Back into the History of Fees on Bitcoin

Originally, fees were created as a DDoS (denial of service) prevention method. The theory was that, if one must pay a certain fee per transaction, then it would become prohibitively expensive for them to spam the network.

The second (unspoken) complement to that assumption is that nodes will generally kick out transactions that appear to be double spends.

In other words, an attacker may think that they can simply spend the same transaction a bunch of times consecutively in an attempt to spam the network without having to worry about the transaction fee because once one transaction gets confirmedn, the rest would be rejected.

But that’s not the case, because nodes would reject that double spend (as stated above).

What If?

What if I told you that someone did figure out how to broadcast double spent transactions in the mempool in a way that would not get them kicked out?

That would change things, wouldn’t it?

Let’s say… Bitcoin were to drop in price a bit, affecting my profits as a miner. I could easily boost the price back up by simply flooding the protocol with these double spend transactions.

This would have the desired impact of making each double spend look like a separate, valid transaction. Not only that — I wouldn’t even need that much money to do it since I’m double spending here (i.e., not creating separate transactions).

Starting Off With Part One

Let me teach you how miners are manipulating the network fees so that you all end up paying out of the ass whenever the price Bitcoin goes down.

First we need to look at the double spend transactions that are taking place on the blockchain right now.

They even have a running list with the transaction IDs for each one of these double spent transactions.

We’re going to go through one together in class.

You’ll be able to confirm everything that’s being written here in live time (and then we’ll attach it to the clear reason for the existence of these double spend attempts on the chain).

Proof of the Double Spend Attempt Live in the Mempool

There are a couple of comments from idiots saying that they’re not double spend transaction attempts, so I will literally so you all in live time that they are.

Root Transaction

(this is the TX that produced the UTXO that someone is attempting to double spend) = https://bitaps.com/7e045db9a3a0d7fa7476a0ed9fea0be9f3515e2c42452c2e2c66e0e624ffc25d

First TX Attempt (unconfirmed)

Can be found here: https://bitaps.com/4234df198e9a42888f995561314b8f06dfb31bb09ad090de069e46b2b802b213

Here you can see them attempting to spend from the 3NSa5aSknNkZzw4M8iiXRcW1sjid8quXdt address to:

A) 18joX1cGYHr4zVmFzE7cAo2q5UMPNsCafi

B) 1BPBY8BV78tZJk6X4RaMKQXUTiXsKX6adK

C) 3NSa5aSknNkZzw4M8iiXRcW1sjid8quXdt

Don’t worry, I left the page open in my browser, we can do the visuals after this.

Second TX Attempt

Can be found here: https://bitaps.com/afabbbf29739b5a91e52d5d324e3c22902c52b949c31da99d16642a6ea856f9d

You can see here the input is that SAME 3NSa5aSknNkZzw4M8iiXRcW1sjid8quXdt

Outputs for this transaction are also:

A) 18joX1cGYHr4zVmFzE7cAo2q5UMPNsCafi

B) 1BPBY8BV78tZJk6X4RaMKQXUTiXsKX6adK

C) 3NSa5aSknNkZzw4M8iiXRcW1sjid8quXdt

Explaining How This is Possible

Please follow carefully because people keep missing this on a repeated basis.

Everyone knows about RBF transactions (replace-by-fee). This has been in Bitcoin forever. But it did not allow the behavior that I just showed you all above.

Per the definition, “RBF” involves you replacing a transaction. That means that the node is supposed to be removing the original transaction in favor of the changed one, effectively “cancelling” the original one.

Peter Todd Augmentation: BIP125

There’s a little clause in BIP125 that everyone forgot to read. Luckily its still here for you all to check: https://github.com/petertodd/replace-by-fee-tools#replace-by-fee-tools (this is another example of Core making unilateral decisions “publicly”, without even considering the community’s input or giving anyone a second to offer their input on this measure).

Incremental-Send-Many

“Finds an unconfirmed transaction in y our wallet that has opted into full-RBF and rebroadcasts it with an additional output. If no such transaction exists, a new opt-in full-RBF transaction is created. The first transaction input is kept to ensure a double-spend; all other inputs are re-optimized for the new set of outputs.”

This has been merged into the Bitcoin Core client at: https://github.com/bitcoin/bitcoin/pull/6871

You can see in this conversation here between Peter Todd and another Core contributor that they brought up the obvious conflict that this would create.

1. You send TX #1 with a fee of 30 satoshis/byte
2. You decide to “opt-in full-RBF” the TX, which doesn’t replace the first one, but rather creates another that pays for the first one and then adds an output.

Point number 2 mandates that the fee rate raise in these chained transaction additions.

This is allegedly done to ensure that the RBF’d transaction is sent monotonically (but this isn’t what happens due to quirk in how Bitcoin Core works).

Child-Pays-For-Parent

This is going to be a confusing concept, but its important that I mention it for you to understand how miners are gaming the protocol by flooding it with these “chained” transactions.

ELI5 Breakdown

Below is a basic Bitcoin transaction:

A) Amy pays Bob 2 BTC

B) Bob waits one confirmation

C) Bob sends 2 BTC to Mary

Above we described two separate transactions. Amy’s initial send to Bob and then Bob’s send to Mary.

How “Child” Transactions Work

In theory (and in practice), let’s say:

1. Amy and Bob are in the same room next to each other
2. Amy knows that Bob is going to send those 2 BTC to Mary
3. Amy can sign her transaction and give it to Bob and then Bob can use the signed 2 BTC as an input to his transaction to Mary
4. Essentially, Bob is crafting the same transaction that he would’ve crafted originally. In theory, they should even have the same TX ID.
5. Only thing is that Alice’s transaction hasn’t actually happened yet. However, Bob’s transaction is not explicitly invalid because Bob isn’t spending money he doesn’t (theoretically) have.
6. Alice did legitimately sign an outgoing TX to Bob (which spends that output), and Bob is taking that hypothetical UTXO and spending it to Mary.

So what does the Bitcoin protocol do if Bob sends that transaction? Do nodes reject it? Would miners include it in a block? If they did, would that violate the protocol rules?

The Transaction Bob Attempts to Send is 100% Valid

Luckily, I did my homework and read the ‘Mastering Bitcoin’ compendium (great read, by the way – lots of good reference info).

With regards to Bob and Amy, their transaction is considered 100% valid by nodes. Not only that, it receives special treatment too.

More on that here:

Relevant Bits From ‘Mastering Bitcoin’

“When a chain of transactions is transmitted across the network, they don’t always arrive in the same order. Sometimes, the child might arrive before the parent. In that case, the nodes that see a child first can see that it references a parent transaction that is not yet known.”

• In that transaction I described above, the transaction that Amy signed and then gave to Bob (but didn’t broadcast), would be considered the parent transaction.
• The TX that Bob broadcasted, which includes that parent transaction + his attempt to spend those same 2 BTC to Mary is known as the child transaction (the entire chain is known as the child).
• In that transaction I described above, the transaction that Amy signed and then gave to Bob (but didn’t broadcast), would be considered the parent transaction.
• The TX that Bob broadcasted, which includes that parent transaction + his attempt to spend those same 2 BTC to Mary is known as the child transaction (the entire chain is known as the child).

Apologies if this is confusing, but this is the most basic way I can use to explain this phenomenon.

There’s More From Mastering Bitcoin

“Rather than reject the child, they put it in a temporary pool (not the mempool) to await the arrival of its parent and propagate it to every other node. The pool of transactions without parents is known as the orphan transaction pool.”

and

“Once the parent arrives, any orphans that reference the UTXO created by the parent are released from the pool, revalidated recursively, and then the entire chain of transactions can be included in the transaction pool, ready to be mined in a block.”

plus

“Transaction chains can be arbitrarily long, with any number of generations transmitted simultaneously. The mechanism of holding orphans in the orphan pool ensures that otherwise valid transactions will not be rejected because their parent has been delayed and that eventually the chain they belong to is reconstructed in the correct order, regardless of the order of arrival.“

Almost Proved Collusion By Miners – But There’s One More Step Left (Pt. 1)

What I’ve written above is not sufficient to prove that the miners are engaging in any monkey business here. Clearly.

We know something funny is going on because sending these transactions is ultimately more expensive for the original sender since they have to:

1. Create a child transaction
2. Ensure that child transaction at least spends the entire fee from original TX (parent can’t have a lower TX fee on the child submission)
3. The child tx must have a higher fee than the parent
4. The child must also account for the additional bandwidth in the new parent transaction that they create

I know that this is confusing as fuck. Don’t stress over it because that’s not necessarily critical information to follow along from here.

Almost Proved Collusion By Miners – But There’s One More Step Left (Pt. 2)

This is where it gets easier, ok?

We need to look at some on-chain metrics.

Namely, we need to look at:

• Out of the total reward miners receive, what % of that was fees?: When miners win a block, they get 6.25 bitcoins, we all know that. They also get all of the fees too (if they decide to keep them all). That “reward” is all added up together (block reward + fees). This looks at how much of that total bundle comes from fees.
• Average TX per Day: Straightforward
• Average TX Confirmed Per Block: This is another critical metric we need to look at here

Now, I’m going to share my findings with all of you guys, which might blow your fucking minds.

Here are the total # of transactions (per day) on Bitcoin on January 7th-11th (390k to 325k ; 17% decrease):

Here, we can see that the price declined by over -25% from its peak on January 7th to its lowest point on January 11th:

Yet somehow at the same time, miners saw their total block reward skyrocket from $264,000 to $303,000 (+13% increase):

Since we know the price declined by over -25% at one point in time, we know that this gain in total reward can’t be due to the price of Bitcoin increasing.

So let’s look at the fees raked in from miners over that same period of time.

From what Bitinfocharts shows us, we can see that the fees went from averaging around 10% to 12% (twenty percent increase here):

This is baffling though, because if:

A) The price of Bitcoin is going down

and

B) The total # of transactions is declining significantly as well

So how could miners end up having their most profitable day of 2021 thus far with ‘A’ and ‘B’ remaining true?

Keep in mind that the price right now is +33% greater than it was that day on January 11th:

Now let’s take a look at the average transactions per block on January 8th, 2021:

Versus what we can see it dropped down to on January 11th, 2021:

From 2,889 TX/block to 1889 TX/block, representing an approximate -30% reduction in transactions per block (which could be one of the contributing factors here).

The Part That Makes Zero Sense

Curiously, despite all of the metrics that we parsed through above, we can see that the average transaction fee actually increased over this time span from January 7th to January 11th (from 11.639 to 13.89; +17% increase in the TX fees):

Nothing Depicted Above Adds Up at All

Taking all of the metrics depicted above in stride, there’s really no rhyme or reason for what we’re seeing above. Unless we’re able to find a demonstrable change in one of the underlying metrics for Bitcoin that we failed to previously take into account.

More Mining Facts

One thing that readers should keep in mind here is that miners are required to wait 100 blocks before they’re able to move ANY of their funds (roughly 3/4th of the day).

source: https://en.bitcoin.it/wiki/Confirmation

This dictates that miners must not only view their mining activities as an investment but as one juxtaposed with their future estimations of Bitcoin’s impending price action 600-ish minutes into the future (accounting for the 100-block height time spending limit).

Intermediate Conclusion

It feels dirty writing ‘conclusion’ on this somewhat confusing, kind of sloppily written piece (for the time being), but this is where I feel it is appropriate to stop.

At some point in the near future, I’m going to take the information contained within this piece and consolidate it alongside some common sense conclusions (specifically based on the data that we observed in the back half of this piece) for the purposes of making it clear that miners are not only colluding to increase the fees on-chain, but that this behavior is inherently obvious when considering the confluence of factors isolated above (i.e., X and Y cannot be true unless Z is also true).