BIP-110, V30 and the Miners

Until around 3 years into my bitcoin journey/epiphany, I did not run a node, and before this time I did not really understand the significance of this action (yes, not doing something is either a conscious or subconscious decision). The logic was strong, if you don’t run your own node, you don’t know whether you’re running the correct version of the code, so you cannot verify that those bitcoin in your wallet are actually bitcoin, or rather those sitting on Sam Bankman Fried’s magical node. I wasn’t using FTX so the level of concern was less, but still my position, holding self-custody bitcoin didn’t take account of other factors of running the node. Bitcoin is the network, bitcoin is the asset, to hold the asset, people need to run a node to maintain the network, running a node means you’re part of the network, making a contribution to the continued running of the most important monetary network. This is not an altruistic act, it is just necessary, then combine with this, if you run a node, there is the, not insignificant, point of when you transmit a transaction, it emerges through your node, potentially on the Tor network. Rather than some third party knowing something about your IP address, and information about both your address and your recipient, this is a massive improvement in the sovereignty and privacy of your interaction with the network. Kind of important in the UK at the moment, Bluewallet simply wouldn’t work with the VPN set to London!

While the cost of a @start9 server, combined with the sats I have since lost as my “ride the lightning wallet” suddenly changed, locking me out of my carefully curated, but totally unprofitable lightning node, are not insignificant, to begin with, running a node was definitely value adding. It was also quite straight forward, v26-v29 were all very “vanilla”, updates addressing identified bugs, and continual error reduction process towards perfection. I was aware of @knots, but being maintained by a single person felt like slightly too much risk initially, even if Luke was the Sigwit Wizard, a single point of failure was not ideal, so remained with core. This was until v30 was released and while staying with the older version was definitely the sensible option, looking forward, I realised I’d have to make a choice about what to do. At the time, it was not the expansion of op_return that I had an issue with (I didn’t understand why such a change needed to be made), rather the process bitcoin core went through. Rough consensus did not appear to have been reached, there were parties (Citrea for one), with explicit vested interests in the change, and as I learnt more, there was specific data storage (and data type) trade-offs for node operators would have to deal with. And so, I moved to run Knots, if nothing else, as a protest for bitcoin core developers working and pushing against a large portion of bitcoin holders, small blocks were chosen for a reason; is increasing op_return simply a Roger Ver backdoor?

A little spoken about consequence of an op_return increase

Something else that has come apparent about running a node, is not simply the publishing of your transactions to the network, but receiving and confirming new transactions and blocks, before they are relayed to your nodes’ peers. Being part of this process is what allows all nodes in the network to have the most up to date record of the blockchain, and so allowing miners to validate when new blocks are added, before beginning hashing the next block. This is a very important process for the miners, because any time they can save in confirming a new block, the sooner they have a chance of winning the next block. This was an issue for the big blockers during the Blocksize War, because with bigger blocks, due to data transmission delays of the larger blocks, there was more opportunity for miners to think they had won a new block, only to later find out that a particular block had already been mined. While this still happens, the idea of more frequent occurrences of miners mining orphaned chains would represent considerable wasted energy as they hash blocks that have already been mined.

In this situation, if the size of a given block increases, it will take longer for the block to disseminate across the network, but in addition to this, if a newly mined block is received by a peer, that include op_return data, or indeed transactions that are not present in their mempool, these transactions will need to be verified. If, for example, miners have chosen to mine sub 1sat/vb transactions, potentially associated with ordinals or BRC-20 tokens, it will be necessary to individual nodes to download and verify these transactions, to ensure they are consensus valid, before relaying onto their peers. Compared to simply checking those transactions already in a nodes mempool, this will be a much slower process (cannot quantify though), so each node that is not operating similar mempool policies as the originating miner will slow propagation.

Ah, I hear you say, computers process information quickly, data can be transmitted at the speed of light, but, light takes 0.13 seconds to travel around the earth. With all the additional downloading and confirming of transactions during this journey, this time is likely to increase, potentially significantly. At which point, the ball dropped. All the nodes that are running instances of bitcoin that are not consistent with those run by the miners are making a decision to either not validate, or at least slow the transmission of blocks. While individually, these nodes may have no measurable impact, as the number of this type of node increases, particularly in well place positions in the network, those blocks with transactions or op_returns that don’t match individual instances’ views of bitcoin, will hamper miners choosing to include op_returns or add “dust” to the dataset.

