In the final Mempool article, we discussed the different types of relay policy filters, why they exist, and ultimately the incentives that determine how effective each class of filters are to prevent confirmation of transactions of different classes. In this article, we will examine the dynamics of a relay network if some nodes on the network are running different relay policies compared to other nodes.

If a node on the network runs a homogenous relay policy with Mempool, all transactions must propagate throughout the network, given that they pay the minimum salary that should not be ousted from the node’s memory during a large transaction backlog. This is changed if different nodes on the network are running heterogeneous policies.

The Bitcoin Relay Network works on a best effort basis using what is called a flood filling architecture. This means that when a transaction is received on one node, it is forwarded to all other nodes except for the node that received the transaction. This is a highly inefficient network architecture, but in the context of a distributed system, it provides a high degree of assurance that transactions will ultimately reach the intended destination, the miner.

Introducing filters in a node’s relay policy to theoretically limit relays of other valid transactions will introduce friction in the propagation of that transaction, reducing the reliability of the network’s ability to perform this function. In reality, things aren’t that simple.

The amount of friction prevents propagation

Let’s take a look at a simplified example of various network node configurations. The next graphics blue node represents it Intention Consensus propagates any class of valid transactions, and the red node is do not have Propagate these transactions. The set of miners is centrally shown as a simple expression of where the transaction user ultimately wants to ultimately engulf the transaction.

This is a model for networks where nodes that reject the propagation of these transactions are clearly minority. As you can clearly see, nodes on the network that accept them have a clear path to relay them to the miners. Two nodes attempting to limit transaction propagation across the network will not affect the final receipt by the miner node.

In this diagram, we see that almost half of the sample network has a filtering policy for this class of transactions. Nevertheless, only a portion of the network propagating these transactions is blocked from the path to the miner. The remaining nodes without filtering still have a clear path to the miners. This introduced some degree of friction in a subset of users, but allows other users to freely engage in the propagation of these transactions.

Even users affected by filtering nodes require only a single connection to the rest of the network node (or direct connection to the miner) that is not detached from the miner to remove that friction. If your actual relay network has a similar configuration to this example, then it is all you need to do is a single new connection to mitigate the problem.

In this scenario, only a small number of networks are actually propagating these transactions. The rest of the network is engaged in policy filtering to prevent propagation. However, even in this case, the unfiltered node still has a clear path to propagate to the miners.

Only this small, small, unfiltering nodes are needed to ensure final propagation to miners. Preferred peering logic, that is, functionality to ensure that nodes prefer peer or relay policies that implement the same software version. These types of solutions can ensure that peers who propagate something to others cannot find each other and maintain connections between themselves throughout the network.

Tolerant minority

As you can see these different examples, even in the face of the overwhelming majority of public networks engaged in filtering certain classes of transactions, what is needed to successfully propagate through the network to miners is the small number of networks that propagate and relay them.

These nodes essentially create “subnetworks” within the larger public relay network through technical mechanisms, ensuring that from users engaged in these types of transactions there is a viable path to minors who are willing to include them in the block.

There is essentially nothing you can do to counter this dynamically, except for carrying out a civil attack on all these nodes. Also, a cibil attack requires a single honest connection to be completely defeated. Similarly, honest nodes that create very large numbers of connections with other nodes on the network can increase the cost of such civil attacks to the de-capacity. The more connections you create, the more civil nodes you need to spin in order to consume all the connection slots.

What if there are no minorities?

So what happens if there are no tolerant minorities? In that case, what happens to transactions in this class?

If users still need to create them and pay the miner, they will be confirmed. Minor simply sets up the API. The role of miners is to confirm the trade, and the reason they do so is to maximize profits. Miners are not selfless, not moral or ideologically motivated, they are business. They exist to make money.

If there are users who are willing to pay for a particular type of transaction, and the entire public relay network refuses to propagate those transactions to miners to include them in the block, the miners create another way for users to submit those transactions to them.

It’s a reasonable move to make as a profit motivating actor when there are customers who want to pay you.

