Blockstream's Big Mistake

A. Summary

Blockstream’s 2014 paper Enabling Blockchain Innovations with Pegged Sidechains may have inadvertently been the largest setback in the history of Bitcoin. We still suffer under it, today!

It contains a disastrous section – 4.3 – which has crippled the Bitcoin intelligentsia ever since. It probably set Bitcoin back 10 years (or more), by unfairly maligning the sidechain – Bitcoin’s most important and (probably) only viable type of L2.

B. The Damage

If only the paper had never been written!

Alas – it’s mere existence contributed, indirectly, to these problems:

• The blocksize war. – (It would never have happened, if Largeblockers could have just gone onto a largeblock sidechain.) – The War turned Bitcoiners against one other. It opened the door to Ethereum and Altcoins. It hurt adoption, and confused users. Etc.
• Sour grapes. – (If we had access to new tech, this also would never have happened.) – These days we say “we never wanted any features” (such as privacy) in the first place. This legitimizes Altcoins. It redirects people into frivolities (such as NFTs, ordinals, ‘treasury companies’, and podcasts).
• Lightning – (If we had L2s that worked, no one would pay attention to Lightning.) – 10 years wasted, on a failed idea. Worse – everyone is lying to themselves – about the viability of lightning. It is a self-perpetuating cult. It destroys everyone’s integrity.
• Spinelessness and Cowardice – Everyone is afraid – to disagree with “tech celebrities” (including but not limited to Greg Maxwell). An environment of fear cannot make any progress.
• Derangement – Bitcoin has become deranged, from a lack of competition. – (With sidechains, there would be healthy competition [among L2s] every step of the way.)

And – these are Bitcoin’s biggest problems! It delays adoption. It causes malinvestment. Good projects get ignored; nonsense junk gets all the attention. Twitter becomes important, people become manipulated, etc. It’s all a big distraction.

I have brought this up in the past – but it’s time to make it slightly more explicit.

We must:

• Face this mistake, and vanquish it.
• Restore “sidechains” to their rightful place, as the optimal L2.
• Restore “competition” and “growth” as important governing principles.

…so that we can finally move on.

Part 1. Why Section 4.3 Is Wrong

The writing in Section 4.3 is dreadfully unclear.

Each sentence contradicts its predecessor. And the argument forms a long, winding, tortured road that ends up not leading anywhere (literally).

But – in order for you to understand why it is wrong, you must understand what it is.

So, I will now quote the entire thing, and interpret it for you. While critiquing it.

Buckle up!!

i. Lines 338-340

An important concern is whether the introduction of sidechains with mining fees places resource
pressure on miners, creating Bitcoin centralisation risks.

This sentence is a summary of their concern.

The logic of the sentence, is:

1. “Sidechains” –> might cause –> “resource pressure”.
2. “Resource pressure” –> might cause –> “centralization risks”.

ii. Lines 340-342

    Because miners receive compensation from the block subsidy and fees of each chain they
provide work for, it is in their economic interest to switch between providing DMMSes for different
similarly-valued blockchains following changes in difficulty and movements in market value.

Translation:

1. Miners can only mine one blockchain at a time. [Wrong]
2. Miners will “switch” blockchains, to maximize their profits.

I added “[WRONG]” next to point #1, because it is wrong.

In fact, the very next paragraph explains why it is wrong…

iii. Lines 343-347

…as follows:

    One response is that some blockchains have tweaked their blockheader definition such that it
includes a part of Bitcoin’s DMMS, thus enabling miners to provide a single DMMS that commits
to Bitcoin as well as one or more other blockchains — this is called merged mining. Since merged
mining enables re-use of work for multiple blockchains, miners are able to claim compensation
from each blockchain that they provide DMMSes for.

This corrects the record.

The authors now say (correctly) that merged mining allows miners to mine many chains at once (and for free). So – we’re back on track… for now.

iv. Lines 348-349

Now, the real problems begin.

(And, here the writing becomes even worse.)

    As miners provide work for more blockchains, more resources are needed to track and validate
them all.

This sentence contains a mistake. And the authors will admit this, in their very next paragraph.

Nonetheless, I will pre-explain it now, anyway.

(Sigh.)

The authors intended to say this:

1. Each “blockchain” has a way “to track and validate” it.
2. That “way” is called: “running a node”.
3. Nodes aren’t free. Each node costs “resources”.
4. Miners must “track and validate” a blockchain, in order to mine it. [Wrong]

Point #4 is wrong. (As they will admit later.)

I know the intent of the authors, because I have spoken with (and debated) [many of] them for 10+ years.

However, their English (above) is unclear. An outsider, might misinterpret 348-349, as:

• Each “miner” provides some “work”… to the “blockchain(s)” of their choice.
• As miners go about “providing” work to chains… each chain ends up with a different “quantity of total work”.
• The chains with “high total work”, are harder to “track and validate”. [Wrong]

This interpretation is NOT what the authors intended – but it turns out not to matter. Coincidentally (or perhaps, inevitably), both versions are wrong for the same reason. And it is easier to catch the mistake in this version. So I’ll elaborate.

If we translated that 2nd version to “Bitcoin lingo”, it would say: “if the difficulty adjusts upward, then full nodes will automatically become harder to run”.

But that is clearly false. And it is also laughable. Technical bitcoiners would make fun of you, if you argued that. Because, everyone knows: no matter what the current work-level is, the cost of running a full node remains exactly the same. Even if we magically shifted the work-level around, to extreme values? Yes, the effect on full nodes would be zero. Our full node would dutifully hash the 80-byte header, and compare that number to the bits field of the previous header. One case is “Is 7 < 16?”, and the other case is “Is 4500 <8000?”. To a computer, those tasks are almost literally identical. One is not more computationally expensive than the other.

v. Aside 1: The Central Confusion

It is important to sidetrack for a moment, and dwell on this mistake.

Because we have hit on the central confusion of the paper:

1. Node Costs, vs
2. Mining Costs.

The paper frequently mixes up the two. Overall, it tries to argue:

1. Node costs are bad. We, the users, want cheap nodes. We should fight… to keep nodes cheap! [TRUE]
2. Miners need to run a node (in order to mine)… [FALSE]
3. …therefore, it hurts miners, when node costs rise… [FALSE]
4. …therefore, we users should fight to keep mining costs down. [FALSE]
5. (These includes node costs, which [after all] are a part of mining costs.) [FALSE]
6. Thus, we make it easier for everyone to mine… even the little guy! [FALSE]

The first statement is absolutely true. Nodes are the cost of reading the chain. They’re how we receive Bitcoin. We want them cheap.

But mining is a separate thing.

Miners are free to take whatever risks they want. They can run a node. Or, they can instead gamble, using another’s node. (Namely, the node at their pool.) This is a business risk/reward decision that they make – like hiring 3 security guards instead of 4. (I explain this graphically, in my reply to Peter.)

The overwhelming majority (99%+) of miners today, do NOT run a node. Instead, they use their pool’s node.

Nodes are for people who receive a lot of coins – people like Coinbase and Kraken and BitPay. You should run a node, if you have many incoming Bitcoin payments.

So, point #2 is flatly wrong. (More details in Part 3, section 1.)

Points #3 and #4 are also wrong. It is folly, to “keep mining costs down”. Mining costs are set via difficulty adjustment. It is not possible to “lower” them. (We might, perhaps, want to hold down the barriers to entry for new miners. But these have nothing to do with node costs.)

Point #6 is also wrong. We shouldn’t focus on “scale” in this case. (More about that later.)

Anyway – let’s proceed.

vi. Lines 348-350

         Miners that provide work for a subset of blockchains are compensated less than those
which provide work for every possible blockchain.

This sentence seems to be simple and innocent.

But even this little sentence manages to be wrong, mangled, and confusing.

It tries to say this:

1. Miners prefer having more money, to having less money.
2. If you mine more chains, then you get more money.
3. Every miner should mine every chain! Else, they are at a disadvantage. [WRONG/CONTRADICTED]

But point #3 only holds if mining those chains has no cost. After all, Profit equals revenue minus cost. If you forget to subtract the costs – then that’s an obvious mistake!

And the authors just said – a moment ago! – (in “iv.4”) that mining a chain has costs. Very specifically, they argued: “mining more chains” = “more costs for miners”.

So – some chains could be money-losers. Their node costs would be high; and their fee-revenues (etc) would be low.

You have to subtract [revenues-costs] first!

vii. Aside 2: Geniuses or Cranks?

Did they really make such an obvious mistake?

Yes.

