Bitcoin Topological Analysis Pt. 1: Relationship Between RBF Signaling and Fast Growing Double Spend Attempts

Peter Todd Oct 24, 2020

Interested in similar content to this? Join our Telegram or follow us on Twitter! (you don't have to, but that'd be cool if you did)
Don't miss us on the forums either!...or through our Git instance!

Its about time we performed another Bitcoin protocol deep dive to explore the enigmatic (and 100% unimpeded) actions of Blockstream employees Core developers as they 'race to the bottom' of piling on unnecessary peripheral (or wholly unrelated) edge-case tweaks that can only be considered positive if they go unnoticed because the few that don't are most likely gaining attention for a lot of the wrong reasons.

Important Note!: I covered this topic in excruciating detail almost an entire year to date as I write this now (Oct 2020 now; Oct. 2019 is when this was first disseminated). Few paid attention then and I can't blame them...this seems like one of those super dense, 'I-don't-really-need-to-read-this' pieces and I'm willing to admit ... this may still fall under that category for now. But given the fact this piece, in specific, shows exactly how the piss poor decision making by Core (with zero accountability), makes these folks potentially dangerous criminals

RBF Signaling

The first network topology metric that we’re going to look at for Bitcoin is ‘RBF Signaling’.

What is RBF Signaling?

This concept is in direct reference to BIP125 (Bitcoin Improvement Proposal), authored by Bitcoin developers, David Harding and Peter Todd:

As stated above, BIP125 allows individuals using the Bitcoin protocol to indicate in the transaction data whether they would like to allow for it to be replaceable should they change their mind about the fee attached to it or some other mutable parameter before it is actually confirmed on-chain.

The easiest way for users to toggle the RBF feature on/off is via the Electrum wallet:

‘RBF Signaling’, in this analysis, refers to the concentration of UTXOs that have been sent with this explicit signaling.

In analyzing this metric in the next section, we’re going to be using this website for reference (write this down if you want to refer back to the resource for your own investigations/research in the future):

Curiously, it appears that the number of transactions fluctuates significantly and without warning or reason:

The above chart shows us the percentage of TXs that signaling RBF capabilities dating back to early July 2019.

The 144-block average used is the rough equivalent to a daily average (assuming a 10-minute block targeting interval; 10x144 = 1440 minutes / 24 hours).

As noted before, there are extreme fluctuations in the percentages of TXs with RBF signaling on them.

On September 25th, 2019, for instance >8.4%+ of transactions had RBF signaling:

This stands in stark contrast to September 4th, 2019, when only >4%+ of transactions sent, on average, had RBF signaling:

What’s more remarkable is that the RBF signaling percentages for TXs have even more variability in value when tracked using a 12-block moving average (2-hour equivalent).

Below, we can see a spike of nearly 14% of transactions RBF signaling on September 24th:

Which is then followed by an abrupt drop to 5%, just a few later:

What’s the Cause of the Fluctuation?

We can’t think of any plausible theories/answers for why there is so much fluctuation in thge number and percentage of transactions that are RBF signaling at various points in time on the Bitcoin protocol.

A few possibilities are as follows:

  1. There is actually no variability in the raw number of transactions being sent with RBF signaling, but rather the variability is in those that are not being sent with such variability. This would create the same fluctuations in % rate of RBF transactions like what we see above. This is fairly implausible though, all things considered.
  2. There is a singular entity or connected group of entities that typically send their transactions using RBF signaling by default that also happen to be responsible for a substantial number of TXs being sent on the protocol. If this were the case, then that would also explain it.
  3. When there is more activity on the blockchain, the fees begin to rise (this is an accepted and agreed-upon characteristic of Bitcoin right now). Thus, it is possible that, as fees are increasing on the Bitcoin protocol, so are the number of RBF transactions due to the increasing uncertainty that transactions may be confirmed in a certain period of time. It is very possible that this is the cause and we can at least probe the blockchain a bit more to see if there truly is a correlation of some sort.

Testing Out Our Third Theory Concerning Fluctuations in RBF Transaction Percentages

