Clif High's solution for Bitcoin to scale to infinity.

[Dorky]

What makes linking blocks like this any different to a larger block? All these blocks need to be propagated across the network. All the transactions in these blocks need to be validated.

I believe Clif High's solution involves blocks that are already validated, and using these validated blocks, laterally, to validate a new yet-to-be-validated one.

So every block has it's own sidechain?

I have no idea. Maybe Clif High can visualize his solution for us to understand. But then he said that the programmers would understand what he says. I don't know if anyone here is an expert programmer or a programmer that works directly in Bitcoin development.

[Dorky]

What makes you think after all the money and time invested into SegWit that the Core Dev's will even worry about considering this? They are pushing their own agenda and BU dev's are doing the same. It is not about the better solution any more, but rather who will be in control of the experiment. < power grab >

More smaller blocks = Bigger blocks 

I understand. That's the main problem with humans in general.

[dinofelis]

The ways to increase Onchain Transactions Capacity.

1. Increase Blocksize
2. Faster Blockspeed
3. His way creating a lateral chain, like a train with cars.

This is nothing else but unlimited blocks, except that you cut them in sideways blocks. 

It seems that people talking about all this forget why there is a block chain in the first place: the reason is that you need to make sure that there aren't double spends and "first rights to spend".  That's all.  You need to have a global consensus on the list of past transactions that do not contain double spends, to be able to reject any future double spend, and the list of "permitted first spends" (coinbase).  It is the *only* thing that you really need.

The block chain is a kind of over-severe way to do so, where the EXACT ORDER OF EVERY SINGLE transaction is graved in stone.  That's not needed.  You only need an "ever-growing bag of transactions that are not double spends and that are permitted first spends".  They do not need to be in order.  This is the big error of the block chain concept: there's no need for transactions to be ordered !

The only thing that you need, is a consensus on the bag of transactions.  So that when a NEW transaction is proposed, you can verify whether it is permitted as a first permitted transaction, or as a first spend of a former transaction in the bag, without there being another transaction of the same kind already in the bag --> the order doesn't matter, the PRESENCE only matters.

IF the new transaction is OK, it can be put IN THE BAG, and one needs to come to consensus again that this transaction can be included.

The only "consensus resolution" is needed if there is an attempt at double spend, because then one needs to decide which one can be included, and which one not, and come to consistent consensus over this decision.  It is the ONLY problem that needs to be resolved.

But whether you organize that bag as an ordered list, or as a kind of tree, or whatever, doesn't matter.  However, this re-organization doesn't alter anything, nor to the amount of data, nor to the actual consensus problem.

[Dorky]

It would be great if the Core and Unlimited developers give their comments on Clif High's solution.

At least then we will know:
1. If the developers understand what Clif High meant.
2. If his solution is really viable.
3. That the developers care about Bitcoin development.

If the developers are silent on this, then it may mean the complete opposite of the 3 points above.

[Xester]

Ok, so there is a person name Clif High that recently made a Youtube video on how to scale Bitcoin to infinity.

In the video, he suggested the developers to look into this 83 bytes in current block structure that can be easily used for iterative processing, laterally, and literally achieve infinite scalability for Bitcoin.
We don't even need Segwit, nor Lightning Network, nor Bitcoin Unlimited, for fast confirmation.
Everything still stays the same while just adding some lines of code (no alteration) and we would probably have a Bitcoin on hyper steroid operating at high speed, with low fees, surpassing Visa, adoption increasing exponentially, skyrocketing Bitcoin price, and creating a new generation of young multimillionaires and multibillionaires.
We would put to rest the issue of scaling once and for all, and probably never need to bother about it ever again.
I wonder why are the developers not looking into this potential solution.

Link to the video is here ---> https://www.youtube.com/watch?v=HapWHBCFd3c (you can start the video at 3:00 for his solution).

This is a great news and if it is functional then we only need to convince the miners to use this kind of code rather than making changes on the system and experience conflicting ideology from different groups causing complications on the network. There are three things why the developers have not acting on this suggestion, first is they did not notice it, second is they found it applicable to the system and third is that they will not achieve huge profit if they use this code.

[paul gatt]

Any solution should be reviewed and approved by professionals who are good at it, so they will have the right idea about it, and hopefully it will be a good solution. I waited for the results from the experts, I believe in them, I dislike seeing the bitcoin branched out, it was really bad, the bitcoin was growing, and suddenly slowed down by greed Of the miners. How bad, and now, bitcoin is being competed by the altcoins