Relay policies are not a consensus alternative

At the end of the day, if the relay policy is consensus in effect, the relay policy cannot successfully censor the transaction if the user is willing to pay. Miners have no extended status such as the user’s willingness to pay (such as spending time checking damage or savings to nodes on the network, i.e. time on consumer PCs, etc.).

If some classes of transactions are deemed truly undesirable by Bitcoin users and node operators, there is no solution to stop them from being seen on blockchains approaching enacting and disabling consensus changes.

If filtering policies implemented in relay networks can prevent transactions from being seen, then Bitcoin will not be able to withstand censorship.

Although the price has hovered optimistically close to the critical $100,000 barrier, stagnant blockchain activity metrics show certain vulnerabilities that could hinder further upside.

According to data from Checkonchain, daily on-chain transfer volume remains near the $10 billion mark, aligning almost perfectly with its 365-day mean. This is a clear indication that transactional demand remains tepid.

Sharp increases in on-chain throughput marked previous bullish phases, but the current scenario reflects minimal fresh transactional activity, effectively capping potential momentum.

Furthermore, Bitcoin’s mempool (the main indicator of transaction backlog and network demand) has been shallow, sustaining only about three to four blocks’ worth of pending transactions. This contrasts starkly with historical breakout periods, where the mempool swelled significantly amid heightened transactional urgency.

Active address metrics corroborate the lethargy seen in on-chain volume and transaction counts. In the past 30 days, daily active addresses averaged around 930,000, with recent fluctuations marking multi-month lows dipping occasionally below 800,000, a departure from the activity typically associated with bullish enthusiasm.

Without an uptick in new or returning user interactions, Bitcoin is increasingly dependent on existing holders to drive the market upward. This dependency often translates into weaker buying pressure, particularly at significant resistance levels where profit-taking from stale holders may dominate.

Bitcoin’s velocity, which shows the rate at which coins change hands, seems to compound these pressures. Data from CryptoQuant shows velocity remains stagnant around 13.0, showing that coins are moving through the Bitcoin ecosystem more slowly.

Moreover, the investor sentiment backdrop provides limited comfort. Although roughly 400,000 BTC recently transitioned into long-term holder (LTH) status in the past month, suggesting a tightening supply, this shift is double-edged. Historically, significant movements into LTH status coincide with phases of market inertia rather than explosive growth as investors brace for prolonged sideways movements.

Additionally, Bitcoin’s short-term holder (STH) cost-basis of $93,500 almost perfectly mirrors the current spot price, adding further technical and psychological weight. This price alignment amplifies the risk of forming a technical lower-high scenario on the weekly charts, particularly if bid support fails to materialize decisively in the next few weeks.

Exchange inflow data offers additional cautionary signals, averaging approximately 32,700 BTC daily over the last month. These numbers represent neither panic selling nor aggressive accumulation: they reflect a neutral and disinterested market.

This middle-ground sentiment most likely won’t provide sufficient fuel to propel Bitcoin past resistance clusters near $100,000, where approximately 15% of Bitcoin’s circulating supply currently resides in unrealized losses, ready to offload at break-even points.

Previous episodes of muted activity have typically led to market frustration, culminating in sudden downside corrections or extended periods of price stasis, both of which are demoralizing for bullish investors hoping for rapid ascents.

Bitcoin will likely escape this inertia when transfer volume, ETF turnover, and active addresses spike in tandem. Increased velocity and mempool depth, followed by increased movement in the derivatives market, would certainly bolster confidence.

Derivatives themselves have seen sharp spikes and drops in activity in the past month, indicating volatile speculative fervor, but weren’t enough to keep BTC above $95,000. But without all these signals materializing together, the likelihood increases that Bitcoin might succumb to a lower-high formation on the weekly chart that could push it back to as low as $86,000.

The current state of transactional inertia acts as a barrier to Bitcoin’s immediate upside potential. Unless significant on-chain activity resumes, the market’s aspirations of surpassing and sustaining Bitcoin’s price above $100,000 may remain out of reach in the short term.

