Topic: Clif High's solution for Bitcoin to scale to infinity. - page 2. (Read 3519 times)

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.

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.

 

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..


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..

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

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 ?

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". 

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.

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/

FYI2: Oldest Reference so far : August 29, 2013, 04:10:56 PM
https://bitcointalksearch.org/topic/auxiliary-block-increasing-max-block-size-with-softfork-283746

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.

Very doubtful.

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

Reminds me of pseudoscience.

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

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.

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.

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.

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

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.

So every block has it's own sidechain?

Yes, I have actually done so. I've emailed him on this matter. Somehow I think we need a 3rd team for this. But I believe Mr. High is competent enough to go solo if he so chooses. And I will be very glad to participate as an investor in his proposal.

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.

Edit:
What he may mean is that we try to validate a new block (at a particular level) with all the blocks that have been validated at one level higher before it. Maybe all these blocks that have the exact same block structure are somewhat connected serially (no idea about that) along with 80 free bytes and this connection can be used for multithreading to "unlock" the new block.

The blocks used for validating a new one are already propagated. Or else they will not be used, as I understand it.

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.

I am not saying his way should be used over increasing blocksize, there is no time for anything but increasing blocksize in BTC.
However Adjacent Blocks tied to the Main Blocks may hold some potential that BTU might want in the Future also.
Maybe these adjacent blocks contain something else beside BTC transactions and increase BTC Utility usage . Time will tell.