Of course, perhaps they expected us to (automatically) exclude all money-losing chains? But in that case, every chain is adding some money. There would be no disadvantages – only either [1] an advantage; or [2] nothing.

Based on how confused they are, in every other sentence in this section, we are forced to conclude that – yes, they also mixed up “profit” and “revenue”. Without realizing it.

I suppose it doesn’t make any difference, either way…

viii. BACK to Lines 348-350

In any event – their sentence is false. “Miners that provide work for a subset…” do NOT necessarily have lower total compensation, overall.

In fact, the authors are about to contradict themselves, yet again. They are about to say that small miners will have lower total compensation, if these SmallMiners mine high-nodecost chains.

ix. Aside 3: Confused Yet?

But – if you’re confused: good. You are correctly realizing that their argument is bad.

You see, they want it both ways:

1. Some chains are so expensive to mine, that they cause pain and suffering for any miner who undertakes this ordeal – by putting “resource pressure” on these miners.
2. Some chains are so lucrative to mine, that they cause pain and suffering for any miner who misses out on participating – since these miners are “compensated less”.

[sarcasm] Wow, what a tragedy it is? To be a miner. Everything is always bad news!

On top of that, there is a 2nd, related contradiction:

1. Miners are slaves to revenue. If they can earn $0.10 by running an L2 node, then it is mandatory that they do so. They must do it (or else – they will “fall behind” and go out of business).
2. Miners are unable to safely shirk any cost. Miner must run every L2 node – even if that node is really, really expensive. (Ie, more than $0.10.) Miners are prohibited from “creative” acts of cost-minimization (such as [using a friend’s node], or [subscribing to a node service]).

These contradictions stem from the author’s misplaced paternalism. They are really worried… about who the equilibrium miner is, and who it might end up being later. The authors see themselves as people who must govern the mining world. This is false. Instead, the mining world is a complex place, that will automatically adapt to fit Bitcoin’s needs. And it will do this no matter what – miners will mine, no matter what is said or believed by Bitcoin-enemies (or Blockstream-authors).

x. Lines 350-352

Finally, the boogeyman of “scale” is introduced:

                                                   Smaller-scale miners may be unable to afford
the full costs to mine every blockchain, and could thus be put at a disadvantage compared to larger,
established miners who are able to claim greater compensation from a larger set of blockchains.

It’s trying to say:

1. A node is a fixed cost [or barrier to entry], which everyone must pay, to “start up” their operation. [WRONG]
2. For a larger operation, this fixed cost is a smaller % of the cashflow of their business model. [WRONG]

But both points are wrong:

1. Point #1 is wrong, because miners do not need a node, to mine.
2. Point #2 is wrong, because 0 is always 0% of any other number (but also for other reasons, see below).

xi. Repeat – Lines 350-352 – Elaboration on Scale

Let me re-interpret it again, in more detail:

1. “Mining” has something called “scale” which is easy to define and measure. [WRONG]
2. In this context, “scale” affects both “revenues” and “costs”. [WRONG]
3. Small-scale miners cannot afford to run some nodes. [WRONG]
4. This is bad, because without those nodes, they cannot mine. [WRONG]

All of that is wrong.

Here’s why:

1. No one knows exactly what scale they are talking about. First, are they talking about pools or hashers (or something else)?
   • If they are talking about pools, then: the scale of a pool has nothing to do with software costs. That scale is set by other factors: [1] statistical variance, [2] the L1 blocksize (which can only payout so many miners), and [3] need to manage the pool’s brand. Any and all software costs (100%), will be passed on, to the pool’s hashers in the form of the pool’s fee. This cost will be microscopic, compared to the revenues pulled in by any reputable pool. It is quite easy to start a new pool (though we should always make it even easier), so no pool can abuse its “scale” in any serious way. Any “scale” a pool has, is only loaned to it by its members.
   • If they are talking about hashers, then: the scale of a hasher also has nothing to do with software costs. Hashers don’t run the node software – instead, they point their hardware at a pool, and the pool does the rest. Nor would it matter if they did! The cheapest viable ASIC, costs at least $100 upfront, and more $ each day (for electricity, cooling, security, etc). Realistic mining scales, run into the millions of dollars per year of expenses. It’s not possible for node software to cost this much – because it must be run by regular users (aka, “0% hashrate miners”).
   • So the whole thing is nonsense!
