Drivechain: The latest controversy to impact the Bitcoin community
by Ryan Shea
Key Take-aways
- Bitcoin has always been associated with controversy. In that regard, 2023 has been nothing special. First came ordinals and more recently Drivechain.
- Drivechain is a method to create sidechains on Bitcoin, which its creator Paul Sztorc believes can bring many benefits to the seminal cryptocurrency.
- One of the primary benefits of Drivechain is it provides another way to scale Bitcoin, something that current methods are not able to achieve in a manner that is consistent with Bitcoin’s trust-minimizing ethos.
- Paul also argues that if Drivechain was enacted there would be no need to make any further changes to Bitcoin’s code (soft forks) because all future innovation can be done via sidechains.
- Ossification of the Bitcoin code is something many in the crypto community welcome due to the risk that code changes can create currently unforeseeable problems in the future. (Ordinals being a timely reminder of that risk).
- Therefore, one could be forgiven for thinking that the “last soft fork ever” argument, combined with its ability to improve Bitcoin’s scalability, would mean Drivechain was a slamdunk with Bitcoiners.
- Wrong. Many do not like Drivechain and because its design has “consensus significance”, which means implementation requires a soft fork, Drivechain is likely dead-in-the-water… for now at least.
- What does this imply for Bitcoin’s future? Read on...
Bitcoin has always been associated with controversy. I'm not just talking about crypto versus non-crypto audiences debating whether it is a hi-tech, money-laundering-enabling Ponzi scheme or a financial innovation that frees money from government bondage, but within the crypto community Bitcoin has proved controversial due to its power consumption1 and limited functionality. In fact, even within the Bitcoin community itself, Bitcoin can be a source of controversy. In that regard, 2023 has been nothing special.
Ordinals
Back in January, Casey Rodamor, a former Bitcoin core contributor, released the ordinals protocol. It provided additional functionality to Bitcoin by enabling users to track satoshis, the atomic unit in Bitcoin (100 million sats equates to one Bitcoin). Ordinals allowed users to make what was generally considered a fungible asset, non-fungible2 and to “inscribe” content into Bitcoin transactions.
Putting it mildly, ordinals did not go down well with large swatches of the Bitcoin community – see image - as I pointed out in a previous research note.
Source: twitter
Its detractors were concerned the Bitcoin blockchain would be bloated by garbage superfluous data3, tainting Bitcoin’s use as a monetary instrument as well as increasing the cost of running full nodes that are required to download and store the entire transaction history all the way back to the genesis block4.
Nodes are a critical part of the Bitcoin blockchain architecture. They send and receive transactions to other nodes and verify the validity of transactions. It is this mechanism that incentivizes miners to behave honestly. If miners do not construct blocks of transactions according to the rules enforced by the nodes they will be rejected by the network and miners will be unable to claim the block reward and transaction fees from these blocks. Because miners still incur the cost of running the Proof-of-Work (PoW) algorithm, producing invalid blocks as a result of “cheating” leaves them out-of-pocket, which is clearly not a viable long-term business model.
Trust-minimization is core to Bitcoin’s ethos. For this incentive mechanism to be as robust as possible, there needs to be a large number of geographically dispersed5 (ie, decentralized) full nodes within the network – see image. Anything that works against this outcome, such as increased financial/technological barriers to entry for running full nodes, therefore does not go down well with Bitcoiners. Hence, the widespread criticism of ordinals.
Reachable Bitcoin Nodes
Source: bitnodes.io
By contrast, miners welcomed ordinals because the surge in demand for inscriptions generated demand for Bitcoin block space and this in turn boosted transaction fees, boosting miners’ profitability at a time when it was being eroded due to the combination of increasing difficultly adjustments6 and a stagnant Bitcoin price. As we shall see, divergence between the wants of Bitcoin miners and Bitcoin users is not unusual.
Unintended Consequences
Despite considerable opposition within the Bitcoin community, ordinals were implemented because they did not require any changes to the Bitcoin code7. In fact, changing the Bitcoin code, either via a soft-fork to “enforce strict Taproot validation script size” or a hard fork to reverse Taproot8, is the only way for ordinals to be removed. Absent that, the best opponents of ordinals can do is ignore them9.
As such, ordinals provided a timely reminder that changes to the Bitcoin code can have unintended, potentially detrimental, consequences in the future that are hard to perceive at the time code changes are activated. This will have a significant bearing on how Bitcoiners approach future changes to the Bitcoin code and is very pertinent when it comes to the latest controversy impacting the Bitcoin community: Drivechain.
Introducing Sidechains
Drivechain is a combination of two Bitcoin Improvement Proposals, BIP300 and BIP301 that...
“… allows Bitcoin to create, delete, send BTC to, and receive BTC from “Layer 2’s called sidechains”.
Great, but what are sidechains?
Sidechains are separate, independent blockchains that connect or link to the mainnet or parent blockchain via a two-way peg or bridge. While a lot of commentary about Drivechain describes it as a Bitcoin sidechain, in reality, Drivechain is a way to create sidechains on Bitcoin10.
For sidechains – any sidechains - to function, there needs to be a way to represent the native token of the Layer 1 blockchain (Bitcoin in this instance) on the Layer 2 sidechain. This process is known as pegging-in and it is relatively straightforward. All sidechains need to do is monitor a designated Bitcoin wallet and when users transfer their Bitcoin to this wallet the sidechain recognizes these transactions and issues tokens on its own blockchain to represent these Bitcoin.
Obviously, it is important that the Bitcoin in these wallets cannot be double-spent. Requiring a given number of confirmations of the original deposit transactions before minting the Layer 2 tokens ensures finality, and requiring deposit transactions are multisig stops users from being able to unilaterally transfer out Bitcoin, meaning they are effectively locked.
Reversing this process, or pegging-out, is much harder to do. The reason for this asymmetry is that while a sidechain, whose designers can design it in anyway they like, has visibility of the Bitcoin mainchain - due to its public nature - the Bitcoin mainchain has no way of determining what is happening on the sidechain, or even if there is a sidechain. As a result, there is no way the Bitcoin mainchain can ascertain who owns which Bitcoin representative tokens on the sidechain and who can legitimately redeem them for Bitcoin on the Layer 1 mainchain.
One, admittedly primitive, solution is not to have a peg-out at all. Bitcoin could be sent to a burn address, meaning they become provably unspendable, and upon verifying such transactions the sidechain issues the equivalent number of representative tokens on its Layer 2 blockchain. While feasible, it is not exactly great functionality for users and hence not likely to be widely adopted.
What The L?
One workaround to the peg-out problem was adopted by Liquid Network. Launched back in 2018, it allows users to move Bitcoin between the mainchain and Liquid’s own blockchain, which has L-BTC as its native token. As per the following description, L-BTC is...
“… a special type of asset on the Liquid sidechain. Its supply is verifiably backed 1-to-1 with bitcoin (BTC) held on the Bitcoin mainchain.
Source: https://help.blockstream.com/hc/en-us/articles/900002016823-What-is-the-Liquid-Network-
L-BTC is created when BTC is moved to the Liquid Network and destroyed when BTC is moved out of the network. The process of moving BTC to Liquid is known as a peg-in, and moving BTC out of Liquid is known as a peg-out.”
To peg in, users send their Bitcoin UXTOs to a wallet address under control of the Liquid Federation - a small, centralized, permissioned group of entities - and after 102 block confirmations the Federation issues L-BTC on the Liquid blockchain at a 1:1 ratio to Bitcoin. Pegging-out is the same transaction in reverse, but with one major difference. Only Liquid Federation members are allowed to burn L-BTC and transfer the Bitcoin held in their wallet to users on-chain (they use a 11-of-15 multisig wallet).
This set-up means that users of the Liquid sidechain necessarily have to trust the members of the Liquid Federation not to steal their coins when they return them to the Bitcoin mainchain. Given Liquid was initially designed to facilitate payments between a small relatively group of centralized exchanges, trading desks and wallet providers this was not considered overly problematic. However, it very much goes against the decentralized, trust-minimizing ethos of Bitcoin that attracted many regular users to it in the first place. Perhaps this is the reason why the amount of L-BTC in circulation remains very modest at around 2,700 BTC (or less than 0.1 out of Bitcoin’s current supply11)– see chart.
L-BTC In Circulation
Source: https://liquid.net/
Drivechain
With Drivechain, Paul Sztroc, its designer, is proposing a different pegging-out mechanism that he believes is more in keeping with Bitcoin’s decentralized, trust-minimizing ethos.
Getting into the weeds, BIP300 allows for six new blockchain messages, which outlines how sidechains come into being and, importantly, how BTC moves from the mainchain to the sidechain and back again. Activating Drivechain sidechains requires the consent (or ACKing) - from miners12. This is important because Bitcoin miners play a key role in the operation of Drivechain.
Let me explain.
Under Drivechain, each sidechain stores all its BTC in one UTXO13, called the "CTIP" that is visible to the sidechain. Once pegging-in transactions are verified, the sidechain “mints” representative tokens on its layer 2 blockchain. As always, pegging-in is the easy part.
To handle the more complex pegging-out process, Drivechain gives miners the ability to vote as to whether a peg-out transaction is valid or not every time a Bitcoin block is produced. If the number of miner votes exceeds 13,150 upvotes in a 26,300 block interval (a 50% threshold over a six month period) then the withdrawal is deemed to be valid.
What stops miners from submitting an invalid proposal and effectively stealing the funds is economic incentives. The sidechain community can easily verify if cheating has occurred because the miner would be including a different hash in its coinbase transaction from the one produced by the sidechain as part of the pegging-out transaction. Because pegging out transactions have a minimum three month time delay this gives the sidechain community ample opportunity to convince other miners not to vote for the withdrawal.
The rationale as to why other miners would vote against an “illegal” withdrawal is because if permitted it would likely result in the death of the sidechain and with it all the additional transaction fees they can derive from it. After all, who would send their valuable Bitcoin to a sidechain that promised a two-way peg but was unable to deliver on its promise?
Obviously for this incentive mechanism to work, Bitcoin miners have to receive part of these sidechain transaction fees, but how does that happen without compelling Bitcoin miners from having to run sidechain software? That is where the blind merge mining detailed in BIP 301 comes in.
Merged Mining
Merged mining has been around for a while, it was even mentioned by Satoshi in a Bitcoin forum thread back in 201014 and it gives miners the opportunity to mine multiple blockchains in return for additional rewards. In short, it is a way of leveraging Proof-of-Work (PoW).
However, confirmation that the PoW had been done requires Bitcoin miners to include the proof that they had mined the sidechain on the Bitcoin mainchain. To do this miners need to run software for all sidechains they mine. This is not desirable because it increases the cost of mining, and potentially introduces centralizing forces that are, as already mentioned, against Bitcoin’s ethos.
Blind-merge-mining sidesteps this problem because Bitcoin miners are only required to put a hash in the mainchain blockchain in return for payments from the block-builders on the sidechain, payments that are funded by transaction fees paid on the sidechain15. It provides a way for Bitcoin miners to earn additional fees16 without the burden of running additional software and without having to care what happens on the sidechain in terms of block validity. In return, the sidechain gets security from the Bitcoin hash power thereby avoiding the need to run a separate PoW process.
Why, Oh Why?
Clearly the architecture of Drivechain is complex. It took me a couple of days of digging in order to get a handle on it, which naturally raises a fundamental question - why does Bitcoin need any sidechains at all?
In his blog, Paul Sztorc suggests one of the benefits of Drivechain and the use of blind-merge-mining is that by increasing the revenue per hash for Bitcoin miners, it will increase the security of the Bitcoin blockchain: more potential revenue, more potential hash rate.
Another benefit outlined by Paul is that because sidechains can adopt any rules they like, it makes it possible to innovate and replicate many of the extra functionality seen in other blockchains – smart contract functionality like Ethereum, privacy like Z-cash or Monero etc. As such, he argues Drivechain adoption would reduce the relative attractiveness of Alt-coins compared with Bitcoin. Given the market cap of these other cryptocurrencies is roughly on a par with Bitcoin ($500bn), he believes that by killing the need for these Altcoins will see this capital return back to Bitcoin significantly boosting the price of Bitcoin.
Personally, I find this “One Coin To Rule Them All” argument not particularly convincing. Altcoin creators typically allocate to themselves a share of their project’s native tokens via pre-mining (it is not much different from having an equity stake in a regular start-up). If the project is successful, then the price of these pre-mined coins should go up, financially benefiting the founders. If instead they opted to implement their project as a Drivechain sidechain on Bitcoin the increase in value created has to be spread out amongst all Bitcoin holders, including those on other sidechains or those that remained on the mainchain. Why? Because price arbitrage ensures Bitcoin on any sidechain is equivalent to Bitcoin on the mainchain and vice versa17. The upside would be lower on a sidechain project compared with running it as a standalone.
One could, of course, argue that using sidechains allows project founders to benefit from the success of other sidechains, a “pooling” effect not unlike that deployed by Bitcoin miners, and hence this not a major discouraging factor. However, my guess is that altcoin creators are more motivated by moonshot payoffs and therefore less inclined to adopt Drivechain implementations of their coins. This is especially so if the alt-coin’s success relies on Ponzinomics and pumpamentals (aka s**tcoins)18.
A further advantage Drivechain brings to Bitcoin, according to Paul, is that once enacted there would be no need to make any further changes to the Bitcoin code because all future innovation can be done via sidechains. This would essentially lead to the “ossification” of the Bitcoin code, something many members of the Bitcoin community consider a benefit given the unintended consequences that have followed prior code changes (see above). Indeed, in various presentations Paul has argued that Drivechain could constitute the last soft fork that Bitcoin needs to make, ever.
The Elephant In The Room
As compelling (or not) these arguments are, one of the clearest benefits from Drivechain /sidechains is that it overcomes a long recognized problem with Bitcoin, namely its limited scalability. The issues arises from what is know as the blockchain trilemma – a concept coined by Ethereum co-founder Vitalik Buterin who wrote about in a 2017 blogpost. To wit,
“The trilemma claims that blockchain systems can only at most have two of the following three properties:
- Decentralization (defined as the system being able to run in a scenario where each participant only has access to O(c) resources, i.e. a regular laptop or small VPS)
- Scalability (defined as being able to process O(n) > O(c) transactions)
- Security (defined as being secure against attackers with up to O(n) resources)”
A direct consequence of the trilemma is that every blockchain must make a trade-off between these three desirable properties. In Bitcoin’s case, security and decentralization are favoured over scalability. We know this because of the outcome of the 2015-2017 block size wars19, which was one of the most contentious periods in Bitcoin history. The undoubted winners of this war were the so-called small blockers, who favoured keeping Bitcoin block sizes small to ensure that the entry barriers to running full nodes – and hence supporting decentralization - was kept low.
How do we know this?
Take a look at the following chart. It shows the market cap of Bitcoin versus Bitcoin Cash and BitcoinSV, two hard forks of the original Bitcoin code released in 2017 and 2018 respectively that allowed for larger block sizes. The market caps of these Bitcoin competitors is utterly dwarfed by that of Bitcoin20. The Bitcoin community voted with its wallets and clearly rejected substantial increases in Bitcoin’s block size. (NB: Miners initally favoured Bitcoin Cash on the assumption that bigger blocks meant more transaction fees, in contrast to most regular Bitcoiners.)
Market Cap (USDbn)
Source: coingecko
Limited TPS
Although the small blockers won the blocksize war, with the later activation of Segwit and Taproot21, the maximum size of Bitcoin blocks was effectively raised from 1MB to 4MB. The number of transactions that can be included in blocks depends upon the type of transaction22 but on average Bitcoin blocks contain between 2-4,000 transactions. As per Satoshi’s design, Bitcoin blocks are produced every 10 minutes give-or-take, which means Bitcoin is capable of processing approximately five transactions per second (tps). Compare this with the processing power of other blockchains, particularly PoS blockchains with faster block times that have tps rates in the thousands, or fiat payment companies such as Visa or Mastercard, which also have tps rates in the thousands.
The limited transactional capacity of Bitcoin means there is no way that Bitcoin can ever become a dominant global player in the payment processing business, at least not in terms of number of transactions on the Layer 1 mainchain.
Compounding the problem is the fact that Bitcoin’s block rewards, which miners earn, monotonically declines every four years (known as halvings). Consequently, either the amount of revenue earned by miners will decline, reducing the incentive to add hash power to Bitcoin’s network that provides its security, or transaction fees will have to increase substantially. Based on a maximum tps of five, I have previously calculated that transaction fees would have to be in the range of $50-100 in not much more than a decade to keep Bitcoin’s security budget constant23.
Such transaction fees mean micro payments are ruled out but also pretty much all regular size payments as well. The only transactions that will be financially viable are high-value transactions that in the fiat world are done by large tradfi institutions and central banks. The crowding out of regular Bitcoin users by these entities is the inevitable outcome if Bitcoin’s security budget is to be maintained without relaxing either the 21 million total supply cap or increasing scalability via either larger blocks, sidechains/Drivechain or some other means.
Indeed, as I outlined in the aforementioned research note, my judgement is that in such circumstances the entities who would find Bitcoin most attractive would be nation-states. Trust between nation-states is declining concomitant with rising geopolitical tension (US/Russia/China?) but supply chains are global and nation-states have to be able to make secure, high-value, cross-border payments to each other using a form of money that neither side can ban (unlike fiat). Bitcoin is ideally suited for such transactions.
Does The Cap Still Fit?
As alluded to above, if this is not the future the Bitcoin community wants, the 21 million cap on Bitcoin supply could be relaxed in favour of a tail emissions model similar to Monero, where block rewards are issued at a fixed pace ad infinitum. This is technically feasible, but given the dominance of the Bitcoin as digital gold narrative due to its finite supply – see image - bringing about such a change would require nothing short of an existential Bitcoin crisis as it would mean a majority (probably super majority) of Bitcoin nodes agree to fork in favour of relaxing the supply gap. This is a massive ask.
Source: makeameme.org
Absent larger blocks or relaxing the 21 million cap, if Bitcoin is to avoid being dominated by nation-states using the most secure payment network in history to conduct cross-border transaction or being out competed by other cryptocurrencies with higher transaction volume capabilities, then Bitcoin has to find a way to scale.
Drivechain is one potential solution but based on my, admittedly unscientific, read of the mood on crypto twitter Bitcoiners do not like it. Especially after the ordinals controversy earlier this year the community is extremely wary of altering the Bitcoin code for fear they will be introducing either new attack surfaces to the protocol or opening the door to currently unforeseeable problems down the road. This probably means Drivechain is dead in the water (at least for the foreseeable future) because BIP300/1 have “consensus significance”, meaning that unlike ordinals it can only be implemented via a softfork.
So where does all this leave us?
Sidechains/Drivechain is not the only way to scale Bitcoin. All scaling requires is that transactions can be recorded off-chain. One alternative, which the Bitcoin community appears to be pinning its hopes on, it is the Lightning Network24.
Struck By Lightning
Lightning Network (LN) () is a Layer 2 payment protocol that sits on top of Bitcoin and uses smart contracts to create a network of payments channels so that Bitcoin users can make off-chain payments that only occasionally are “settled” on-chain when the payment channel is closed. This means payments using LN are faster and cheaper transactions than on-chain Bitcoin transactions. Sounds good, but what is the catch?
The most obvious problem with LN25 is that there may not be direct payment channels between two parties wishing to make a payment over the network. The solution is to find a pathway via a series of bilateral payment channels, which is analogous to the famous Travelling Salesman Problem (or should that be travelling salesperson these days – idk?). This is known to be a NP-hard maths problem implying there is no predictable way to compute the solution. This means there is no guarantee that a valid pathway via bilateral payment channels can be found over LN to connect to users wishing to make a payment in a reasonable time-frame. And, if a payment pathway can’t be found, the result is a payment failure, which is clearly not the ideal outcome for a payment network.
One way to mitigate this problem is to have a small number of nodes each with a large number of open payment channels. Such a set-up would make finding valid payment paths somewhat easier, but it does so at the cost of increasing centralization (the old trilemma coming back to bite you).
Moreover, for such centralized LN nodes to be useful, they must also have large capacity. Because payment channels over LN are bilateral 2-of-2 multi-sig smart contracts, when opened the capacity of the channel must be defined. This capacity is equal to the sum of inbound liquidity, the amount of Bitcoin users are able to receive, and outbound liquidity, the amount of Bitcoin users are able to send. In the early days of LN, this meant that these nodes needed to maintain large Bitcoin balances – an absolute honeypot for hackers. In response to these issues, LN developers have introduced workarounds such as the establishment of Lightning Pool, a peer-to-peer marketplace of node operators to buy and sell channel leases, and sidecars, which allow third parties to purchase channels on behalf of other users. Convoluted, I know, but overcoming the trilemma is a far from easy thing to do.
Lightning is very much a work-in-progress and it remains to be seen whether it will be widely adopted by Bitcoin users. So far it is not looking overly promising. Lightning’s network capacity is higher than Liquid Network (4,900 vs. 2,700) but is still very modest compared to the current supply of Bitcoin (0.25% of total supply).
Lightning Network Capacity (BTC)
Source: theblock.co
Roll-up, Roll-up
When one looks at all the options, it is clear that at present there is no way to scale Bitcoin without compromise. Either security, decentralization or the supply cap need to be sacrificed to enable higher transactional throughput, which is itself a necessary condition to stop Bitcoin either being overtaken by more scalable cryptocurrencies or being dominated by players wishing to use the most secure payment network in the world for high-value transactions (most probably nation-states).
The Bitcoin community does not wish to make these trade-offs and with good reason. It runs contrary to Bitcoin’s ethos established in Satoshi’s white paper published over 14 years ago. For now, time is on Bitcoin’s side because even after the next halving, which will occur in spring next year, the block reward would still be 3.125 BTC ($80,000 at current market prices), which is a decent enough payout to support mining hash. But, there is no escaping the fact the clock is ticking and sooner or later the Bitcoin community is going to have to decide what future it wants for the world’s first cryptocurrency. Maybe a scaling method can be found that requires no compromise, or at least less of a compromise.
One recent, but potentially interesting area for exploration is deploying ZK Rollups on Bitcoin26. These utilize zero knowledge proofs, a technology I must admit I have always been fascinated by, but that is a topic to return to in the future.
Until next time.
Ryan Shea, Crypto economist
1An increasingly unfounded concern as I outlined in a La Tribune column earlier this year (French language)– see: https://www.latribune.fr/opinions/tribunes/pourquoi-le-minage-de-bitcoin-peut-accelerer-la-transition-vers-les-energies-renouvelables-964132.html
2Ordinals are not dissimilar to serial numbers on bank notes.
3Cartoon wizards being a particularly egregious use-case – see: https://taprootwizards.com/
4Light nodes, as the name suggests, are faster and more efficient than full nodes but do not store the entire blockchain just the block headers and must connect to full nodes to get block data, meaning they entail some trust in order to function.
5Geographic dispersion is required to mitigate the threat from nation-state actors.
6Difficulty adjustments in Bitcoin occur every 2016 blocks (roughly two weeks based on the target 10 minute block interval) and is a function of the amount of total hash power committed to the network. The higher the hash power, the higher the difficulty. Over recent months, the amount of hash power directed towards Bitcoin has surged to record highs, which is certainly a noteworthy development given miners overall revenues have stagnated over the past 12 months – see: https://www.blockchain.com/explorer/charts/miners-revenue
7Ordinals simply require a Bitcoin ordinal wallet with a taproot wallet address with “coin control” capabilities.
8For those unfamiliar with Bitcoin’s history, Taproot was an upgrade to the Bitcoin code that was activated via a soft fork in November 2021. Traditionally, Bitcoin transactions used OP_RETURN to store data, but outputs using OP_RETURN are provably unspendable meaning they cannot be subsequently transferred. Ordinals data, by contrast, is stored in Taproot script-path spend scripts using the OP_FALSE OP_IF codes, and these can be sent to Bitcoin addresses and held in Bitcoin UXTOs, making them a much better means to store information/data you wish to be able to transfer (sell?) in the future.
9The cost of ignoring ordinals is the value users ascribe and are prepared to pay for these non-fungible sats.
10The code allows for the creation of 256 sidechains.
11Current Bitcoin supply is 19.48m or 92.7% of the 21 million maximum supply.
12These ACKs are subject to thresholds specified in the BIPs.
13Thereby avoiding bloating the blockchain with UTXOs – a good thing.
14In Satoshi’s original idea, merge mining would be possible if the sidechain has a lower difficulty then the Bitcoin network because solving the hash for the Bitcoin network would necessarily imply that they had found the hash for the easier-to-solve sidechain (assuming, of course, both blockchains are running the same hashing function) - see: https://bitcointalk.org/index.php?topic=1790.msg28696#msg28696
15The split between Bitcoin miners and sidechain block proposers on the side chain will depend upon the degree of competition amongst block proposers on the side chain. The greater the competition the higher the rewards to Bitcoin miners and vice versa. One of the arguments against Drivechain is that due to the long pegging-out process Bitcoin miners will be be better positioned than other non-Bitcoin mining block builders and this creates centralization pressures – see: https://bitcoinmagazine.com/technical/drivechains-introduce-new-incentive-dynamics-to-bitcoin
16Drivechains also mean that MEV will come to Bitcoin’s network, which is yet another potential way in which centralization creeps into the protocol (see reference in preceding footnote).
17For a mental analogy think a rising tide has to lift all boats, not just your boat.
18As much as I detest those concepts, it would be foolish not to recognize they exist in crypto.
19For a good read of this episode - see: https://www.amazon.co.uk/Blocksize-War-controls-Bitcoins-protocol/dp/B08YQMC2WM
20You might need to squint to see the lines for Bitcoin Cash and BitcoinSV.
21See footnote 8 above.
22Different types of Bitcoin transactions have different weights measured as Bytes originally and vBytes post Segwit, which add to the blockweight.
23Yes the hash rate may increase due to technology making hashing cheaper, but attackers equally benefit from technology improving meaning the security is unchanged - see: https://trakx.io/privacy-and-security/
24As part of the research for this note I came across a company called Stacks. It also offer a Bitcoin Layer 2 scaling solution that offers its users a more decentralized approach to pegging out using something called Proof of Transfer (or PoX, presumably the X stands for exchange) – see: https://www.stacks.co/ As this research note is already quite lengthy, I will refrain from discussing it here but may come back to it in a future research note.
25There is another problem that is for nodes to be able to make and receive payments they must be online. If one party is not online, opening one up to what is known as a fraudulent channel closure” where one party can settle a transaction that may not be approved by both parties. For a more in-depth look at the issues with LN – see: https://unboundedcapital.com/blog/why-lightning-doesnt-work
26See: https://bitcoinmagazine.com/technical/zk-rollups-are-coming-to-bitcoin-heres-all-you-need-to-know
