Original author: B10C
Original compilation: GaryMa Wu Shuo Blockchain
Note: The original text comes with corresponding hyperlinks for each address and transaction, making it easier for readers to verify on-chain.
My project, miningpool-observer, aims to detect whether a Bitcoin mining pool censors transactions. Over the past few weeks, it detected six missing transactions spent from OFAC-sanctioned addresses. This post explores whether these transactions were deliberately filtered because they came from OFAC-sanctioned addresses, or if there are other possible explanations for why these transactions did not appear in the block. I concluded that four of the transactions were potentially filtered.
In September and October 2023, my miningpool-observer instances RSS feed reported missing OFAC sanctioned transactions in six blocks. One of the blocks was produced by the ViaBTC mining pool, another was produced by the Foundry USA mining pool, and four blocks were produced by F 2 Pool. An OFAC sanctioned transaction is a transaction from or to an address sanctioned by the U.S. Department of the Treasury’s Office of Foreign Assets Control (OFAC). I maintain a tool that extracts a list of OFAC sanctioned addresses from the Specially Designated Nationals (SDN) list published by OFAC.
There may be several reasons why a transaction does not appear in the block. Generally speaking, transactions are spread unevenly across the network and there is no global mempool to select transactions. Each node has its own set of valid transactions. Mining pools may also prioritize transactions paid through other methods. However, they may also downgrade or filter certain transactions.
The goal here is to determine whether the mining pool filtered these six OFAC sanctioned transactions, or if there are other possible explanations for these transactions not appearing in the block. Note that mining pools are free to choose which transactions to include and which to exclude. However, in order to analyze the censorship-resistant nature of Bitcoin, it is crucial to understand how many mining pools there are and how they filter transactions.
I concluded that the missing sanctioned transactions for ViaBTC and Foundry reported by miningpool-observer may be false positives and not the result of filtering. However, transactions missing from the F2Pool block are likely to have been filtered.
ViaBTC block height #808660 block
Block 808660 produced by ViaBTC on September 21, 2023 does not contain transaction 262025 e 7... This transaction combines 100 inputs into one output. One of the inputs spends an output paying the address 1ECeZBxCVJ8Wm2JSN3Cyc6rge2gnvD3W5K. The address was added to OFACs SDN list on September 21, 2021.
The size of the transaction is 14.7 kvB and the payment rate is 25.18 sat/vByte. The output spent from the sanctioned address was 0.0002 BTC (20k sat) and was created approximately 75 minutes before block 808660. When ViaBTC produced block 808660, the transaction had been in my nodes memory pool for about 75 minutes. It has no dependencies on other transactions in the mempool.
Block 808660 and template fee distribution
Checking the rate distribution for block 808660 on miningpool.observer, we find that ViaBTC takes up approximately 1 MWU of block space out of 4 MWU, including prioritized transactions. These transactions may come from the ViaBTC Bitcoin trading accelerator. Prioritizing some transactions means that transactions with lower rates, such as those spent from sanctioned addresses, cannot be included in the block. For this ViaBTC block, my miningpool-observer instance lists 24 large merged transactions that are not included in the block.
List of large merged transactions lost in block 808660
This leads to the conclusion that ViaBTC did not filter this transaction. It is replaced by other priority transactions. This is supported by the fact that three days later, ViaBTC blocked a transaction spending from the same sanctioned address in block 809181.
Block 813231 produced by Foundry USA
Block 813231 produced by Foundry USA on October 21, 2023 does not contain transaction c 9 b 57191... This transaction combines 150 inputs into one output. One of the inputs spent a payment to the output of address 3PKiHs4GY4rFg8dpppNVPXGPqMX6K2cBML7. The address was added to OFACs SDN list on April 14, 2023.
Since most of these 150 inputs are 2/3 multi-signature P 2 SH scripts, the missing transactions are very large, 43842 vByte. It pays a rate of 5.09 sat/vByte and does not rely on transactions in the mempool. This rate is enough to rank it 161st out of 2215 transactions in the template built by my Bitcoin Core node. However, as in the previous case, when I learned about Foundry USAs block 812331, 18 other transactions, including this transaction, had only existed in my mempool for about 30 seconds. This gives Foundry no chance to include the transaction in their block because they dont know about it yet.
Transaction propagation may take several seconds. Additionally, most mining pools only push new block templates to miners every 30 seconds and then take a while to switch to new work. Additionally, the miningpool-observer tool requests new block templates every few seconds and makes the best match based on the smallest difference between missing and extra transactions (see methodology in the FAQ). This makes false positives possible for young transactions, which can be as high as 60 seconds or so.
The mempool.space block explorer also tracks the differences between the block template broadcast by miners and the final block. They show c 9 b 57191.. included in their template but missing from the actual block. Transactions are marked by them as Recently Broadcast.
Foundry considers the missing transaction in block 813231 to be considered recently broadcast by mempool.space
This conclusion indicates that Foundry USA did not filter this transaction. The transaction was broadcast too late to be included in the block production effort that discovered block 813231. In addition, Foundry USA also produced the next block at height 813232, which included the sanctioned transaction.
Blocks 810727, 811791, 811920 and 813357 were produced by F 2 Pool
F 2 Pool produced block 810727 on October 5, 2023, identified as ..ccda 1498; block 811791 was produced on October 12, identified as ..af 445 3d 6 and block 811920, identified It is ..00 badf 62; and block 813357 was produced on October 22, identified as ..6 3ac 1669. Each block is missing a sanctioned transaction. Each of these transactions combines 150 2/3 multi-signature inputs into a single output. For each transaction, one of the inputs spends an output paying the address 3PKiHs4GY4rFg8dpppNVPXGPqMX6K2cBML. This is the same merge mode and address discussed in the previous section. All missing transactions do not depend on transactions in the mempool.
Block 810727
In block 810727, F 2 Pool does not contain transaction c 6 a 66836..9 , which spends a sanctioned output. With 150 2/3 multisig inputs, the transaction is quite large, taking up 44017 vBytes. It paid a fee of 446260 sats and had been in my node memory pool for nearly 4 hours when F 2 Pool produced block 810727. The F 2 Pool selection contains transactions 907 e 1 f 45..10 compared to c 6 a 66836... This transaction is also a merge transaction, with 150 inputs and one output, but does not spend the sanctioned output. It pays the same, 446260 sats, but is actually larger, with 3 more vBytes, to 44020 vByte. This means that the missing transaction c 6 a 66836.. has a slightly higher rate than 907 e 1 f 45.. From a strict ordering perspective of rates, missing transactions should be included. However, in practice, the 3 vByte of additional block space is unlikely to make a difference in overall cost.
Compare the missing sanctioned transactions in F 2 Pool block 810727 with the additional included transactions. Additional transactions are larger, adding 3 vBytes.
Block 811791
In F 2 Pool block 811791, transaction aa 001 ce 6..9 is missing. Similar to the previous merge transaction, the size of this transaction is 42459 vBytes (169836 WU). At a cost of 446260 sats, it paid a rate of 10.5 sat/vByte. When block 811791 reaches the mining pool observation node, the transaction has been in its memory pool for four minutes.
In this block, it is worth noting that five transactions containing OP_RETURN block commitments are missing. However, F 2 Pool inserts its own block commitments. This happens frequently and has been reported before. Additionally, F 2 Pool included two larger zero-fee transactions in its block. One of them merges the previous F 2 Pool coinbase output and the other is a payment transaction to the miner. This is a common block generation behavior of F 2 Pool.
Although these additional transactions take up more than 400 kWU of block space, it is still enough to contain the transaction aa 001 ce 6…. The block includes 2.86 MWU transactions at a lower rate than aa 001 ce 6.. (10.5 sat/vByte). This transaction of approximately 170 kWU should have been able to fit in this block. On mempool.space, this transaction was marked as removed, which negatively impacted its block health indicator.
In block 811791, the fee distribution of the transaction package containing the fee and weight of the missing transaction is included.
Block 811920
In block 811920, F 2 Pool does not contain the transaction 1 cb 3d 6 bc..9 , which spends a sanctioned output. This deal is also a larger merger. It has a size of 43630 vBytes (169836 WU) and pays a rate of 10.23 sat/vByte for 44660 sats. When block 811920 reaches the mining pool observation node, the transaction has existed in the nodes memory pool for nearly 2 minutes.
In block 811920, there were 1.44 MWU transactions paying rates lower than 10.23 sat/vByte. Transaction 1 cb 3d 6 bc.. 170 kWU should be able to fit in this block. Since the transaction only existed in my nodes memory pool for almost two minutes, its possible that it hadnt propagated to F 2 Pool by the time F 2 Pool built its block template. On mempool.space, the transaction is also marked as Recently Broadcast. Typically, mining pools work hard to ensure a good connection to the Bitcoin network. If the transaction is in the memory pool of mempool.space and miningpool.observer, there is a high probability that the transaction is already in the memory pool of F 2 Pool. This transaction already existed when F 2 Pool built its block template.
In block 811920, the fee distribution of the transaction package containing the fee and weight of the missing transaction is included.
Block 813357
In block 813357 of F 2 Pool, the transaction e 49 cdb 60..9, which spends a sanctioned output, is missing. The size of this merged transaction is 43053 vBytes (172209 WU). At a cost of 178504 sats, it paid a rate of 4.15 sat/vByte. When block 813357 reaches the mining pool observation node, the transaction has existed in the nodes memory pool for more than 25 minutes.
In block 813357, there were 684 kWU transactions paying less than 4.15 sat/vByte. Transaction e 49 cdb 60.. 172 kWU should be able to fit in this block. Since the transaction has existed in my nodes memory pool for more than 25 minutes, it is likely that the transaction has propagated to a node in the F 2 Pool. This transaction is also included in the mempool-space template for block 813357.
In block 813357, the rate distribution of transaction packages containing the rates and weights of missing transactions is included.
Summary of the F 2 Pool block
Judging from the missing sanctioned transaction in block 810727, its rate is slightly higher since it is 3 vByte smaller than the included transaction. However, in this case, these 3 vBytes of extra block space will have no impact on the total fees, and the Bitcoin Core block template algorithm will select transactions with higher fees. The additional large transaction included in block 811791 will have no impact on the sanctioned transaction in the missing block 811791. The transaction has most likely been filtered out of the block. The block audit on mempool.space matches this. It is possible that F 2 Pool has not yet learned about the missing sanctioned transaction in block 811920. However, for a large mining pool, 2 minutes is enough to receive a transaction. Especially since mempool.space and miningpool.observer already know about this transaction. The sanctioned transaction was not included in the F 2 Pool most likely because it was filtered out. Similar to the missing transaction in block 811791, the missing transaction in block 813357 is likely to be filtered out by F 2 Pool.
These four missing sanctioned transactions lead to the conclusion that F 2 Pool is currently filtering transactions. Since we only see missing transactions related to a single OFAC-sanctioned address, 3PKiHs4GY4rFg8dpppNVPXGPqMX6K2cBML, we cannot determine whether F 2 Pool is filtering just this single address, or all OFAC-sanctioned addresses.
Summarize
This article discusses six Bitcoin transactions with spends from OFAC-sanctioned addresses that were detected as missing from blocks by mining pool observation tools. The two transactions missing from the ViaBTC and Foundry USA mining pool blocks were false positives and were not filtered. The four OFAC-sanctioned transactions missing from the F 2 Pool block are likely to have been filtered. This raises the question of why F2 Pool, a mining pool that originated in Asia, was the first to filter transactions based on U.S. OFAC sanctions.
However, the Bitcoin network is still functioning normally. Filtering transactions by one mining pool does not affect the overall censorship resistance of the Bitcoin network. Further monitoring of pool transaction selection could help identify when more pools begin filtering transactions based on, for example, OFAC sanctions. It also allows miners who direct their computing power to these pools to make informed switching decisions if they disagree with the pools (unannounced) filtering policy.