2. Scale will NOT affect costs, because (in this case) the costs are (in this case) always zero. Hashers don’t need to run the node software, at all. They can outsource it (for example, to pools). And pools don’t need to run it either! If it is too expensive, pools can outsource it to anyone else. And if no one runs the chain, then that chain simply doesn’t exist. (In which case – that’s the exact scenario we are in, today, with our zero sidechains – so how could it be a problem?)
   • By the way: scale also won’t affect revenues [ie, not per-unit revenues]. The revenues have to be redivided among the constituent members. (After all, its not like I’ll pay 50% higher txn fee to have my txn mined by Foundry, or something).
3. Again – this is both false and irrelevant.
4. Again – it is quite easy to mine, without running a node. Most miners do.

So far: everything argued in 4.3, has been either wrong or irrelevant.

The authors agree! In fact, (yet again) they’re about to wipe their own argument(s) away.

xii. Lines 353-356

In the very next two sentences:

    We note however that it is possible for miners to delegate validation and transaction selection
of any subset of the blockchains that they provide work for. Choosing to delegate authority enables
miners to avoid almost all of the additional resource requirements, or provide work for blockchains
that they are still in the process of validating.

Yes. Exactly what I told you (in “v. Aside 1”)! Mining costs and Node costs are different.

Believe it or not, there are only two sentences left. So – what was the point of writing section 4.3? Was it supposed to be a tour of various misconceptions? Maybe the last two sentences will pull it all together?

xiii. Lines 356-358

Here’s the 2nd-to-last sentence:

                                                     However such delegation comes at the cost of
centralising validation and transaction selection for the blockchain, even if the work generation
itself remains distributed.

But – like most of the other sentences in 4.3 – it is wrong.

I’ll translate it:

1. We can compare two worlds: “delegate-world” and “redundant-world”.
   • In the “redundant” world, everyone always runs their own node.
   • In the “delegate” world, (some) people (occasionally) choose to rely on a friend’s node (sometimes).
2. That “delegate” world… has fewer nodes (than “redundant-world”)… [WRONG]
3. … and this “centralizes validation”. [WRONG]

Point 2 is not necessarily true. The requirement to run a node, might deter you from joining in the first place. Usually, when something has more requirements, people want to do it less.

To take a silly example: imagine two girls invite you on a date. A scientist will measure: “which girl will you ultimately spend more time with?”.

• Date 1 – You must marry the girl immediately – and stay with her forever.
• Date 2 – You must attend the 1st date, but afterwards there is no obligation.

Most people will avoid Date 1.

Point 3 is also incorrect. “Validation centralization” is not the quantity of L2 nodes. Instead, “centralization” is the cost [of starting up a new full node]. Each L2 network has its own “centralization” metric. Yes, you could “add them up” – you could produce a “cost of running all nodes” metric. That sum would, of course, grow larger as we add more sidechains.

Is that really what the authors meant to say?? If so, it is pure nonsense. The sidechain node costs, must be compared to whatever else would be processing those Bitcoin transactions. Only then, can we determine if “centralization” is higher or lower, as a result of using sidechains. For example, if instead custodial Lightning processes these transactions (or VISA, or traditional banks) – then what is my cost of running an L2 node? Near-infinite. (It is a heck of a lot more than what it would cost to run a high-blocksize L2 node!) So, in that case, sidechains vastly improve decentralization.

In addition to being wrong, lines 356-358 are irrelevant and misleading. The title of (4.3) was risk of centralization of mining – but the only thing discussed, was node costs and how they are optional for miners. This section has the wrong title!

xiv. Lines 358-360

Now, the final sentence:

                             Miners might also choose instead to not provide work for blockchains
that they are still in the process of validating, thus voluntarily giving up some compensation in
exchange for increased validation decentralisation.

I’ll translate:

1. If miners are willing to give up some $$… [WRONG]
2. …then they can still use their own nodes, instead of “delegating”.

Point 1 is wrong, because miners aren’t going to “voluntarily give up” any money. (Especially if their competitors don’t.)

That’s just bad design.

xv. Summary of Section 4.3

So – we made it to the end.

The whole section is nonsense. Convoluted, erroneous, and misleading nonsense.

Overall, it tries to say:

• The introduction of sidechains, allows miners to earn more $$. [TRUE]
• While doing so, miners might run nodes of these chains (or they might not). [TRUE]
• If they don’t, this might cause a risk of “centralization”. [FALSE]

Currently, we have zero sidechains – and zero sidechain nodes. None are run by miners, and none are run by nodes (and none are run by anyone else). Presumably, this is a situation of infinite centralization – and indeed it is. That is because the cost of starting a new sidechain node, is currently infinite. It is being gate-kept… by the very authors of the paper.

Ironically, the author’s themselves imposed the biggest “centralization pressure” on the Bitcoin network – by strangling this idea. (They also apply the most “resource pressure”.)

Part 2. What Should Have Been Written

Here’s what the paper should have contained, instead.

First, a new Section 4.3:

4.3 -- Nodes of All Shapes and Sizes

As we introduce more blockchains to users, more resources are needed to
track and validate them all.

Not everyone will be able to run a node, of every chain. But this is OK
-- it allows Bitcoin to have chains of all shapes and sizes. Chains can
have different blocksizes, in precisely the same way that they have
different cryptography or hash functions. Some chains can be centralized
(with expensive nodes), and others can be decentralized (with cheap
nodes).  All chains would be linked together, on the same Bitcoin 
network -- sharing the same 21 million coins.

And next, a new section (4.4):

4.4 -- Effect on Miners

All Bitcoin users share the same mining network. How do sidechains
affect mining? 

First: by providing additional fees. By using *merged mining*,
miners can collect fees from all chains, for free. Merged mining
was invented by Satoshi in 2010, and has been in continuous use,
ever since Namecoin adopted it in 2011.
 
If fee rates remains low (under 1 USD per txn), then total mining
revenues can only increase, if the network processes a large
number of transactions. Indeed, Satoshi remarked: "I'm sure that
in 20 years there will either be very large transaction volume or
no volume." Merged mining allows miners to collect enormous fee
revenues, while keeping the L1 blocks small, and L1 validation
costs down. 

Third, the convoluted junk – [about some miners possibly exercising their free option to run (or not run) a subset of L2 nodes] – has no value, is misleading, and should all be deleted.

Fourth, if you want another interesting section, add something like this:

1. If sidechains are successful, then miners will collect billions of $ from them, as fees.
2. Therefore, sidechains will likely pay 99% of miner’s revenues.
3. As a result, miners may shift their focus – from L1 to L2(s).
4. Therefore, we want to explore ways of ensuring that the L1 chain is still venerated, in a world where most economic activity is on a higher layer.

Fifth, further clarity could be obtained, by emphasizing these true facts:

• We want miners to include every transaction (on all chains). Otherwise, that is censorship. Which is bad.
• We want different nodes to compete, on node cost. If a node is too expensive, it should have fewer users (and maybe even die off). We want to explore the full spectrum of decentralization, safely. We want users to complain about expensive node-costs. We want devs to have an incentive to keep node costs down.
• We want miners to compete (against each other), and we want lazy miners to be fired. We want miners to cut every cost that they can, and to grab every revenue they can. That is how we maximize proof of work; that is how we maximize hashrate (and 51% protection). Mining technology will be invented, at all “scales” (large and small) – this is perfectly fine.

Part 3. Emphasizing the Facts

I’m going to repeat myself yet again.

Truth 1: Miners Don’t Need Nodes

Miners do not need their own full node, to validate. Ever.

In the same way: I do not need my own cow, to drink milk. (For example, I can get my milk from someone else’s cow, or from a middleman such as a supermarket.)

Of course – someone has to have that cow! Milk has to come from somewhere! Yes! Therefore, it is reasonable for me (a milk-drinker) to ask about the milk supply chain.

In the same way, a miner (who benefits from sidechains) might ask is anyone out there running a node? They might ask about the L2 validation supply chain? What if one day there are zero nodes?

Miners should worry about that – since that’s their goose that lays the golden eggs. Miners can take any risk(s) they want, including: [1] relying on another’s node, [2] hoping there will always be nodes, or [3] (the opposite) mistakenly wasting money on a node that turns out to be superfluous and unnecessary.

Layer 1 users, do not need to worry. We aren’t drinking any “milk”. We never need to about the “zero cow” problem. After all, remember this: if a blockchain network has zero nodes, then it just stops existing. This leaves Bitcoin in the exact situation it is in today – with no sidechains. The L1 Bitcoiners are unaffected. So, either there are some nodes, or there aren’t. Either way the problem is solved.