[Yogafan00000]

Very doubtful.

Where are all these extra lateral blocks going to be stored?

Reminds me of pseudoscience.

[BillyBobZorton]

Cliff High is a bit insane and I don't think you can predict the future analizing keywords, and it's just ridiculous that he can make predictions like he does, he said $30,000 is coming this year or something.

[kiklo]

Very doubtful.

Where are all these extra lateral blocks going to be stored?

Reminds me of pseudoscience.

Geez.  

You never use a Spread sheet Before?

Block #52652 A   |   Block #52652  B   |   Block #52652  C
Block #52653 A
Block #52654 A
Block #52655 A   |   Block #52655 B

They would be stored in the blockchain like the rest of the blocks.


 

FYI:
Now a week of so later and everyone is claiming it as their idea first.  
http://www.coindesk.com/purse-proposal-touts-extension-blocks-bitcoin-scaling-solution/

Purse Proposal Touts Extension Blocks as Bitcoin Scaling Solution

FYI2: Oldest Reference so far : August 29, 2013, 04:10:56 PM
https://bitcointalk.org/index.php?topic=283746.0

Auxiliary block: Increasing max block size with softfork
I just realize that the 1MB block size limit could be increased with a softfork. I call it auxiliary block:

1. An auxiliary block is created for each main block. Auxiliary block looks like a traditional block without the header.

2. OP_NOP1 is redefined as OP_AUX

3. Initially, auxiliary blocks are empty, until someone sends X bitcoin to a scriptPubKey of this format: <serialized script x> OP_AUX. This will create a coinbase-like transaction in the auxiliary block, with X bitcoin sending to <deserialized script x>. The Merkle Root of the auxiliary block will be included in the coinbase of the main block. All upgraded nodes will check whether the bitcoins are correctly transferred from the main chain to the aux chain

4. People can transfer aux chain bitcoins like in the main chain. Miners can also collect fee in the aux chain using the same mechanism as the main chain. The only difference is there is no generation bonus in aux chain. New aux coins are generated if and only if someone send bitcoins to <serialized script> OP_AUX in the main chain

5. When someone want to transfer Y aux coins back to the main chain, he will send Y aux coins to a scriptPubKey of this format: <serialized script y> OP_AUX OP_RETURN. Seeing this, the miner will randomly choose some OP_AUX UTXO in the main chain, with value exactly equals to Y bitcoins, and pass them to <deserialized script y> in the main chain.

Backward compatibility:

1. Since old nodes will not see the aux block, the aux block could be indefinitely big

2. The OP_AUX outputs look like anyone-can-redeem so old nodes won't complaint.

3. If some try to steal these OP_AUX outputs without following the new rules, however, they will be rejected by the majority of miners.

4. Old nodes can still mine. As long as they are not trying to include or redeem OP_AUX transactions, their blocks are still valid.

