A Brief History of the Mempool Chaining Limit
*(An excerpt from an article originally* *published on the BU blog**)* https://www.bitcoinunlimited.info/blog/6a710fed-21d3-499a-97a5-e1a419bc0a6f
Examining the history behind the mempool chaining limit is instructive. When Satoshi first released the bitcoin client, there was no such limit. In a certain sense, there was no mempool either [1] — miners simply collected valid transactions and confirmed them in the next block. And nothing broke. For years. In fact, it wasn’t until blocks became congested, in the summer of 2015, that the “mempool” really became a distinct concept unto itself [2]. The Core devs decided at that time that it needed new rules to ensure that it was more carefully managed [3].
The problem was that if transactions were admitted into the node faster than they were being written out to blocks, then a queue of unconfirmed transactions would form. This queue is what we call the mempool. It takes up space in RAM, and since a computer only has so much RAM, the queue could only grow so long before the computer would catch on fire and cats and dogs would become friends (ok the part about the fire was a stretch but some bitcoin nodes crashed and had to be rebooted that summer).
The obvious solution was to increase the block size limit to allow mempool to clear each block, like it had for the previous 6 years. But who wants a simple solution when a complex one will do? Certainly not the Core developers.
And besides, the Core devs of the time subscribed to the Maxwellian theory of block space economics. The fundamental premise of the theory was that the natural state of a block is full. The Maxwellians believe that if the block size limit were maintained above demand, then blocks would soon grow to infinite sizes clogging the Internet and consuming every bit of flash memory on Earth (this might be a slight exaggeration). It takes a group of very smart people to act this dumb. But if you accepted the Maxwellian premise, then the change in direction that bitcoin development took might have appeared rational.
The Core devs carefully considered what to do about the mempool problem [4]. They rejected simple solutions like ejecting transactions at random when low on RAM, as proposed by Mike Hearn [5]. The mempool couldn’t be just a simple queue where transactions waited their turn. The Core devs demanded an *optimal solution* to the problem they had invented.
They wanted new transactions to be able to cut in line by paying a higher fee, such that the queue was always sorted by fee rate. If the queue got too long, then the lowest-fee-rate transactions would be dropped. Miners would build blocks by selecting the set of transactions that paid the highest total fees while consuming no more than 1 MB of block space. By the power of Central Planning, the Maxwellian Fee Market was born.
(Aside: You can begin to see how something that barely even existed was transformed by the Core devs into a complex mempool management machine that Satoshi had never intended. The irony is that all of this complexity goes away if the block size limit is maintained above the size of blocks demanded by users. It’s replaced by the natural fact that a miner will increase his profit by including any transaction that pays more than some minimum fee rate (that depends on block propagation and other factors) [6]. Personally, I think we should leave miners alone to build blocks how they please.)
Where were we. Oh yes….complexity bred further complexity. The Core devs’ solution to overflowing mempools (the Maxwellian Fee Market) caused additional problems that needed their own clever solutions. For example, a bitcoin user might submit a transaction with a fee rate of 2 sat/byte, that would normally be confirmed quickly, but because of a spike in demand his transaction might be pushed to the back of the queue over and over, never confirming. This was a real problem that many bitcoin users were complaining about [7].
There were two solutions proposed. The first was called “replace-by-fee” (RBF) and it allowed the sender to replace the stuck transaction with a higher paying version (which caused further problems in BTC because this higher paying version could be made payable to someone other than the original payee (are you seeing a pattern yet?)). Thankfully, RBF was purged from all implementations of BCH.
The second solution was called “child-pays-for-parent” (CPFP). Child-pays-for-parent allowed the effective fee rate of the stuck transaction to be bumped so that it (the parent transaction) would be treated together with its child as a “family.” The family would be placed within the queue based on the family’s average fee rate. The recipient of a stuck transaction could bump it by spending the unconfirmed transaction again back to himself with a high fee. Or the sender of the stuck transaction could bump it by spending the change output (assuming there was one) back to himself with a high fee.
Clever, right? Now the “mempool manager” not only needed to sort incoming transactions by fee rate and stick them into the correct location in the queue and eject low fee transactions before running out of RAM, but it also needed to check to see if any of these new transactions were respending a transaction that was already waiting in the queue. That is, it had to check if a child of one of the parents waiting in line had arrived, and if so, it had to relocate both the child and parent together as a family within the queue.
But Bitcoin transactions breed much faster than humans, and next thing the Core devs knew the kids were having kids that were having kids, there’s some weird cross-breeding action going on in the corner, and that funny-looking guy waiting in the movie theatre line 50 feet back is his own grandfather [8]. Of course, what I’m describing here are long chains of unconfirmed transactions and the relations between them can be as confusing as that between your third-cousin twice removed and the mother of your grandfather’s daughter. The point I’m trying to communicate is that as these chains become longer, it becomes more difficult for the “mempool manager” running its CPFP algorithm to figure out where each family belongs in the queue. And so the Core devs just added a stop-gap rule forbidding parents from watching the show with more than 25 of their descendants. Not only were additional relatives forbidden from the theatre regardless of the amount they were willing to pay, they weren’t even allowed to wait at the end of the line outside in the rain.
This brings us to where we are today. The 25-descendent limit and the CPFP code that ABC inherited from Core is now causing problems for Satoshi Dice, Badger Wallet, Memo and others. To summarize, the current problem was caused by a solution (CPFP) to a different problem (stuck transactions), which in turn was caused by another solution (the Maxwellian Fee Market) to a third problem (overflowing mempools) that would never have been a problem in the first place had the block size limit been maintained above demand.
Notes
[1] To all the pedants out there, yeah yeah yeah strictly speaking there was still a mempool, but it as its own cog in the system hadn’t yet entered the gestalt of bitcoin. The mempool concept was not well defined from the collection of transactions a node was trying to confirm.
[2] See [1]
[3] Early discussion of the mempool overflowing problem:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-October/011368.html
[4] There were several proposals for addressing the mempool problem, for example:
https://github.com/bitcoin/bitcoin/pull/6557
https://github.com/bitcoin/bitcoin/pull/6673
https://github.com/bitcoin/bitcoin/pull/6722
[5] Mike Hearn on why ejecting transactions at random is better than sorting by fee rate:
https://medium.com/@octskyward/mempool-size-limiting-a3f604b72a4a
[6] I wrote a paper and gave a talk on the topic of how miners actually lose money confirming transactions with too small of fees:
https://www.bitcoinunlimited.info/resources/feemarket.pdf
https://www.youtube.com/watch?v=ad0Pjj_ms2k
[7] One of the many discussions on stuck transactions:
https://www.reddit.com/r/Bitcoin/comments/4o9tb1/mempool_megathread/
[8] “I’m my own Grandpa”:
https://en.wikipedia.org/wiki/I%27m_My_Own_Grandpa
Exploring Long Chains of Unconfirmed Transactions and Their Resistance to Double-spend Fraud
1 Introduction
This article explores long chains of unconfirmed bitcoin transactions and investigates their resistance to double-spend fraud. First we show how to hit the 25-chained transaction limit using the Electron Cash wallet, and then we discuss why the limit hurts certain use cases. Thanks to BU's recent work improving the child-pays-for-parent algorithm, hundreds of nodes on the network today now support long mempool chains. We then connect an Electron Cash wallet to one of these nodes hosting an Electrum server, and attempt a double-spend attack against a simulated merchant, showcasing how BU's "intelligent forwarding" protects the merchant against double-spend fraud. We then explore other potential double-spend vulnerabilities before concluding that accepting deeply-chained unconfirmed transactions today using a default BU node is not significantly more risky than accepting lightly-chained unconfirmed transactions. Unfortunately, during our testing we discovered an attack that succeeds with a very high probability against *all chained transactions* that can be carried out with an off-the-shelf bitcoin wallet unless the merchant (or his payment provider) follows a fairly onerous procedure to protect himself.
In this article series, the term “bitcoin” refers to a system with the properties described by its inventor Satoshi Nakamoto in the white paper “Bitcoin: A Peer-to-Peer Electronic Cash System.” We assume the reader has a technical understanding of bitcoin at the level of this paper. In particular, we assume he is familiar with the concepts of unconfirmed transactions, double-spends, and the structure of bitcoin transactions (i.e., transactions spend inputs and mint new outputs—there are no “accounts” that get debited or credited at the protocol level). We also assume the reader is familiar with the concept of the "mempool": the set of (unconfirmed) transactions that have been broadcast to the network but not yet confirmed in the blockchain. https://www.bitcoin.com/bitcoin.pdf
2 What is the mempool chaining limit?
The reader can experience the mempool chaining limit for himself by downloading the Electron Cash SPV wallet (it takes only a minute or two to get a wallet up and running). Starting with a new empty wallet, open the receive tab and send $1’s worth of BCH from your usual wallet to its receiving address (or some other small amount). After the payment is received, open the “Send” tab and paste the same receiving address into the “Pay to” field, then press the “Max” button to populate the “Amount” field, and finally, press the “Send” button. Your wallet will create and broadcast a transaction that sends the unconfirmed output back into your wallet, after subtracting a small miners’ fee. https://electroncash.org
In the “History” tab, you should see the original unconfirmed transaction and a second transaction marked “Unconfirmed parent.” The “Amount” for the second transaction is negative because the net result was that your balance decreased due to the miner’s fee required to send the transaction (185 satoshis in this case). The second transaction spent the output of the original transaction that deposited $1 into your Electron Cash wallet, thereby creating an “unconfirmed chain” of length 2. If for some reason the parent transaction does not confirm (perhaps it was double-spent), then it would become impossible for the second transaction to confirm because the output consumed by the second transaction would no longer exist.
You should be able to repeat this 23 more times to create a chain of 25 unconfirmed transactions. However, if you try once more, you should encounter the following error:
Congratulations, you’ve hit the mempool chaining limit!
*FRUSTRATION WARNING: Refer to Note [1] .*
3 Why is the mempool chaining limit a problem?
Imagine that you received a $5 bill as change when you bought a train ticket and then you went to pay for a coffee but couldn’t physically remove the $5 bill from your wallet—it was stuck by some magical force! After some arbitrary amount of time passed the $5 bill would start working again, but in the moment when you needed it it could not be spent. This is exactly the way BCH coins behave due to the mempool chaining limit. When we imagine “cash” having this property, it seems ridiculous.
Fortunately, it is rare for most users to encounter the limit, since it is rare that the same output would be spent 25 times between new blocks. But there are certain cases where the limit is a real problem:
One example is the “on-chain” gambling website Satoshi Dice. Gamblers don’t need an account with Satoshi Dice—they send their bets directly to a BCH address corresponding to their game of choice, and their winnings are sent back to them with a second BCH transaction. Like a slot machine player hammering on the lever, a Satoshi Dice gambler can easily make 25 bets between BCH blocks. If the player’s wallet has no other confirmed coins, then the gambler will have to wait for the next bitcoin block before he can continue playing. And there goes his lucky streak!
Another example is the on-chain Twitter-alternative Memo.bch: posting a message requires making a transaction, limiting the amount of messages a Memo user can send between new blocks to 25 messages per confirmed output in his Memo wallet. Imagine that you’ve thought up the perfect argument in a heated debate and now you can’t post your message until the next block comes in. Rate limiting sucks!
A third example is general wallet reliability. When the BitcoinVerde team was demonstrating an app built on top of BCH at a meeting in Dublin, Ohio, meeting attendees began experimenting with the wallets, passing tokens back and forth. However, they hit mempool chaining limit, at which point they could not longer make transactions, tempering enthusiasm for the concept. I have also heard reports from bitcoin advocates about hitting the mempool chaining limit at conferences and meet-ups while gifting small amounts of BCH to new users to get them started. Talk about a bad first impression for a new user when this new fancy money just stops working!
4 Is the mempool chaining limit necessary?
It isn’t.
The limit is an artefact that Bitcoin ABC inherited from Bitcoin Core due to Core’s full-block policy (specifically, there is an inefficiency in its child-pays-for-payment (CPFP) algorithm that necessitates a small limit). For more information, see this post. https://www.bitcoinunlimited.info/blog/6a710fed-21d3-499a-97a5-e1a419bc0a6f
Bitcoin Unlimited developer Peter Tschipper optimized the CPFP algorithm used by ABC thereby making it hundreds of times faster and allowing it to operate quickly on mempool chains even thousands of transactions long (Fig. 4). The trade-off of the optimization was that at times, for example when the mempool is larger than the block size, it becomes possible that the transactions selected for a miner's block candidate may not be the identical to the set the would maximize fee revenue, possibly leaving a few pennies on the table. For more information, see this explanation. https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/1903 https://gist.github.com/sickpig/589c21fa4294677cc0ab7daf71f8b502
In addition to this work, the O(n^2) complexity was removed from the code that removes transactions from the mempool after they are included in a block that won the PoW lottery (code), and the code that adds a transaction to a long chain in the mempool was optimized (code). https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/2020 https://github.com/BitcoinUnlimited/BitcoinUnlimited/pull/2032
5 Can I send and accept deeply-chained transactions today?
Yes, you can!
Several nodes on the BCH network today support sending and receiving up to 500 chained transactions. If you run a full node, you can join them by adding the following lines to your `bitcoin.conf` file and then restarting your node (these feature will be enabled by default in the upcoming 1.8 release of BU):
limitancestorcount=500
limitdescendantcount=500
limitancestorsize=2020
limitdescendantsize=2020
net.unconfChainResendAction=2
net.restrictInputs=true
If you don’t run a full node but use a SPV wallet such as Electron Cash, you need to manually connect your wallet to a node that supports longer chains in order to send or receive deeply-chained payments. For example, the server `bch.loping.net` and the BU controlled `electrs.bitcoinunlimited.info` supports up to 500 chained transactions. Connect to the BU server by typing in the domain name and port number (`50002`) in the “Server” text box. (Note: if you send a deeply-chained transaction to a person or business whose wallet does not support long chains, they will not see the payment until after one or more blocks is confirmed.)
In theory, this technique works with all SPV wallets. In practice, the option to connect to a specific node needs to be exposed in the SPV wallet’s user interface.
If you use a CoPay-style wallet (e.g., the Bitcoin.com wallet) you will need to wait until the server your wallet connects to upgrades to support longer mempool chains.
6 Long-chain block explorer
In addition to the many nodes and a few electrum servers that support long chains, Bitcoin Unlimited also maintains a block explorer that supports up to 500 chained transactions. This explorer will show unconfirmed transactions broadcast to the network that exceed the common network policy limit of 25 that do not show up on other block explorers.
https://explorer.bitcoinunlimited.info
7 Is it risky to accept deeply chained unconfirmed transactions?
First, let’s try to understand exactly what the concern is. We learned in Section 2 how to create a chain of 25 unconfirmed transactions by repeatedly sending the same coin back into our own wallet. We learned in Section 5 how to connect our Electron Cash wallet to a server that would allow us to send a 26th transaction on top of that chain. Now here’s the worry: A fraudster could send a transaction chained 26 times to a coffee shop that accepts longer mempool chains. But the fraudster would know that many nodes on the network would not immediately learn about his payment because those nodes would reject transactions chained deeper than 25. And so the fraudster could create a second conflicting (double-spent) transaction that sends the coin he used to pay for his coffee back into his own wallet instead. Because this double-spent transaction is also the 26th in the chain, it would be rejected by the same nodes that rejected the legitimate payment if broadcast immediately (it would trigger the error in Fig. 3). Instead, the fraudster must wait until the next block is found, and *then* broadcasts his fraudulent transaction. Since it is only possible for one of the two transactions to be confirmed in the blockchain, the fraudster could theoretically succeed in taking back his payment. Free coffee!
8 Could a fraudster double-spend with Electron Cash?
Let’s find out! We don’t want to *actually* defraud anyone, so instead of trying this on a *real* merchant, we’ll try it on a “simulated merchant.” For this experiment, I’m using a spare Android phone I had lying around to simulate the merchant’s wallet, which I’ve connected to an Electron Cash server that supports long chains. Here are the steps:
Create a chain of 25 unconfirmed transactions as per Section 2
Manually connect Electron Cash to a server that supports long chains
Pay for your “coffee” normally with your Electron Cash wallet (this creates the 26th transaction in the mempool chain)
Manually connect to an Electrum server that does **not** support long chains
Create a transaction that sends "Max" back to your own address (as per Section 2)
Wait until a new block is found and then press “Send.”
If you try this, you will succeed in sending the 26th transaction to the simulated merchant. The balance in your Electron Cash wallet will fall, and the balance in the merchant’s wallet will rise.
When you switch to a server that does not support long chains, your balance will be restored (it will appear as though you never paid the merchant). However, the merchant’s balance will be unaffected (obviously). There are two competing future states of the network at this point: the first state where you paid the merchant, and the second state where you didn’t.
In the attempts I made, I was never able to succeed in reversing the payment. The payment to the simulated merchant would confirm every time. Double-spending a deeply chained transaction is at least not trivial.
9 Why does the double-spend fail?
The reason my double-spend attempts failed is because the network of BU nodes use Intelligent Forwarding (IF) to *defend* the network. The deeply-chained payment to the merchant still propagates across the network. In a very real sense, the legitimate TX exists in the "network wide mempool" just not in the individual mempools of the nodes that reject long chains. The window of opportunity for the fraudster begins the moment an ABC node accepts a new block (and thus becomes receptive to either the legitimate transaction or the double-spend). Each BU node with IF enabled blasts every ABC node that it is connected to the moment the BU nodes learns of a block. Since there are hundreds of BU nodes and each BU node is connected to several ABC nodes, the window of opportunity closes nearly instantly. The manual process we tried above has almost no chance of success. https://medium.com/@g.andrew.stone/quasi-consensus-and-the-unconfirmed-transaction-chain-limit-22e74e33421d
10 Attack #2: Tainting a regular coin with a long chain
There is also a more subtle risk where an attacker taints a regular (unchained coin) with a deeply-chained output, as shown in Fig. 11. He sends the tainted transaction to a merchant who accepts long chains. After receiving the goods or service, he then creates a second transaction that spends only the regular (unchained coin) back into his wallet. Because most miners today reject deeply-chained transactions, the second (fraudulent) transaction will likely be confirmed in the next block and the attack would succeed.
**To avoid this vulnerability, Bitcoin Unlimited by default only accepts transactions chained more deeply than 25 if they spend only a single input.** With this restriction, the transaction marked "legit tx" in Fig. 11 would be rejected by the BU node. (There is no worry that an attacker could taint a parent transaction to bypass the restricted inputs check because without the parent transaction the receiving node will not consider the child transaction as valid.)
This safety feature can be *disabled* by setting the restrictInputs flag to false:
net.restrictInputs=false
11 What about the miners?
Miners can safely mine long chains with BU today provided they do not disable the input restrictions. Without input restrictions for deeply chained transactions, miners mining long chains might unknowingly facilitate double-spend attacks.
12 More advanced attacks
When we began the long-chain testing, our intention was to *quantify* the double-spend risk of deeply-chained unconfirmed transactions compared to unconfirmed transactions chained less than 25 deep. To do this, we also carried out more advanced versions of the race attack described in Section 8. We had fast Python scripts running on Sybil nodes across the globe (including China) that would blast out the double-spend as soon as the new block was found and the miners and other nodes would accept it.
The results showed that the attacker needed either a very large Sybil network (i.e., more Sybil nodes than the total number of BU nodes with Intelligent Forwarding), or more strategically positioned nodes (e.g., nodes closer to the miners). With only a single computer with no special attention paid to its connection to the miners, the attack would fail.
It was during this testing that we discovered a way for an attacker to attempt to double-spend chained transactions *less than* 25 deep, succeed with a high probability and maintain plausible deniability, using only an off-the-shelf wallet such as Electron Cash. The merchant must follow a fairly onerous procedure to ensure he remains directly connected to the entire BCH hash power, including profit-switching miners, to protect himself. We speculate few merchants or payment providers today are doing this.
13 Summary
Today there is already a significant fraction of the network that supports very long chains of mempool transactions (typically 500), including a block explorer and Electrum servers that users can connect wallets like Electron Cash to. Managing long chains is no longer taxing on a miner using child-pays-for-parent thanks to the improvements in the CPFP algorithm that BU made. BU nodes that support long chains use Intelligent forwarding and input restrictions to make accepting deeply-chained unconfirmed transactions nearly as secure as lightly-chained transactions. A merchant can use a BU node and accept deeply-chained transactions without significant risk of double-spend fraud compared to unconfirmed transactions chained less than 25-deep. Our testing however highlighted that unconfirmed chained transactions in general (**whether longer or shorter than 25**) can be double-spent with high success rates by a determined attacker. Merchants must follow a fairly onerous procedure to protect themselves from such attacks.
Network support for very long chains of unconfirmed transactions makes BCH more cash-like, solving existing problems and creating new use cases.
Notes
[1] If a block is found while you are creating the mempool chain, then you will need to do this more than 23 times in order to create a chain of 25 unconfirmed transactions. BCH’s difficulty adjustment algorithm is currently being gamed by miners resulting in bursts of blocks in quick succession, followed by hours with no blocks. If you are attempting this during a block burst, then manually chaining 25 transactions will be frustrating as each new block will reset the chaining length back to zero. Additionally, I encountered problems where certain Electrum servers would not register transactions even for < 25 chaining limit and I needed to manually change servers in EC settings. There also seems to be a synchronicity bug in EC where pressing “Max” will occasionally populate a stale value resulting in an error.
What Makes Satoshi's Incentive Work
*In this article, I will argue that if miners ran the network as described in the Satoshi white paper, incentives would exist to do the research and development necessary to scale bitcoin to meet demand. I will also highlight a flaw in bitcoin's consensus rules—an oversight by Satoshi—that makes it profitable for miners to deviate from his intended protocol, thus partially short-circuiting this incentive. Lastly, I will suggest adding a new rule to remedy the situation.*
Run the Network, Earn New Coins
Satoshi described the steps to run the network in Section 5 of the bitcoin white paper:
Then in Section 6, he said that the first transaction in each block starts a new coin owned by the creator of the block. Those new coins, he believed, would be the incentive to run the network. The work the network would pay for would be precisely the work required to keep it running.
The Proof-of-Work Market is Proof this Incentive Works
Satoshi's incentive was an astonishing success at improving Step 3 (finding difficult proof-of-works). The original bitcoind miner had an efficiency of 0.03 Mhash/J: that is, for each Joule of energy it consumed, it could make 30,000 attempts at finding a difficult proof-of-work for its block. Today, an Antminer S19 has an efficiency of 40,000 MHash/J: for each Joule of energy it consumes, it can make 40,000,000,000 attempts at finding a proof-of-work (yes, 40 *billion* attempts). In just one decade, the free market made Step 3 over *one million times* more efficient. https://en.bitcoin.it/wiki/Non-specialized_hardware_comparison#Intel https://www.prnewswire.com/news-releases/bitmain-announces-specs-for-next-gen-antminer-s19-and-s19-pro-coming-soon-301012293.html
There was no team of "world-class" developers leading this effort, nor was there a need for the protocol to issue new coins to a Hong Kong corporation to fund them. It didn't even require donations from early bitcoin investors. The work happened spontaneously as free people responded with ingenuity to the opportunity for profit that presented itself. The incredible six-order-of-magnitude improvement in mining technology is proof that the free market can develop mind-blowing tech when properly incentivised.
The Block-Validation Market That Should Have Been
Satoshi's incentive failed to improve Step 5 (validating new blocks). The reason is subtle because if miners ran the network as Satoshi described (i.e., if they followed Steps 1 through 6 as written above) a market for efficient block validation technology would already exist. As bitcoin usage increased, the bigger blocks would take longer to validate such that each additional second a miner spent on Step 5 (validation) before beginning Step 6 would shave about 0.17% off his potential revenue (1s/600s=0.17%). A miner with 10% of the hash power would lose ~$1M of potential revenue per year, at $10,000 per coin (BTC). And so such a miner, following Steps 1 - 6 as written, would rationally pay up to $1M per year for technology that makes Step 5 one second faster. The same economics would apply to *all* miners, and so combined there would be a market worth about $10 million per year **per second** of scaling improvement (at $10k per coin). If blocks got so big that the average miner took 11 seconds to perform Step 5, technology that would reduce that time back to 1 second would be worth up to $100M per year!
Unfortunately, this market was not to be. Instead of paying for the development of technology to scale block validation, miners realised they could increase their revenue just as much by simply not validating [1]. They realised that they could assume that the previous block was valid, without first checking what it contained, and then immediately begin mining a new block above it. Worse yet, in order for this new trick to work, the blocks needed to be empty. These validationless miners weren't really even doing the job of collecting new transactions into a block like Satoshi intended. The fact that bitcoin's consensus rules do not discourage validationless mining killed the market for efficient block validation technology, short-circuiting the built-in incentive.
To Create Demand For Efficient Block Validation Technology, Increase the Cost of Validationless Mining
To create a market for efficient block validation technology today, we must make validationless mining less profitable. One way to do this is to add a new rule requiring a hash of the UTXO set (i.e., a UTXO commitment) to be included in each new block. The commitment should be most practical to calculate by actually downloading the previous block and updating one's UTXO set [2].
Adding a new rule for UTXO commitments is *already* on the roadmap for BCH. https://www.bitcoincash.org/roadmap.html
Compete On Different Implementations, and Scale to Global Levels
Imagine that new-car buyers got a fuel rebate for buying a gas guzzler, as well as a $1000 credit if they also bought the *most common* gas guzzler. A lot of people would buy the same gas guzzler, fuel efficiency be damned. Car companies wouldn't invest in making cars fuel efficient, because any fuel they could save their customers would be offset by the customer receiving less benefit from the gas-guzzler fuel rebate. In fact, we'd probably end up with a single car company making the same crappy gas guzzler year after year. This is the situation today in bitcoin where there is no link between how efficiently a node implementation can validate a block and the revenue a miner can earn using that node—validationless mining acts as a gas guzzler fuel rebate. (The $1000 credit for using the *most common* gas guzzler is analogous to the bug-for-bug compatibility miners get if they all use the same implementation.)
But with validationless mining made impractical, miners would need to acquire the best block validation technology in order to remain competitive, just as they need to acquire the most efficient proof-of-work finding technology today in order to mine profitably. A competitive market for high-performance node implementations would be born. This market would deliver the technology and optimisations necessary to build implementations of the bitcoin protocol that scale to global levels.
Cooperate On a Stable, Largely Unchanging, and Economically Rational Protocol
The *protocol* (the set of rules governing what constitutes a valid transaction or block) is distinct from *implementations* of that protocol. Competition on implementations leads to technology advancement, but for the protocol itself, stability, neutrality, and economic rationality is most important. Except for block size limits and the incentive problem described in this article, the protocol can already scale to global levels, so the need for protocol changes should be small or nil.
A special interest group (SIG) could still fund a "reference implementation" but the goals for that implementation might be very different than today. The reference implementation might serve as a *reference* for the behaviour defined by the protocol specification. It would focus on clarity, simplicity and adherence to the specification, not on efficiency. Efficiency improvements (and their associated complexity) would *intentionally* be left to free-market competition.
Conclusion
Bitcoin's current incentive system works and the six-order-of-magnitude improvements in technology for finding difficult proof-of-works proves it. The ironically-named "infrastructure funding plan" for BCH would actually reduce the number of coins available to pay for running the network's infrastructure, giving it to unaccountable third-parties instead. What is actually needed is to make validationless mining impractical, thereby creating a direct link between how efficiently a miner can validate the previous block and the amount of revenue that miner expects to earn. This would lead to a competitive market for high-performance node technology built upon a stable, largely unchanging, economically rational bitcoin protocol [3].
There is amazing technology, waiting on the sidelines, that would allow a bitcoin to scale to global levels. For example, imagine a small router-sized device capable of processing a million transactions per second on a few Watts of electricity. If that sounds crazy, would you also have thought it crazy in 2010 to hear that within a decade the technology for finding those difficult proof-of-works would be *one million times* better?
**Notes**
[1] Indeed the miner forgoes fees for the few seconds while performing validationless mining, but the previous block probably cleared out mempool anyways, so mining an empty block or a nearly empty block makes little difference to his revenue.
[2] It is probably not feasible to make validationless mining impossible, but that doesn't matter. What matters is increasing the cost of validationless mining so that it ideally costs more, but at least not significantly less, than full validation. One solution that does *not* appear to work is using a non-lagging version of a rolling UTXO hash method like ECMH. A validationless miner could simply assume the hash in the last block was correct and quickly update it with the single output created by his coinbase transaction in his otherwise empty block. https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html
[3] Of course, awesome scaling tech is useless if there is only demand for 100 kB blocks. What is even more important than making validationless mining impractical is increasing demand for BCH transaction through increased adoption and new use cases.
The Best Of Intentions: The Dev Tax Is Intended to Benefit Investors But Will Corrupt Us Instead
Despite the best of intentions, the developer service fee, AKA dev tax, will corrupt BCH. It represents a departure too far both from our core principles and from bitcoin as peer-to-peer electronic cash. In this article, I will first explain how the proposed service fee scheme would work, and then I will argue why it has no place in a decentralized digital cash system.
WHAT IS THE DEVELOPER SERVICE FEE PROPOSAL?
In the spring of 2020, after the halving, the supply of new bitcoins will be reduced to 6.25 BCH per block. If the proposal is adopted, the coinbase from each new block would be split into 8 pieces. Seven (7) of the eight (8) pieces (87.5% or 5.46875 BCH) would go to the miner who found the block, while one (1) piece (12.5% or 0.78125 BCH) would go to a newly-formed company domiciled in Hong Kong.
Under the proposal, it would be useful to think of new BCH coinbases as consisting of two parts: a coin that is competitively mined, and a token that is issued for zero cost to the Hong Kong corporation. Because the competitively-mined coin is 12.5% smaller than before the dev tax, the network's hash rate would fall by roughly the same percentage. As BCH represents approximately 3% of the SHA256 hash rate, total revenue for SHA256 miners would fall ~0.4%, all else held constant, as a result of this reduction in mineable revenue.
Under the proposal, BCH developers would change the consensus rules in software so that blocks that fail to issue the 0.78125 BCH to the Hong Kong corporation would be deemed invalid. As explained by BCH developer Mark Lundeberg [**link**] and confirmed by the self-proclaimed "pusher" of the dev tax [**link**], this is necessary to prevent chain splits due to BCH's 10-block finalization and its minority hash power (the alternative is that miners would coordinate the orphaning at the pool level leaving the protocol unchanged). This action would also prevent non-cooperating miners—that together might hold more hash power than the cooperating group—from avoiding the service fee. https://old.reddit.com/r/btc/comments/esebco/infrastructure_funding_plan_for_bitcoin_cash_by/ffapqej/ https://read.cash/@jonald_fyookball/little-known-but-important-facts-about-the-mining-plan-a1f1fe13
The Hong Kong company would then raise capital by disposing of its newly issued tokens, for example, by selling them to investors. A market for these tokens is guaranteed if key exchanges cooperate by running software to enforce the issuance to the Hong Kong company (e.g., blocks that did not issue tokens would not be considered legitimate BCH by the exchange). The proceeds from these token sales would then be used to fund further work by these developers to grow this BCH enterprise. The purpose of the developers' efforts would be to improve BCH as a cryptocurrency, with the expectation of profit for the investors.
In nearly all of the discourse on the developer service fee, it is claimed that miners pay; however, this diagram reveals that the capital raised to pay developers actually originates from the investors who purchase the tokens issued to the Hong Kong company. The SHA256 miners as a group suffer only a small reduction in aggregate revenue, all else held constant. The name "developer service fee" is more accurate than "dev tax" in the sense that it reveals the implicit investment contract between the Hong Kong corporation and the investors who purchase the tokens: the **fee** is passed on to the **developers** who would provide the **service** of advancing the protocol to generate profit for those investors.
WHY THE DEVELOPER SERVICE FEE HAS NO PLACE IN BITCOIN
Although the service fee would create a reliable and stable mechanism to transfer money from investors to select developers, such a protocol change comes with great cost.
IT REDEFINES WHO OWNS NEW COINBASES
In the bitcoin white paper, Satoshi wrote:
*"By convention, the first transaction in a block is a special transaction that starts a new coin owned by the creator of the block.”*
The key word is "owned." The developer service fee proposal would change this so that the miner whose work created a new block would instead own 87.5% of the new coin. The remaining 12.5% would be owned by the Hong Kong authority. By accepting this proposal, this 12.5% would no longer be the miner's property to keep:
https://www.taxjustice.net/2014/10/08/money-taxation-isnt-theft/.
Bitcoin Unlimited's (BU's) mandate is to foster the development and growth of "Bitcoin: a peer-to-peer electronic cash system" as described in the white paper. It is my opinion that BU would not condone this radical departure that hard codes a third-party into the protocol.
COOPERATION VERSUS COLLUSION
Changing the word "cooperating" to "colluding" in the scheme's diagram and adding some kickbacks illustrates the antitrust problem. Regardless of how well the raised capital is managed, at a distance the scheme is indistinguishable from a scam that takes money from investors in exchange for tokens (issued to the HK corp at zero cost and legitimized by colluding exchanges) with the promise of moon lambos in the future thanks to the hard work of its "world-class dev team."
This is only made worse by the fact that the colluding miners, exchanges, and developers benefit *regardless* of whether the tokens appreciate in value or depreciate. As long as the tokens have *some* market value, the scheme can reliably and continually transfer capital from investors to the colluding group members. In other words, the group in control of the scheme has their skin in a **different** game than the investors.
Moving forward with this proposal without legal clarity on the antitrust and conspiracy risks (e.g., to avoid civil lawsuits) is foolish.
THE HOWEY TEST: MINED COINS VS SECURITIES
The "Howey Test" is a test created by the US Supreme Court for determining whether certain transactions qualify as "investment contracts." Transactions are securities if they are:
An investment of money,
In a common enterprise,
With an expectation of profit,
Through the efforts of the promoter.
Bitcoin satisfies all but the last. There is no "promoter" whose efforts are intended to generate profit for the investor. It is for this reason that bitcoin fails the Howey Test and is not considered a security by the SEC.
The proposed developer service fee and the new structure centered around the Hong Kong corporation changes this in an important way. The explicit purpose of the Hong Kong corporation is to pay developers whose efforts are intended to increase the value of the tokens. The Hong Kong company is in fact a promoter!
Moving forward with this proposal without regulatory clarity on whether the sale of the tokens issued to the Hong Kong company, or tokens issued directly to developers, would qualify as investment contracts is unwise.
It is important to recognize that the problem is not the Hong Kong Corporation, it is the issuance of tokens to the third-party encoded into the protocol. The problems remain if the free tokens are issued directly to developers.
IT INTRODUCES FISCAL POLICY IN BITCOIN
Why shouldn't the Hong Kong promoter charge additional service fees to pay for marketers to grow BCH adoption? It would be more useful than further development work. Our network needs new users more than new code. In fact, with Avalanche and proof-of-stake, we could redirect nearly all of the coinbase rewards to the Hong Kong corporation without changing bitcoin's inflation schedule.
Do not take this idea seriously. The point is that once we start paying for one "super important thing" it will turn out that there are many other "super important things" that also need funding. It will not be possible to raise taxes sufficiently high to pay for them all. Deciding which of the super important things are the most important will become a politicized process dominated by opportunists jockeying for position at this new faucet of free money.
The bitcoin protocol is very simple and was mostly complete in 2009 (by Satoshi). It is 11 years later and we should be moving towards a stable protocol (without block size limits) and the role of the "protocol developer" should be waning. Many people are passionate about bitcoin and will continue to do the work that needs doing. And as bitcoin becomes more important to businesses—because we attract more users—these business will also have an incentive to contribute. But with service fees funding a wage assistance program for select developers, these select developers will block initiatives that come from the volunteer devs or companies, to avoid revealing the uselessness of the assistance program. In fact, the developers receiving assistance will create roadblocks that only they can solve in order to justify their continued feeding from the public trough.
THE END
Back in 2013 we used to say that fiscal policy was impossible with bitcoin and monetary policy was known decades in advance. Today, advocates for the developer service fee are too blinded by self-righteousness to see that they've lost the plot, or too greedy and entitled to care. It is bad enough that mining is centralized to the point where it *might* be feasible for a cartel of miners to impose a tax on block rewards. The fact that the community is seriously considering modifying the protocol to kill-off this cartel's competition is sickening. As Satoshi said, "the first transaction in a block is a special transaction that starts a new coin **owned** by the creator of the block." The community must reject any change to the protocol that would make this no longer so.
@PeterRizun