The post Quiet mempool and flat volume could mean limited fuel for Bitcoin’s breakout above $100k appeared first on CryptoSlate.

You are trying to capture all exchanged transactions. Bitcon Core has been adhered to trace Enable and listen mempool:replaced As suggested in this question.

This method works as expected and can retrieve exchanged transactions. However, in some cases (about 20% of all transactions I capture), TracePoint warns that the transaction is being exchanged, but it’s not capturing the exchange of that transaction.

We can consider two reasons why this is happening:

1. It’s possible that some of the alternatives won’t be included in my members. But in that case, how does TracePoint know that transactions are being exchanged? It’s also strange that this happens in so many transactions (20% as mentioned above).
2. The second option is that the script that handles the transaction does not take into account some cases. This means losing the transaction. The script is a modified version of this example. I changed it so that the children of exchanged transactions can also be captured. The data collected with this script will be saved later in a PKL file, so there is a sharing list.

I’m not sure why I’m losing so many deals, so I was wondering if anyone could help me see what I’m doing wrong.

Here is the modified function:

       def handle_replaced(_, data, size):
          # Establish a new RPC connection for this event
          rpc_connection_replaced = connection()
          event = bpf("replaced_events").event(data)
          hash_replaced = bytes(event.replaced_hash)(::-1).hex()
          hash_new = bytes(event.replacement_hash)(::-1).hex()
          tx_time = get_timestamp()
          
          hex_tx = rpc_connection_replaced.getrawtransaction(hash_new)
          new_tx = rpc_connection_replaced.decoderawtransaction(hex_tx)
          new_tx('hex') = hex_tx
          # Determine parent transactions that are still in the mempool and are not the transaction itself
          parents = set((x('txid') for x in new_tx('vin') if x('txid') in mempool.keys() and x('txid') != new_tx('txid')))
          # Retrieve the old transaction info from the mempool 
          old = mempool.get(hash_replaced, None)
          if old is not None:  # Some transactions may be missing initially
            mempool.pop(hash_replaced, None)
            # Share the replaced event details via list_shared queue
            list_shared.put((old, (new_tx, tx_time, parents)))
            # Find all child transactions that reference the new transaction as a parent
            childs = (i(0)('txid') for i in mempool.values() if new_tx('txid') in i(2))
            
            # Recursive function to collect child transaction IDs
            def child(ll):
              if len(ll) == 0:
                return ()
              new_childs = (i(0)('txid') for i in mempool.values() if ll - i(2) != ll)
              return list(ll) + new_childs + child(set(new_childs))
            
            if len(childs) > 0:
              childs = child(set(childs))
              # Share the connection between the new transaction and the first child
              list_shared.put(((new_tx, tx_time, parents), mempool(childs(0))))
              # Share connections between subsequent child transactions
              for i in range(len(childs)-1):
                list_shared.put((mempool(childs(i)), mempool(childs(i+1))))

          # Add the new transaction to the mempool with its timestamp and parent set
          mempool(new_tx('txid')) = (new_tx, tx_time, parents)
          logger.info('-----------')
          logger.info('New RBF!')        
          
      def handle_added(_, data, size):
          rpc_connection_added = connection()
          event = bpf("added_events").event(data)
          hash_new = bytes(event.hash)(::-1).hex()
          hex_tx = rpc_connection_added.getrawtransaction(hash_new)
          tx_raw = rpc_connection_added.decoderawtransaction(hex_tx)
          tx_raw('hex') = hex_tx
          parents = set((x('txid') for x in tx_raw('vin') if x('txid') in mempool.keys()))
          mempool(tx_raw('txid')) = (tx_raw, get_timestamp(), parents)
          
      def handle_removed(_, data, size):
        event = bpf("removed_events").event(data)
        if event.reason != b'replaced':
            txid_rem = bytes(event.hash)(::-1).hex()
                    
            keys = mempool.keys()
            if txid_rem in keys:
              mempool.pop(txid_rem) 
              logger.info('-----------')
              logger.info(f'Removed. Reason:{event.reason}')