Interestingly, while I’m not a fan of these low fee transactions or the “well actually it’s just a database”, philosophical arguments (no bru, it’s money), Jimmy Song brought considerable clarity to my thinking with cold hard numbers (thank you Sir). With the addition transmission of increased op_returns and increased validation, due to delayed retransmission, if a miner somewhere in the world is delayed in confirming the next block by just 6 seconds, that is a 1% reduction in mining the current block. Given the tight margins of many miners, the argument for a 1% improvement in uptime by not mining such blocks (effectively productivity), must be something worth thinking carefully about. Using back of a fag packet maths, to offset this loss in uptime of 1%, the extra fees you make on your additional, funky transactions would need to be at least 1% of the block reward subsidy (~3.1 million sats) in addition to the transaction fees of “normal transactions”. Then to add insult to injury, once one of these low fee/token heavy blocks are mined, the transmission delay could also increase the chance of a block being found by another miner, so orphaning the originally minded block (100% reduction in efficiency).

While based loosely upon Jimmy Song’s discussion with @CedricYoungelman, there is at least some ideas that are worth exploring further, the logic may be over simplified, and numbers could have a stronger foundation. However, Bob Burnett has run the numbers, to explore the relative profitability of different mining pools, finding that Ocean was consistently more profitable that other mining pools. While this may have something to do with the direct payout mechanism, rather than the favoured FPPS approach of most miners, there could be another explanation. While each miner has the opportunity to run their own instance of bitcoin, with Ocean’s machines actually mining blocks thanks to Datum, it is likely, if not certain, that miners will be running instances with op_return of closer to 80bits. If this is the case, those blocks mined by Ocean would be transmitted more quickly through the network, leading to more uptime, so greater profitability for those mining with Ocean.

The BIP-110 Distraction?

While I have listened to a number of BIP-110 podcasts, in terms of it representing a soft fork, limited to just a year to limit data fields at a consensus level, based on my understanding, which has developed while writing this piece, this would not only slow, but prevent op_return data from being transmitted across the network. While the above discussion provides a free market perspective of incentivising voluntary adoption to limit arbitrary data in an effort to improve miner efficiency, this soft fork would prevent non-consensus valid blocks being transmitted at all. For those miners, such as Ocean, in theory this would not affect their mining process, they would likely continue mining similar blocks to the ones that have previously mined. However, once initialised, if another miner  mined a “non BIP-110 compliant” block, it would not simply have its transmission slowed across the network, those nodes running BIP-110 compliant versions would reject those blocks and not relay them. On the one side, this might provide Ocean mining, for example, addition time to find another compliant block to build the longest chain. However, on the other side, if non-compliant miners continue to add blocks, this will create a chain that represents the one with the most proof of work, which given Ocean’s portion of the network, is highly likely.

Based on my understanding of the workings of bitcoin, if those miners that are BIP-110 compliant continue to only mining upon previously mined BIP-110 blocks, they will begin working on a separate chain to those other miners, meaning a chain split will have taken place. In this scenario, all the bitcoin associated with the BIP-110 compliant blocks, will be different from all the bitcoin associated with the non BIP-110 compliant blocks. These two coins; BTC110 and BTC(op_return), with the latter, initially at least, being associated with considerably more mining resources than the former, meaning that latter will likely add considerably more blocks, so creating the dominant chain. Saying this, given the threshold for activation is 55% for BIP-110, if miners were mining at this scale, it would be likely that if a chain split took place, the BIP-110 compliant blocks would be added more quickly, suggesting that could become the dominant chain. However, the current level of miners signalling is dramatically under this threshold (<1%).

Interestingly, this is only part of the process, which was eloquently pointed out by @grassfedbitcoin (although am yet to find the clip), where he calmly identifies the need to 3 options in any proposed soft fork. A) Do nothing, keep using core or the implementation of choice, B) Activate BIP-110 and prepare for a potential chain split, or C) Activate a counter implementation, potentially from Core that addresses issues raised by bitcoiners. Currently, there is no option C, reflecting a position from Bitcoin Core, in a similar vein to v30, where changes are made without broad consensus, but also responses are not given for valid concerns in the eco system. If bitcoin core allows/promotes the inclusion of arbitrary data on nodes, there is no telling what could be included, and what any law-abiding node running may have unwittingly downloading when synchronising their node. Bitcoin core have opened the door for government attention on the content of the blockchain, with no regards for its impact on bitcoin’s monetary properties, hmm, it’s as if a bitcoin core developer didn’t realise bitcoin is money (Thank you Matthew).

