BTC congestion manager

The bitcoin tx queue is messy and too many people are jumping the line, congesting whoever is behind. Let’s organize that mess. No randomly jumping in front of the line no more! Rather squeeze in and dance with the queue.

philosophy

• Do not overpay in fees
• Proactively manage the tx queue

We aim to organize the queue by spoting non-uniformity on the mempool fee distribution and suggest fees for new txs that would fill that gap. Over time that produces a somewhat uniform fee distribution and a much more predictable fee market where different parties could trully prioritize transactions.

Lets assume a stationary mempool. Lets take all txs and sort by fee and sum up their sizes up to when it reaches block 1 (1 MB) and then continue up to block n (n MB). We have the queue from the perspective of a miner. In the ideal scenario if we take the difference in fees paid by transaction tx_2 (2nd in the queue) and tx_1 (1st in the queue), and the difference between tx_3 and tx_2 that should be the same, and could be as low as the lowest unit, 1 satoshi. Just enough to represent priority.

Now let’s stop assuming the mempool is stationary and take it as a dynamic system. We introduce velocities where old txs are pushed back by the introduction of new txs in front of it.

So now the problem becomes, what fee do I pay for my transaction such that it will be mined on the block say 2. The mempool is growing in front of the 2nd megabyte, and old txs are pushed back. You should place ur tx much in front of where you want it to end up in.

Very often the fee market is very shallow. The next 2 blocks might be packed with txs paying 600 sat/B, but then the 3rd block has txs paying 200 sat/B. We try to find in real time where these fee gaps are and suggest them as fees so that they fill the gaps.

As a beneficial side effect, it becomes much easier to predict fees in the future.

requirements

• bitcoind full node with zmq push notifications enabled for blockhash
• nodejs
• crossbar
• redis

diagram

• data from [2018-01-01 16:48:56]

       0 sat/B  -143 sat/B  -159 sat/B   -18 sat/B
         |-----------|-----------|-----------|
         |           |           |           |
     371 sat/B   228 sat/B    68 sat/B   50 sat/B
         |           |           |           |
         v           v           v           v
 |---------|-----------|-----------|-----------|
0MB       1MB         2MB         3MB         4MB
   block1      block2      block3      block4

methods

• we rewrite x = x_0 + vt into x_0 = x - vt (eq1), where x_0 is the initial position in B, x is the finalPosition B, v is velocity in B/10 min and t is time in 10 min
• all txs are sorted according to weight of the whole branch involving all its decendents
• we calculate how many transactions are added ahead of a target block to estimate average velocity (estimate comes from the past 1 hour – set that in config.ts)
• we assume probability of finding a new block at any time is constant (Poison).
• we use the sorted list of txs to determine x. knowing x and vt we can calculate x_0 (using eq1) – x_0 is a position in B
• we look up the feeRate paid by that tx closest to where x_0 falls and use that feeRate + 0.01 (avoid spurious minimum)
• best deal calculation using the derivative of feeRates over waiting times, and suggesting rate with big savings