Bitcoin Forum
May 24, 2024, 12:13:25 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: On the History and Feasibility of Sidechains as a Scalability Option  (Read 498 times)
benjamindees (OP)
Legendary
*
Offline Offline

Activity: 1330
Merit: 1000


View Profile
June 26, 2015, 08:39:06 PM
Last edit: June 26, 2015, 09:48:37 PM by benjamindees
 #1

I think it's time to have a little discussion about the origins of Sidechains, and to dispute a claim made recently by a certain core developer that they have no application to Bitcoin scaling.

This post was prompted by a thread here regarding the claimed origins of Sidechains and their relation to Mike Hearn's Lighthouse.  I'm going to lay out an argument that this claimed history is not entirely accurate, and perhaps some of you can see how the Lighthouse is relevant to the discussion.

There has been a noticeable PR push over the past several months by Blockstream employees to make the claim that Sidechains 1) were the sole idea of Adam Back (aside from the attributions in the whitepaper itself, of course) and 2) are not useful for scaling Bitcoin.  This is hogwash, as far as I'm concerned.  And it needs to be disputed not only in the interest of historical accuracy, but for the good of the Bitcoin community.

Several years ago, I made a thought experiment.  I asked myself "what is the best way to use Bitcoin as a true local currency, in an isolated community with poor internet access, especially once it has begun to scale to accommodate millions of users?"  Based on Satoshi's original plan of scaling up the block size, this would be a difficult task without relying on SPV wallets, which some consider flawed.  But I decided there should be a way to do so, even with some limitations, and that perhaps these limitations could even be engineered to have economic benefits.

The result of this thought experiment was Bencoin.  Bencoin was simply a method to deposit Bitcoins, off-chain, with a trusted third party representing a separate more localized economy, while still being able to withdraw them at will.  It represented a middle-ground between the then-common practice of trusting a third party with deposited Bitcoins, and using the blockchain directly for everything.  It was basically a low-trust, rather than zero-trust or full-trust, method of handling Bitcoins off-chain (and thus scaling Bitcoin), without the limitations and costs imposed by tracking large blocks.

It did, however, still have other drawbacks.  So I never pursued it beyond the proof-of-concept.  Instead, I began thinking of ways to deposit Bitcoins somewhere else -- not with a third party, but on the blockchain itself.  I started looking into the nLockTime feature, and eventually developed the first native Bitcoin Bond, locking Bitcoins on the blockchain in a way that they could not be spent by a trusted third party without the authorization of the depositor.

This represented an improvement over Bencoin.  The fundamental improvement of Bencoin was that Bitcoins deposited with a third party could be withdrawn at any time by the depositor alone, but the drawback remained that they could still be taken by the trusted third party.  With the Bitcoin Bond, locked Bitcoins can still be withdrawn (after a specified time) by the depositor, and *cannot* be spent by the third party without authorization of the depositor.

All of this was done in public, and is documented in various places on the Bitcointalk forum and the #bitcoin-dev IRC channel.  All of it occurred long before Blockstream was even a glimmer in its founders' eyes.  And the short leap from Bencoin to Bitcoin Bonds to one-way pegged Sidechains is, I think, obvious.

So, knowing this, I found it somewhat interesting when a lot of other history and precursors were mentioned in the Sidechain whitepaper, yet none of this.  I found it only mildly disturbing when the similarity was flatly denied by a Blockstream employee, having been pointed out to him on Reddit when the original Sidechains whitepaper was released.  But, now, I find it outright insulting that Blockstream seems to be engaged in a publicity campaign to downplay the capabilities of "their own" invention.

In fact, it's almost as though Blockstream would rather seize control of this idea and keep it for themselves, instead of allowing for the possibility that the scalability benefits of Sidechains or similar be opened to the entire Bitcoin community.  I'm beginning to think that may actually be what's going on.

Now, I'm not going to argue that Blockstream's proposed implementation of Sidechains is the best option for scaling Bitcoin.  It may not even be a good option, as is.  But it, or an idea like it such as Extension Blocks, is a valid option that should not be brushed aside based on the claims of a single developer that Sidechains have nothing to do with scaling.

These claims are wrong, at least, and disingenous, at worst.  The actual history of Sidechains' precursors is that they have a lot to do with scaling.  And there are likely several ways to implement them in order to enable Bitcoin to scale in a flexible and completely voluntary fashion.

If anything, I hope this post will at least convince you to question the claim that Sidechains or similar have nothing to do with Bitcoin scaling, or are not even a valid option to be considered in the scaling debate.

In an attempt to avoid any coordinated or future censorship, I've also posted a copy of this to Reddit.

Thank-you for your time.

Civil Liberty Through Complex Mathematics
Lauda
Legendary
*
Offline Offline

Activity: 2674
Merit: 2965


Terminated.


View Profile WWW
June 26, 2015, 10:06:53 PM
 #2

I guess we are never going to see an end to this scalability debate just because people are too stubborn. I'm going to thank you for clearing some thing up, I did not even know about Bencoin.
Another problem is that many do not even understand how they're supposed to work and have yet participated and mentioned them in several discussions.

I do wonder why there were rejecting the increase in block size so badly and now they're saying that their own "solution" isn't the right way? It's possible that they're trying to make it look like Blockstream wasn't the main reason for the dismissal of Gavin's proposals? There's definitely a hidden agenda on both sides, however I'm not yet sure what they are.


This might be a bit off topic, but I would like to hear what you think of the Lightning Network?

"The Times 03/Jan/2009 Chancellor on brink of second bailout for banks"
😼 Bitcoin Core (onion)
jonald_fyookball
Legendary
*
Offline Offline

Activity: 1302
Merit: 1004


Core dev leaves me neg feedback #abuse #political


View Profile
June 27, 2015, 03:18:35 AM
 #3

Huh??  I thought the core devs at block stream were so against hearndressen's big blocks because they thought side chains were the answer?  now you're saying they think sidechains DONT provide scalability?

johnyj
Legendary
*
Offline Offline

Activity: 1988
Merit: 1012


Beyond Imagination


View Profile
June 27, 2015, 01:57:27 PM
 #4

Raised level of complexity will reduce the people's understanding thus give less community support

JohnnyBTCSeed
Hero Member
*****
Offline Offline

Activity: 882
Merit: 1000



View Profile
June 27, 2015, 05:07:52 PM
 #5

I think we need to inject the term " companion chain" into the debate.

A companion chain could be thought of as what the supernet project is trying to accomplish, dif chains working together.

However i think an equaly interesting approach could be bitcoin and ixcoin and namecoin as companion chains.
The later two are merge mined, have a hig hash rate, in ixcoins case it is a copy of bitcoin so the code has the same security as bitcoin, these are both well distributed, and ixcoin has ended its minting period.

I mention ixcoin not so much as an endorsement but to point out that it meets severeal of the points the blockstream guys make for sidechains.

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!