Yes – we do need people to care about cheap full nodes (see “Truth 3”, below). But in this case, it is the ultimate distraction.¹

That should be enough!

But let’s continue to examine this issue, in exhausting detail…

Truth 2: Should we really coddle weak miners?

Let’s examine an extreme situation: an L2 exists, it pays lucrative fees, but it is on death’s door. It is about to die, because no one runs it anymore, due to its high node costs.

In this case, miners would be affected by the L2’s death. They may voluntarily vertically-integrate, to try to keep it alive.

This is a good thing, where miners are starting nodes of an L2 – to save that L2. Presumably, by saving the L2, they will prevent users from falling back to a custodial alternative. Yet – in the logic of Blockstream’s paper, this would (somehow) be a bad thing (ie, a “centralisation risk”).

The paper is also concerned with miner’s economies of scale.

Let’s return to the milk analogy. Milk is a physical liquid – but “L2 validation” is an electronic service. Producing milk for 8 billion people (and shipping it around the world), is a tall order. In contrast, “L2 validation” is easy to scale – miners just need a few relationships with trustworthy nodes. Those nodes can tell the miners what to mine – at near zero marginal cost. Miners can use multiple independent nodes (for redundancy) – and (of course) they can spy on each other. These are cheap and effective ways of getting L2-validation, without running a node.

Of course, without running their own node, miners risk being misinformed. With bad info, they might accidentally create an invalid block. If they did, they would lose a ton of money. This is a risk/reward decision each miner must make – no different than any other business decision (eg, about security guards, power racks, cooling equipment, ASIC-turnover, etc).

In addition to lighting their own money on fire, miners who accidentally produce an invalid block, may also temporarily mislead any SPV users who use this mining IP as their blockchain server. But SPV users are in the same category as SPV miners – they are also making their own risk/reward decision. First, they are taking a (tiny and microscopic) risk by using SPV, and furthermore they are taking a (bizarre) risk by connecting to only an SPV-miner as their source of new blocks.

Again, it is a good thing that we can cut these corners!

Imagine that 99% of the time, we could pull milk out of the air, for free, whenever we wanted. That would be pretty cool! (That would be an improvement over today’s world, where we cannot.)

But Blockstream’s paper sees it differently. It has a mysterious hatred of specialization (and of efficiency… and practicality) – it rejects these “clever” ideas, and instead aims for a Communist “blank slate” of fairness. (Meanwhile, they establish themselves as authorities on which sidechains are “centralizing” [and, presumably, therefore, which should not come into existence].)

Each miner is an entrepreneur. They must make their own decisions. One miner may specialize, perhaps. Another might do the reverse, and vertically integrate. Each miner bears his own costs and risks. And each reaps their own reward. Why would we want to try to micromanage this process?

In the long run, Miners must optimize for profits. So, they must cut every redundant cost – including nodes. If nodes are expensive and useless, then miners are prohibited from running them (just as they are “prohibited” from setting their ASICs on fire).

The simple truth is this: “Node costs” and “Mining costs” live in completely separate worlds.

Truth 3: Small Blocks = Decentralization = Good

These statements are true: We want cheap nodes. We want decentralization. We want small blocks (other things equal).

This is because every blockchain has a data availability problem: how much data is everyone responsible for broadcasting/validating/storing/serving ?

Or, as Wayne Vaughan put it: “Who pays for all of this?”, or, as I put it: “How much does it cost to run a full node”.

So, indeed: full node costs do centralize validation. But “outsourcing” does not.

An L2 may indeed be highly centralized. But it does not cause L1 to become centralized – it does not cause the mining network to become centralized. It does not cause other L2s to become centralized. They are not necessarily affected, at all.

Other things the same, smaller blocks are better than larger blocks. But with sidechains, other things aren’t the same. They are supposed to have some kind of new feature, which the L1 lacks. Users then choose the network that is right for them (and for their use-case).

Truth 4: Sidechain = voluntary blocksize increase.

The whole point of sidechains, is to create a “choose your own blocksize” situation. (Or, if you prefer, a “choose your own data availability problem”.)

You choose which network(s) you want to validate, and how.

The voluntary part is the whole point – as is the increase part.