In bitcoin, attention needs to be given to the stability and robustness of the code (see Ossification and Bitcoin Development), not back room deals to promote the use of the network outside of its monetary utility. With v30, it appears attention was not given to the vast majority of bitcoin holders, reflected in the recent rise of nodes running bitcoin Knots, or only around 15% of those running core using the latest version. While taking considerable liberties with the reasoning behind this, it does show that considerable trust may have been lost in bitcoin core since v30, with people calling for more implementations outside the currently dominant bitcoin core and knot. Such a situation, while obviously introducing risks with the implementation of new/altered code people are running on their nodes, it would at least reduce what appears to be excessive power residing in core and over reliance on an individual (@LukeDashjr). But let’s remember, there is further flexibility and nuances that bitcoiners have available to them; if they worry about bugs in alternative implementations, broadcast transactions using an established client. Then, if you don’t want transactions of a particular type being relayed or transmitted, either customise your mempool/node settings to reflect this, or run an alternative instance and simply turn off your established client when you’re not making a transaction.

So which way Sovereign Bitcoiner?

“The directing mind is that which wakes itself, adapts itself, makes itself of whatever nature it wishes, and makes all that happens to it appear in the way it wants.” Marcus Asurelius, Meditations

As a young man, I considered philosophy was something those “not doing proper subjects” did on the other side of campus, but today I realise what I once looked down on, from an engineer’s high ground, is critical. On many occasions it is not about finding the right or perfect solutions (which is of course, is the enemy of the good), but a process of understanding who you’re dealing with, then working out how best to present your ideas. Philosophical perspective, however naive, an ability to rationally question established logic and knowledge provides a powerful tools for better understanding the world and those operating within in. I fully admit, I’m still a student and am yet to pitch any idea to anyone successfully, from a philosophical or other perspective (I write rather than debate), but I’m working on it. Within the bitcoin core, knots and BIP-110 camps, there are important arguments or discussions to be had and answers that need to be sought, not least; why make such a significant change without broad backing for v30? Given bitcoin is not a formally structured hierarchy, operated by those in power, but an anarcho-capitalist structure, where individuals voluntarily contribute time effort and resources to operating the Bitcoin network, the individual has power. The individual node runner then needs to make a decision, and decide what is important to them, and then take actions to be part of a world they want to live within. While the bitcoin time chain can be viewed as a database, is this the highest purpose of data stored across thousands of nodes across the world, or should we attempt to reserve scarce block space as a ledger for transactions of sound, censorship resistance money? I know which side of the argument I will not be shifted from.

Unless there is a dramatic upswing in adoption of BIP-110 by miners, it is unlikely to be activated, but is that even the point? BIP-110 (and anti BIP-110), with all its anger, division and even some mud-slinging has got people asking about what is important? Honestly, how many bitcoin holders really think arbitrary data is part of a path towards bitcoin winning? Please raise your hand at an in person bitcoin event if you do. Personally, I know it will increase the amount of data I have to store on my node, has not increased the amount of money miners are able to make while opening doors no one in public should really want opening (even if you’ve received emails from Jeff). My directing mind is simple, it adapts itself (I had been unconvinced/confused until doing this work myself), I decide what is within my control (my node), adapt that (run Knots) and share my views. I cannot control the network as a whole, and maybe BIP-110 will show even those with some weight and podcast appearances can’t either, but if more people with similar points of views, as presented here, can hamper or slow the transmission of data we have no interest in storing, maybe our impact can be felt. If we also informed bitcoin miners that their decision to mine lower value (non-monetary) transactions or include large op_returns will negatively impact their profitability, we can maybe talk in the language of the ever “profit maximising” fiat brained miners. Would it be more profitable to only mine transactions with more than 2sats/vb, so that you can broadcast a smaller, part block that is transmitted more quickly through the network so you can begin mining the next block more quickly? I don’t know the answer and it would harm transaction throughput, but it has to be worth a thought. Put quite simply, would you mine/invest with a company or mining pool that is reducing your profitability by at least 1% because they choose to include arbitrary (potentially harmful) data in blocks? From there, we can make all that happens to \[bitcoin\] appear in the way \[we\] want.