As noted in out third theory in the list above (prior section), it is entirely possible that increasing fees are the cause of RBF transaction percentage variability.

Fortunately, the same source that we were using to analyze the RBF transaction percentage metric for Bitcoin also has charted information on the changing average fees for Bitcoin (over the same time periods as well).

Let’s start with the 12-block MA RBF Signaling % chart again (we’re going to juxtapose this metric with the average fee [same MA/same time period] for a smoother visual analysis).

RBF Signaling Percentage [12-block MA]

As we can see above, on September 26th, 2019 at approximately 5:52 GMT (17:52 military time), the percentage of RBF transactions on the network was approximately 10.5724%.

Bitcoin Avg. Fee/Tx [12-Block MA]

As we can see above, at exactly the same time (September 26th, 2019; 17:52 GMT), the average fee (satoshis) was on the rise for all percentiles (10th/25th/50th/75th/90th).

Drawing a similar comparative analysis with the remaining values (and also running linear regression equivalents on the equivalent; not shown here for space conservation reasons), shows that there indeed is a correlation between the RBF signaling on Bitcoin and the average fee during a given period of time.

Why Would There Be a Correlation Between the Number of RBF Transactions and the Average Transaction Fee on the Network?

The answer can be found directly in the text of BIP125. Specifically, at the end, where Peter Todd’s contributions can be seen:

In following the link, boxed above, we end up here:

Incremental Send Many (Peter Todd's Mess)

Among the tools created by Peter Todd in conjunction with BIP125 was a feature called, ‘Incremental Send Many’.

As shown above, the description of this tool is as follows:

Finds an unconfirmed transaction in your 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 can be significantly cheaper than respending unconfirmed outputs in long transaction chains.
Depends on the availability of the fundrawtransaction RPC call, which is currently only available in git master. (will be in Bitcoin Core v0.12.0)
Opt-In Full-RBF pull-req:

The documentation for the ‘Opt-In Full-RBF pull-req’ is linked above and also can be found here:

Peter Todd’s Explanation Below (excerpted from the n-Sequence based Full-RBF discussion):

Notably, after a very brief discussion, the “concept ACK” responses by other developers signaled that it was tentatively accepted:

[Note: This is how decisions are made via Bitcoin Core. No room for the community to comment/contribute/give feedback on any facet of the process and certainly no consideration of anyone other than the primary developers (Blockstream-employed) when it comes to leveling said measures.]

Consequence of n-Sequence-based-Full-RBF-Opt-in

While rarely discussed in the Bitcoin community, there were tremendous consequences that stemmed from n-Sequence based (Full) RBF Opt-in as Peter Todd proposed.

Below is an excerpt of a conversation between Peter Todd and another Bitcoin developer [Suhas Daftuar] where the piece of code analyzed shows that Todd’s proposal would require the RBF transactions, if replaced, be replaced with a TX of a greater fee:

More can be found through a remedial quick peruse

As noted in the conversation, excerpted above, Peter Todd’s proposal would have the inevitable impact of creating a ‘race condition’-esque situation where, as senders of RBF signaled TXs that have opted into Peter Todd’s n-Sequence based tool are automatically replacing/swapping transaction fees, the activity of doing so is increasing the average transaction fee on the network (as perceived by nodes and other monitoring solutions that wallets employ).

Thus, as the average fee rises on the network, users will more than likely send their transactions in accordance with said fees (as expected), in order to ensure that their transaction is confirmed ASAP.

However, as users are doing so, the average fee will inevitably rise along with it, creating a feedback loop where inevitably more TXs must be replaced with an increased fee rate attached to them.

Bitcoin Fees Explained

You may have noticed in the conversation posted above between Peter Todd and other Bitcoin Core developers that the acronym, ‘CPFP’ crept its way into the chat several times when discussing the n-Sequence based RBF opt-in proposal.

Specifically, CPFP is an acronym that stands for ‘Child-Pays-For-Parent’. However, before we can dissect this concept, we must first gain a better understanding of how fees work on the Bitcoin protocol.

A good resource for those that are also looking to conduct their own independent study on the side regarding Bitcoin fees is the Bitcoin wiki, specifically:

Without coincidence, this is also where we’re going to start in our dissection of the Bitcoin fee model.

It is important that we cover Bitcoin’s fee model because there are certain misconceptions that are still prevalent in the community to this day, despite the fact that this process and the mechanisms behind it have been fairly well-documented for a few years at this point.

Bitcoin Fee Fact #1: Fees Are Not a Literal Addition

As aptly noted by the Bitcoin fee breakdown by the ‘Bitcoin Wiki’, fees are not literal add-ons on the Bitcoin network. In other words, there isn’t actually a reserved spot in each Bitcoin transaction that specifies the total fee.

Below is a picture showing the inputs that one can expect in a ‘typical’ Bitcoin transaction:

Question: So how is the fee calculated then?

Great question. As stated by the ‘Bitcoin Wiki’:

Every Bitcoin transaction spends zero or more bitcoins to zero or more recipients. The difference between the amount being spent and the amount being received is the transaction fee (which must be zero or more).
Bitcoin’s design makes it easy and efficient for the spender to specify how much fee to pay, whereas it would be harder and less efficient for the recipient to specify the fee, so by custom the spender is almost always solely responsible for paying all necessary Bitcoin transaction fees.
When a miner creates a block proposal, the miner is entitled to specify where all the fees paid by the transactions in that block proposal should be sent. If the proposal results in a valid block that becomes a part of the best block chain, the fee income will be sent to the specified recipient. If a valid block does not collect all available fees, the amount not collected are permanently destroyed; this has happened on more than 1,000 occasions from 2011 to 2017,[1][2] with decreasing frequency over time.

‘Effective Market for Fee Space’

One thing to keep in mind as we go forward is that there is competition for ‘block space’ and that fees are directly correlated to block space.

There are many entities/individuals in the blockchain space that may attempt to argue differently, for whatever agenda-based reasons they have — but the explicit reality of the situation is that the finite amount of block space available (maximum of 1MB/block; 1 block targeted every 10 minutes | each TX is an avg. of roughly 250 bytes/each ) means that the fee rate for Bitcoin is a product of:

  1. Available space
  2. Number of pending transactions
  3. Estimated wait time
  4. Time of day (going by the United States; West Coast & East Coast — at their sleeping areas, the on-chain activity decreases tremendously)
  5. Perceived importance of having a transaction confirmed ASAP
  6. Desire by Bitcoin’s users (sending TXs) to have their transaction confirmed within a block
  7. Average size of the transactions being sent
  8. Price of Bitcoin because the fee is only tabulated in sats and thus not ‘aware’ or ‘sensitive’ to the USD price. Thus, Bitcoin’s fee being perceived as ‘high’ or ‘low’ at any given period of time is not just contingent on what the network’s fee is, but also the actual price of Bitcoin at that given moment in time as well.

Each element above plays a critical role in determining what the calculated average fee necessary to get a transaction confirmed on the protocol will be.

However, since there are so many variables (seven that we listed above), and various factors that can influence each one, increasing or decreasing fees on the network can never be evaluated from a strictly two-dimensional perspective (i.e., “if we simply raise the fees/adopt Lightning Network, then we’ll ensure that there are lower fees!”).

Observers of Bitcoin must also be careful to not create a false equivalency between increased throughput and lowered fees.

It is entirely possible for Bitcoin’s throughput to increase while fees simultaneously increase at an even higher rate.

The excerpts below from the Bitcoin Wiki do a solid job of characterizing the ‘effective market for fee rate’ on the Bitcoin protocol:

Excerpt on Transaction Sorting (CPFP)

The information below from the Bitcoin Wiki summarizes this feature perfectly:

“Bitcoin transactions can depend on the inclusion of other transactions in the same block, which complicates the feerate-based transaction selection described above. This section describes the rules of that dependency system, how miners can maximize revenue while managing those dependencies, and how bitcoin spenders can use the dependency system to effectively increase the feerate of unconfirmed transactions.
Each transaction in a block has a sequential order, one transaction after another. Each block in the block chain also has a sequential order, one block after another. This means that there’s a single sequential order to every transaction in the best block chain.
One of Bitcoin’s consensus rules is that the transaction where you receive bitcoins must appear earlier in this sequence than the transaction where you spend those bitcoins. For example, if Alice pays Bob in transaction A and Bob uses those same bitcoins to pay Charlie in transaction B, transaction A must appear earlier in the sequence of transactions than transaction B. Often this is easy to accomplish because transaction A appears in an earlier block than transaction B:
But if transaction A and B both appear in the same block, the rule still applies: transaction A must appear earlier in the block than transaction B.
This complicates the task of maximizing fee revenue for miners. Normally, miners would prefer to simply sort transactions by feerate as described in the feerate section above. But if both transaction A and B are unconfirmed, the miner cannot include B earlier in the block than A even if B pays a higher feerate. This can make sorting by feerate alone less profitable than expected, so a more complex algorithm is needed. Happily, it’s only slightly more complex.
For example, consider the following four transactions that are similar to those analyzed in the preceding feerate section:
To maximize revenue, miners need a way to compare groups of related transactions to each other as well as to individual transactions that have no unconfirmed dependencies. To do that, every transaction available for inclusion in the next block has its feerate calculated for it and all of its unconfirmed ancestors. In the example, this means that transaction B is now considered as a combination of transaction B plus transaction A:
Note that this means that unconfirmed ancestor transactions will be considered twice or more, as in the case of transaction A in our example which is considered once as part of the transaction B+A group and once on its own. We’ll deal with this complication in a moment.
These transaction groups are then sorted in feerate order as described in the previous feerate section:
Any individual transaction that appears twice or more in the sorted list has its redundant copies removed. In the example case, we remove the standalone version of transaction A since it’s already part of the transaction B+A group:
Finally, we see if we can squeeze in some smaller transactions into the end of the block to avoid wasting space as described in the previous feerate section. In this case, we can’t, so no changes are made.
Except for some edge cases that are rare and rarely have a significant impact on revenue, this simple and efficient transaction sorting algorithm maximizes miner feerate revenue after factoring in transaction dependencies.
Note: to ensure the algorithm runs quickly, implementations such as Bitcoin Core limit the maximum number of related transactions that will be collected together for consideration as one group. As of Bitcoin Core 0.15.0 (released late 2017), this is a maximum of 25 transactions, although there have been proposals to increase this amount somewhat.
For spenders, miner use of transaction grouping means that if you’re waiting for an unconfirmed transaction that pays too low a feerate (e.g. transaction A), you can create a child transaction spending an output of that transaction and which pays a much higher feerate (e.g. transaction B) to encourage miners to confirm both transactions in the same block. Wallets that explicitly support this feature often call it child pays for parent (CPFP) because the child transaction B helps pay for the parent transaction A.
To calculate the feerate for a transaction group, sum the fees paid by all the the group’s unconfirmed transactions and divide that by the sum of the sizes for all those same transactions (in weight units or vbytes). For example, if transaction A has a fee of 1,000 nanobitcoins and a size of 250 vbytes and transaction B has a fee of 3,000 nanobitcoins and a size of 150 vbytes, the combined feerate is (1,000 + 3,000)/(250 + 150), which is 10 nanobitcoins per vbyte.
The idea behind ancestor feerate grouping goes back to at least 2013 and saw several different proposals to add it to Bitcoin Core, with it finally becoming available for production with the August 2016 release of Bitcoin Core 0.13.0.”

We’ll go ahead and end this write-up here because there’s a lot more information to get into from this point.

But keep this in mind because we’re going to have some fun really looking under the hood at Bitcoin in the very near future.



Happy to serve and help wherever I'm needed in the blockchain space. #Education #EthicalContent #BringingLibretotheForefront

Great! You've successfully subscribed.
Great! Next, complete checkout for full access.
Welcome back! You've successfully signed in.
Success! Your account is fully activated, you now have access to all content.