(More extremely, we may disallow people transferring aux coin back to the main chain by requesting them to send bitcoin to <serialized script x> OP_AUX OP_RETURN on the main chain. This will provide better backward compatibility since such outputs are not redeemable in both new and old nodes, and old miners would see these as non-standard and won't mine them)

[Dorky]

Now a week of so later and everyone is claiming it as their idea first.  

It is precisely because human nature is generally such, that Bitcoin is NOT a work of "Satoshi Nakamoto".


It is simply beyond human nature to promote Bitcoin as Satoshi Nakamoto's work, and give all the credit to him.


Only thru concerted and organized effort by a very powerful group of people can push Bitcoin to the level of exposure and success that it is in today.

[dinofelis]

Very doubtful.

Where are all these extra lateral blocks going to be stored?

Reminds me of pseudoscience.

Yes, there is strictly no difference between making one larger block, or making *several* side blocks having to be signed off by the "main chain block".   This is nothing else but unlimited block size.

But it is smart propaganda.  As BU now has a bad name, we call it "sidewise blocks". 

[dinofelis]

Very doubtful.

Where are all these extra lateral blocks going to be stored?

Reminds me of pseudoscience.

Geez.  

You never use a Spread sheet Before?

Block #52652 A   |   Block #52652  B   |   Block #52652  C
Block #52653 A
Block #52654 A
Block #52655 A   |   Block #52655 B

They would be stored in the blockchain like the rest of the blocks.

Tell me, do blocks B, C etc... also come within the same 10 minutes as the A-blocks ?  Do they also have block rewards ?  Do these rewards increase bitcoin's inflation ?

If yes --> Mwhahaha

If no -->
Who mines them ?  Does block A have to certify (Merkle of blocks ?) blocks B, C etc.... and hence "wait for them" ? Is there only one miner of blocks A,B and C, namely the one mining block A and getting its rewards ? What's then the difference if the one mining block A is also including the transactions of B and C into block A ?

[K128kevin2]

Is a homeless guy living in the back of a van really better than all of the minds behind Bitcoin?

[eddie13]

I could see this working if block A only had to store the hashes of aux blocks B and C D E and on, it could verify all of that extra information but not store it.
But, don't all of the transactions have to be stored so the balances of addresses can be known and can be known if they have something they can then spend, or are the hashes enough?

On a block explorer I imagine it would look like TXs disappearing into thin air but then you could spend them as long as your new TX was in agreement with the hashes?
Maybe the other aux blocks transactions could be stored off chain for reference purposes (for balance lookup, explorers) and store just the aux blocks hashes in the master block A in the blockchain for immutable verification?

I don't really see it as being any better than BU if you still have to store all of the complete aux blocks on the blockchain taking up space..

Is a homeless guy living in the back of a van really better than all of the minds behind Bitcoin?

A lot of incredibly intelligent people are eccentric, a lot of people choose to live simplistically, such as in a van, for purposes of freedom and travel, if a person can get passed their addiction to material belongings and value life experiences over stuff.. Maybe he would rather see the world than own a bunch of things, maybe he simply has property where he has all of his things to go to when he wants..

[kiklo]

Very doubtful.

Where are all these extra lateral blocks going to be stored?

Reminds me of pseudoscience.

Geez.  

You never use a Spread sheet Before?

Block #52652 A   |   Block #52652  B   |   Block #52652  C
Block #52653 A
Block #52654 A
Block #52655 A   |   Block #52655 B

They would be stored in the blockchain like the rest of the blocks.

Tell me, do blocks B, C etc... also come within the same 10 minutes as the A-blocks ?  Do they also have block rewards ?  Do these rewards increase bitcoin's inflation ?

If yes --> Mwhahaha

If no -->
Who mines them ?  Does block A have to certify (Merkle of blocks ?) blocks B, C etc.... and hence "wait for them" ? Is there only one miner of blocks A,B and C, namely the one mining block A and getting its rewards ? What's then the difference if the one mining block A is also including the transactions of B and C into block A ?

Since no one has wrote the code yet,
Just my speculation:
Block B & C would be broadcast as quickly as possible, so in the same 10 minute window.
ZERO BLOCK rewards for the lateral Blocks, however the Miner would receive the transaction fees for the additional blocks.
1 Miner for each Block #, and the A,B,C or more that follow

You are correct , 1 large block A could contain B & C

Difference is you have to verify the block, so doing it Clif's way means you can validate a smaller block faster, and only use the lateral blocks when the it is full of transactions. The Additional blocks would be more important , if they can run past the next main block that is found .
Meaning someone tries to spam the network, and a main block plus 20 lateral blocks, eats up the entire spam attack,
and then the next block is only 1 main block again.

Single Large Blocks can also adapt , but usually BTC miners are not lowering the blocksize now, even  when they include only 1 transaction.

At some point the larger blocksizes would not be able to be verified in the time before the next block, therefore limiting the maximum size.
If the additional lateral blocks can run longer than the 10 minute window to the next main block, they can exceed the scalability of the Larger BlockSizes, by only having to verify the Main block, you never hit the verification limit.

All theory until someone writes it.  
We are nowhere near the max blocksize limit, so this technique would not really be needed for ~5 to 7 years.
Also the increases from just speeding up the blockchain are being ignored by the current dev teams.
Plenty of transaction capacity to squeeze out of the blockchain before this would be required, but one day it might be the last option, for Onchain scaling.

 

[DooMAD]

Very doubtful.

Where are all these extra lateral blocks going to be stored?

Reminds me of pseudoscience.

Geez. 

You never use a Spread sheet Before?

Block #52652 A   |   Block #52652  B   |   Block #52652  C
Block #52653 A
Block #52654 A
Block #52655 A   |   Block #52655 B

They would be stored in the blockchain like the rest of the blocks.

If this proposed "solution" is just extra blocks at the same time, it's no different to an increase to the blocksize.  Nodes still have to store and relay the additional data.  Blocks B and C still take up space in terms of storage and bandwidth.  If anything, it would use up fractionally more space than a flat increase to the blocksize because there would be a few extra block headers to store.  If Clif High's idea is another variant of Extension blocks or Auxiliary blocks, then that's different, but it's not exactly a new idea, as you said.  The downside with that sort of idea is that it raises questions over fungibility in that coins aren't equal and identical if they are stored in two different varieties of block.

[Dorky]

Clif said (in my own words) in his video that his solution applies to (preceding?) blocks of the exact same size and structure.

[Andre_Goldman]

Cliff High is a bit insane and I don't think you can predict the future analizing keywords, and it's just ridiculous that he can make predictions like he does, he said $30,000 is coming this year or something.

Actually 'Machine Learning'¹ (and Sciences in general is all about to make predictions, testing hypothesis, etc )

I think a new version of his 'keywords prediction' software could be adapted on top of these deep learning frameworks like Caffe, CNTK, TensorFlow, Theano and Torch ...  for instance you can visualize words proximity using word2vec² http://projector.tensorflow.org/

But I wonder a code to cryptographically bind adjacent blocks fitting into 83 bytes ...


1 - Machine Learning as a subfield of AI that concerns about make predictions from the data (Statistical Learning).
2 -> word2vector - Distributed Representations of Words and Phrases and their Compositionality

[Andre_Goldman]

Very doubtful.

Where are all these extra lateral blocks going to be stored?

Reminds me of pseudoscience.

Geez. 

You never use a Spread sheet Before?

Block #52652 A   |   Block #52652  B   |   Block #52652  C
Block #52653 A
Block #52654 A
Block #52655 A   |   Block #52655 B

They would be stored in the blockchain like the rest of the blocks.

If this proposed "solution" is just extra blocks at the same time, it's no different to an increase to the blocksize.  Nodes still have to store and relay the additional data.  Blocks B and C still take up space in terms of storage and bandwidth.  If anything, it would use up fractionally more space than a flat increase to the blocksize because there would be a few extra block headers to store.  If Clif High's idea is another variant of Extension blocks or Auxiliary blocks, then that's different, but it's not exactly a new idea, as you said.  The downside with that sort of idea is that it raises questions over fungibility in that coins aren't equal and identical if they are stored in two different varieties of block.

I agree ... reminds me "IPv4 address exhaustion" ( https://en.wikipedia.org/wiki/IPv4_address_exhaustion ) ... Also reminds me "Colored Coins" ( build new tokens from the dust, All we are is dust in the wind )

[wck]

I will appreciate it (I am sure anyone with large savings in Bitcoin will too) if someone can explain how + why Clif High's solution can/cannot work, instead of outright saying it can/cannot.
At least I would like to see the details of how and why it can/cannot work, instead of an opinion.
Clif High developed his own spider to scout the entire web universe for collective human sentiments for prediction and many of his predictions came true so I don't assume him to make flimsy suggestion on solving Bitcoin scaling issue.
I assume he knows what he is talking about.
The only thing left is if he's right, then we need to lay out a plan on how to make it possible with his concept.
His solution has nothing to do with perpetual motion machine or free energy for nothing (so please don't make the stuff up or make accusation).
I think his solution has to do with parallel programming or multithreading on the block chain numbers to solve the next block, but this is just my interpretation.

Ok, I actually watched the vid (at least the part you referenced)

He is misunderstanding the problem.  

The problem is not how to organize the data structure.
If that were the issue, then what he is saying would be fine -- you could have 'slave blocks' or 'ancillary blocks'
that are pointed to by the main block.

You still have to process all those blocks.

When people talk about scalability challenges in Bitcoin, they mean:  How do we deal with all the storage requirements, the bandwidth requirements, the propogation requirements, etc.
As the network grows to accomodate greater transaction volume and a bigger blockchain, these requirements also grow.

So whether its all in one big block or in a master block with a bunch of slave blocks, well you still have to propogate that data, you still have to process that data, you still have to store
that data.  There are more efficient ways and less efficient ways to do those things, but nothing he is saying is providing a way to "scale to infinity", or give a huge increase in efficiency.

The lightening network is a huge increase in efficiency because it moves things off the main chain into bidirectional payment channels on a different network.  Aside from
something radical like that, the main scaling improvements will come as technology gives us faster internet and cheaper hard drives, stuff like that.

Hope that helps and makes sense.

Very clear explanation!  Now if only people will listen to what you are saying.