The node costs have to go up – for the volunteers. The miners have to be enticed by the L2 fees. It’s inevitably linked to the sidechain idea.

Hopefully you now we see the problem with Section 4.3. It tries to say: “we want sidechains” – but then it says: “it is bad if some people process more data”. But the entire point of sidechains in the first place, is “some people voluntarily processing more data”.

I mean –after all– if we want more transactions, than at least someone has to be processing them! Surely, the ideal choice is the volunteers?!

Each new chain has its own node costs and its own benefits. That’s the point!

Truth 5: The “Scale” Argument is a Distraction

The scale argument is disingenuous.

First, it is always vague. You never see any numbers.

This is because – I mean – how high could node costs possibly be?? A Solana node (the most expensive I could find) has an “all in” dedicated bare-metal hosting cost of aprox $1000-$2000 per month. (Not including the staking cost.)

So – that’s (?!) what we’re complaining about?? $24,000 a year? That’s nothing! Bitcoin’s marketcap is 2 trillion dollars! And we want it to be two hundred trillion dollars! And we want the network to pay hundreds of billions of txn fees, every year.

It’s absurd.

Third, even that $24k cost is wildly incorrect. I personally have tested nodes [which can scale to 8 billion people], on hardware costing just a few thousand dollars per year. To say nothing of what will be invented in the future – nor of what would be invented, if Bitcoin became a global superpower (and/or if it became a problem for miners).

Fourth, at the exact same time Blockstream was writing this paper, they raised over 55,000 BTC. Today, that BTC is worth 5 billion dollars – enough to run a Solana-style “expensive” node for over 200,000 years. And – a year after that – Blockstream went on to raise even more money – 125,000 BTC! So – if Blockstream is genuinely worried – they can just vertically integrate and run these L2 nodes as a kind of charity! Jeesh!

The scale argument is a concern troll. It’s nonsense.

Miners can operate at whatever scale they want. Large or small. The optimal scale is set by a million factors – most of them out of our control. And there is plenty of room for different miners at each scale.

One Final Time

Mining costs (of all kinds) are always irrelevant, due to difficulty adjustment. They should never be mentioned at all. Mining costs can never be kept down – anyone who attempts this, is subverting proof-of-work and is an enemy of Bitcoin.

With respect to Node Costs, the paper should have just said: “a more expensive node” = “a worse user experience, syncing that node” = “a higher likelihood that the network dies off”. Then they should remind people that if a sidechain dies off, this does not affect the L1 chain or any other sidechains.

The Rest of the Paper

Unfortunately, the rest of the paper is also not good.

For example:

• Section 3.2 “Symmetric two-way peg” is a bad idea – the “asymmetric” peg is much better, and makes the sidechain into a true L2. There’s no reason to even mention this at all – it is distracting and confusing.
• Section 4.4 “Risk of Soft Fork” is also wildly confusing and self-contradictory – especially at line 370 and beyond. That also should just be deleted.
• Section 5 “Applications” is very uneven. It does not mention scaling bitcoin (the most important application), or governance (ie, handling disagreements among developers). It has a pointless digression about Freicoin.
• Section 6 “Future Directions” – none of these ideas are remotely likely to help.
• Appendix A – the “federated peg”. This is in the same category as “custodial lightning” – a fraud. (As some of them later admitted – to their credit.) It is like a “stair-based elevator”, or “human-operated driveless Waymo”. This idea confused people for years (and still does).
• Appendix B – This convoluted “skiplist” idea has never been used in practice, anywhere. As far as I’m aware, no one ever bothered to code it.

Is there anything good about the paper? Yes, we can credit it for popularizing the “sidechain” word, (and the “DMMS” concept). But in general, it causes much more problems than it solves.

Conclusion

Section 4.3 is terrible. Blockstream should either [1] formally retract it, or [2] totally overhaul it (edit it to replace it with something that makes sense).

In particular, everyone should clearly admit that:

• “The argument” [that sidechains “affect mining centralization”] was wrong (and always has been).
• Sidechains should instead be praised for [1] their harmlessness and [2] their beneficial effect on innovation, mining revenues (aka “security budget”).

Although the paper is 10+ years old, the misconceptions it inspired still haunt us today. This hurts the price of Bitcoin, and the viability of every mining company, Bitcoin startup, crypto-currency exchange, etc.

Footnotes