Bitcoin Forum

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 (https://www.youtube.com/watch?v=HapWHBCFd3c) (you can start the video at 3:00 for his solution).

Mr. Clif High is the creator of the web bot.

The web bot is an internet bot computer program whose developers claim is able to predict future events by tracking keywords entered on the internet. It was developed in 1997, originally to predict stock market trends.

The web bot works based on predictive linguistics. Predictive linguistics is the process of using computer software to aggregate vast amounts of written text from the internet by categories delineated by emotional content of the words and using the result to make forecasts based on the emotional 'tone' changes within the larger population. A form of 'collective sub-conscious expression' is a good way to think of it.

Predictive linguistics can be used to forecast trends at many different levels, from the detail of sales to individuals, all the way up to forecasts about emerging global population trends including Bitcoin.

You can see more details on his webpage including the Bitcoin price predictions, which you can analyze and compare for yourself over the past years.

https://halfpasthuman.com/

He was also featured recently at the cointelegraph based on his market predictions including Bitcoin, gold and silver, see below:

https://cointelegraph.com/news/bitcoin-price-will-triple-gold-in-2018-silver-achieves-parity-with-gold-clif-high

I am not a technical expert, so I can't verify how viable is that solution Mr. High tries to sold.
But the way he explained it, it wasn't that complicated, took him less than a minute to sum all up - so my question is:
if that is really that good, then why no one ever thought about it and I we don't see this concept of "Infinite Scaling" used by any cryptocurrency?

Scammer, fairy-tale writer.
If author is right describing his claims in his youtube video. Core developers will add this couple lines of code to make bitcoin scale infinitely.
Its just impossible. He is delusional, thats it.

No , he is not delusional.

He just found a different way.

Observe
BTC each of the below is a new 1mb block every 10 minutes
[1]
[1]
[1]
[1]

If I understand him correctly , he is saying
BTC with Lateral Block Scaling
[1]-[1]-[1]      (1 Main Block with 2 adjacent Blocks) (3 Times the Transaction Capacity)
[1]                (1 Main Block only , Normal Transaction Capacity)
[1]-[1]           (1 Main Block with 1 adjacent Block) (2 Times the Transaction Capacity)
[1]                (1 Main Block only , Normal Transaction Capacity)
[1]                (1 Main Block only , Normal Transaction Capacity)
[1]-[1]-[1]      (1 Main Block with 2 adjacent Blocks) (3 Times the Transaction Capacity)

Basically using the area of BTC where people store crap like text or graphics, instead make it where it can couple some additional blocks
So depending on the # of Lateral Blocks, you could directly scale when you needed too
In theory , it would be workable ,
In Practice, I'll let the programmers weight in on that.

 8)

FYI:
Imagine the Main Block as a Train, his idea just lets you add additional Train Cars , so you can carry more Transactions.
The empty space he mentioned would act as the coupler between the train & train cars holding them all together.
Pretty Creative Actually.  :)

Dont be fucking stupid. 

You can't get blood from a stone, there's no perpetual motion machines, you can't fold a piece of paper in half unlimited times, if a genie gives you three wishes, no you can't use one of the wishes to wish for more wishes, and you can't fit more than X bits of information into a space providing X bits of information. 

WE AGREE!  ;D

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.

This sound like magic.... and I think it is indeed magic! By definition, magic is "mysterious tricks, such as making things disappear and appear again, performed as entertainment."

So I don't think this suits scientific things like bitcoin.

It doesn't sound like magic at all to me. Maybe because I have some skills and experience in programming that I see it differently.

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.

No you are Misunderstanding him.

I hate to be the one to break it to you , his solution is ONCHAIN Scaling , why you are peeing in your pants over it is beyond me.
His way is not unlimited, but it would have the ability to scale up at time of heavy transactions and scale down when there are very few transactions.
Fact is we don't know what it's limits are , as no one has yet researched it. If they can have the adjacent blocks continue pass a main block, then his way would have a greater scalability than BTU. But at this point in time, it is unknown.

LN is Bullshit OFFCHAIN BANKERS Shenanigans , and people might as well just use Paypal as LN.
(Money probably safer with Paypal than LN (Know exploits to steal in their Whitepaper.)

If you are scared it will block BTU , get over it , BTU will be implemented.
But his idea should be studied as others may use it instead. And it may be possible to add it to BTU, since all of you BTC guys are afraid of a faster blockspeed.

 8)

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  ::)

@kiklo.

peeing my pants? lol...no.. OP asked for a detailed explanation.

Yes I realize its on chain... but if I am misunderstanding him then
what problem does his 'solution' actually solve?
 
no need for convoluted schemes.  just use bigger blocks.

Dear Dorky, it would be a good idea to first set up a team of open minded and bright programmers interested on this infinity scaling solution. Then, the team can contact Mr High directly, and ask him exactly what he means. I have contacted him before regarding the web bot ALTA reports, and he has been quite reachable and supportive within a 72 hours response by email.

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.

 8)

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.

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.

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.

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

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.

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

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

Very doubtful.

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

Reminds me of pseudoscience.

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.

Geez.  :P

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.


 8)

FYI:
Now a week of so later and everyone is claiming it as their idea first.  :P
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://bitcointalk.org/index.php?topic=283746.0

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.

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

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 ?

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

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

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.

 8)

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.

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

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/ (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

I agree ... reminds me "IPv4 address exhaustion" ( https://en.wikipedia.org/wiki/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 ;D )

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

But if it is not a miner, who will "broadcast" blocks B and C ?  Will this not be a cacophony of many people broadcasting many slightly different blocks B and C ?  Normally, only a miner can "broadcast" a valid block (everybody can claim to be miner and broadcast a block with wrong proof of work of course, but that's quickly discovered in the block header).  But who will broadcast blocks B and C ?

If it is the miner of block A, he's just cutting his big own block in a few pieces.


But who is broadcasting these non-PoW, non-PoS blocks ?  Every node ?


How are you going to be able to verify the gazillion of POSSIBLE and BROADCAST small blocks, while the miner of block A has just picked out two of them ?  

Suppose that the mem pool contains, at a certain moment, 10 000 transactions.  There are 5000 different ways to put 6000 of these 10 000 transactions into 3 blocks of about 2000 transactions each because there are 5000 nodes doing so, with slightly different mem pools (not sync of course).  So you receive 15000 blocks from 5000 different nodes.  The miner of block A has picked 3 of them, which he calls A, B and C.  You will indeed find, amongst the 15000 broadcast blocks, that one is block A, another one is block B and still another one is block C.  But if you don't have the time to verify the big block {A,B,C}, do you think you have the time to verify those 15000 blocks ??

I was going to say the same thing, for once I agree with Johnny

It's really scary, everything looks OK, but I'm concerned about its viability, that's just the theory, we need something more practical to prove. I look forward to a good result from his solution. Hope it will succeed. I am tired of seeing things that are theoretically small but weak in the present.

Yes, a "ExtensionBlockBitcoin" would not be the same than a "MainChainBitcoin". My understanding is, however, that the "peg" between these two varieties of Bitcoin could be easier to implement with extension/lateral blocks  than with near-fully-separated sidechains.

If the peg is working well then we could hide the functionality from the users (at least those who opt-in to it) in the clients - and for merchants, I think it would be a competitive disadvantage to not accept "ExtensionBlockBitcoins". So the fungibility problem looks solvable, for me - the "hard problem" is making the peg work.

Nope, only the miner that mined the main block would be able to broadcast the lateral blocks for that main block.
The Lateral or adjacent blocks would have to match a checksum included in the main block or fail inclusion into the chain.

 


Only the miner of the main block would be able to broadcast the lateral blocks and only for the block he mined the main one.





Only Block A requires Complete Verification, the additional Lateral Blocks are only accepted if they match the Checksums, listed by the verified block.

 8)

Looks like you are confused understanding what is really happening here, people want to be able to mine up to the 21M limit in a few years and not decades, problem isn't bandwidth and storage as mining is now specialized industry anyone wanting to start mining they'd need to invest large amounts so let them spend some on good internet and hardware but with the ASIC miners you'll only need one full node.

Problem isn't in the lack of space but how many transactions in size and how often (time between finding blocks) should be mined.
Unless anyone has any method/program/algorithm that could compress all sorts of signature versions/transaction data of normal addresses-multi sig addresses and reduce their sizes in order for miners being able to put more TXs in a 1MB of space, otherwise I suggested a mining mechanism where all the miners point their hash power and then mine 1 block exactly every 10 minutes and that would be a huge pool with no orphan blocks/aborted blocks/rejected blocks and also that would mean no more lottery for each miner trying to win=much easier and people will be able to mine with one tenth of the electricity and that could potentially affect the price in a negative way.

ok this is how i see it
https://i.imgur.com/djz2ikJ.png
We already know that whatever is in purple gets hashed. And that the hash is thrown to ASICS to make a more secure hash with a bunch of zero’s at the start
there are [80bytes of data]  that is unused in a block..

---

https://i.imgur.com/QpqRszE.png
now imagine that we used that 80bytes for something as simple as a signature(sidehash)..
more precisely a signature hash of data signed by the pools own chosen coinbase(reward) keypair.
and then hashed the same as before.

now you may well be asking what 'message' could that signature be part of

---

https://i.imgur.com/ylGthLn.png
the message could be a cluster of tx's and a signature belonging to another previous cluster of tx's.. and so on.. and so on

---

so how would it work.
https://i.imgur.com/I07by2y.png
well imagine every second new tx's are signed into a cluster (extended block) by the pool making the main block

so timeline, using just 3 clusterblocks/extended blocks for example
previous block solved. Previous block hash is added to the new block aswell as 2500 tx added to the new block.
2500 tx added to sideblockA and signed as A by that pool
2500 tx and signature A added to sideblock B data and signed as B by that pool
2500 tx and signature B added to sideblock C data and signed as C by that pool
sideblockC signature added to block and the block is hashed and PoW’d as usual all within the same 10 minute window

---

possibilities, because signatures are involved. clusters/extended blocks can be signed once a second, meaning it can make 600 cluster/extended blocks to allow a tx to get semi confirmed in second of being seen by a pool.
yes them 600 clusters instead of 1 extended block may have a 42-48kb extra bloat(600 signatures), but then you gain the feature of 1second semi confirmation instead of just extra tx per single block waiting 10 minutes for a confirm.

issues:
there are 20+pools
so your TX might be in cluster/extended block antpool: 350 of the 600 blocks signed by antpool
 or 123 of the 600 blocks signed by bitfury
 or 500 of the 600 blocks signed by btcc
all because in the 600 seconds between mainblocks each pool has their own 600 cluster/extendedblocks and tx arrangement that pool has solely/independently chosen
resolution:
user receives atleast 20 pool responses that the users tx is in a cluster/extended block somewhere in each pools

issue:
this then causes alot more data flying around the network of 'soft confirming' 12,000 cluster/extended blocks (20 pools*600cluster/extended blocks each)

issue:
logical minds will think screw it lets make it 60 clusters/extended blocks with a 10 second semi confirm. practical minds then argue that although 10 seconds is better than 10 minutes. there is still 1200 extended blocks flying through the network. and 10 seconds is now slower than visa's 'touchless' NFC swipe and go payment method.

my opinion.
1. just using 1 extended block that can hold an infinite amount of tx's is a way of 'going soft' with dynamics. but then the nodes should have a dynamic useragent flag that pools find a consensus of nodes of, to know how many tx's should be put in this extended block where it wont cause issue to the majority of nodes.

2. by using it to also 'speed up' the confirm by having MULTIPLE extended blocks signed every second/10seconds/whatever.. is better than wrecking blockrewards/difficulty/halving schedules like some other lame proposals of just reducing the 10min average to 2minutes, 1min, 30seconds. but again nodes will need to have rules of acceptability to keep pools inline so that pools do not overdo it.

i could continue waffling on, but ill stop here for now

Well, then he could just as well make one big block, instead of splitting his one big block he's alone in deciding about, into several small ones.
 

So he's just putting what he'd put in one big block, in several smaller ones.


Of course not. There are two "levels" of verification: "header verification", and "full transaction consensus verification".

Let us not forget what is the PURPOSE of a block chain: coming to a consensus of *transactions*.   You want to know whether a given transaction is part of the past consensus, or not, because the validity of a new transaction depends on that.  It is the only reason of existence of a block chain: knowing on what set of past transactions, there is consensus.

You can check the validity of the block headers: that makes you know that:
1) the header fits in correctly in the chain
2) it has the right amount of PoW

By verifying only the headers, you can verify the block chain structure, and the Merkle tree hashes included in them.  But you don't know anything about the consensus of transactions this chain is supposed to bring you.

In order to know that, you have to know the transactions themselves.  They need two verifications:
1) the validity of the transactions themselves, for which you need previous consensus knowledge: that is, what previous transactions did we agree upon ?  They provide the outputs that can be used as inputs in a valid transaction.
2) their inclusion in the consensus the miner decided upon.  You combine their hashes into a Merkle tree, and you verify whether that Merkle tree hash corresponds to what is in the block header.  If it fits, ALL of them are OK, if it doesn't fit, the block including its block header, is false.

But if you need to know this, you need to know ALL THE SIDE BLOCKS and verify all of them.  It is sufficient that one single transaction in block C doesn't work, and your block header is, in the end, false.

==> there is no conceptual difference between verifying block A only, or not verifying any block.  It is A,B and C or nothing. 

Because a smart guy could include a transaction in block A, but "screw up" block C.  If that's the case, block A is just as invalid as if, in a normal chain, the block itself were false.  If you ONLY verify block A, and you think it is OK, and you accept the payment, then if it turns out that block C was erroneous, your block A is JUST AS FALSE and your transaction will not be part of consensus.  The block header will turn out to be false, after all, just as if you included a double spend or a wrong Merkle hash in today's chain.

Verifying ONLY block A doesn't verify anything: if block B or block C are false, this invalidates the block header, and hence also block A.

There is really no difference between putting all these transactions in one big block or making all these "clusters".  Note that as long as a pool hasn't built all his clusters together, it CANNOT START HASHING on the main block, because it doesn't know the final signature to include.  In fact, the "list" of signatures is more wasteful than the "Merkle tree" hash or signature that is used within a big block.  So from the miner's PoV, there is no difference between making his list of linked clusters, to include the final signature into his block on which it will start hashing, or to make one big block with a Merkle tree of hashes (his list is just slightly slower).

The "signatures" of the pools are absolutely no guarantee that the whole series will not be orphaned if another pool wins the main block.  And, as you point out, not only do the individual transactions fly through the network, but all the *different versions of clusters of all pools* fly through the network with their signatures.  That is a large multitude of traffic as compared to one big block.  The factor is the number of competing pools (not only the big ones !).  So if you see a transaction flying by, and there are 30 mining pools active, you will see 30 different miner clusters containing this transaction fly by within a second or so...  You will see this transaction 30 times, you will have to check the validity of 30 clusters, and finally, only one of them will make it as the 25th cluster in a row by a given pool that won the race for the main block.  And maybe it is a main block that doesn't, finally include that transaction in one of its side clusters despite the 29 signatures you saw, because these 29 pools that signed it, didn't win the main block.

Essentially, if there are about 30 active mining pools, the spent bandwidth is multiplied by about 30 as compared to a single big block.

to put them into 600 clusters allows for 'semi-confirm' of 1 second. instead of waiting 10 minutes. drawback is the user needs to see 20 different signatures (from all the pools)

i explained this already...!


yep again i explained this already
it would be signing clusters of fresh transactions so by the time its validated a previous main block to know what tx's that were in mempool already, to add to the new mainblock it would have already also/separately grabbed a whole load of tx's that are fresh to put into clusters.
ive explained this already...!


yep again i explained this already
1 extended block vs 600 clusters = 42kb-48kb of signature wasted. but to users its a 1second confirm feature


again i explained this..
issues: '12,000 cluster/extended blocks (20 pools*600cluster/extended blocks each)'


wow you waffled a paragraph to repeat what i said and all you done was change the number 20 to 30..
yep i explained it..

issues: '12,000 cluster/extended blocks (20 pools*600cluster/extended blocks each)'

but its good to see you have a critical hat on. but your just repeating what i already said.

Then you are just doing a kind of "20 masternode scheme" of DASH, with the "pools" electing themselves as masternodes.
This is nothing else but the instant pay mechanism of DASH, with informal master nodes instead of protocol-defined masternodes.
In other words, bitcoin then has 20 certificate authorities, signing the validity of transactions.

Once you do that, why not simply use PoS ?  Why waste electricity on mining, if you trust miner signatures ?  They could simply sign off the main block too, in a PoS scheme, instead of wasting electricity on PoW !


Ok, sorry, I misunderstood your post as "being in favour" of this scheme, while it is a total clusterfuck concerning bandwidth etc...

If 8 MB blocks are a "bandwidth issue", then 20 times the block size is most probably a "bandwidth issue" !


However, what is positive in these discussions is that people are slowly, very slowly, discovering that:

1) PoW is a bad cryptographic protection

2) a block chain is way too much severity of consensus (we don't need the EXACT ORDER of transactions)

3) signatures of different entities can validate transactions much better/cheaper/faster than by putting them into a block that needs PoW protection.

In other words, that most of the principles of bitcoin are, well, improvable.  Which is no surprise because it is the oldest, and very first tech that is used.

1. PoW has nothing to do with blockchain size. a 1Kb block or a 1Gb block both result in a 256bit hash.
PoW only needs 256bit hash, and doesnt care about blocksize. (hint: you wont see a hard drive in an asic)
its about timing

2. you do. to then have a checkable history by just knowing the latest contains data of the previous. thus no need to constantly be checking everything, because the previous is locked.

3. and as we both pointed out signatures of different pools become troublesome of users seeing 20+ pools all with different signatures, plus to offset things like propagation.. the timing of signing then becomes less instant to give room for the network congestion to breath.
which then brings back the issues of "but its not fast enough if your waiting 1mb-10min in a grocery store checkout line hoping a confirm happens soon

I wasn't making that remark in direct relationship to the current subject.  PoW is bad cryptographic security, because the "good guy" doesn't have any advantage over the "bad guy".  It is simply the one that wastes more that wins.  I only mentioned it because digital signatures do have the advantage that PoW doesn't have: the one with the secret key can easily sign, and it is essentially practically impossible to imitate such a signature if you don't have the key.


I'm not saying that a block chain is "not good enough".  I'm saying it is way too severe.  You don't NEED full block chain ordering in order to verify transaction validity.  It is much harder to come to "exact order consensus" than it is to come to "correct transaction set consensus".  The order is not needed.  If you have a consensus on a BAG of valid past transactions (no matter what is the order), that's good enough to find out whether a newly proposed transaction is valid or not:
1) do all inputs correspond to an existing output in a transaction in the bag ?
2) do none of these inputs appear in any existing transaction input in the bag ?

That's all that is needed.  No order needed.  In the bag, or not in the bag.   Mathematically, you only need the SET of transactions, you don't need the sequence.  But of course a sequence is (more than) good enough.  But it is a complication that is not needed.


Indeed, the "solution" in this thread doesn't bring any solution to any serious problem, but adds problems.

you really need to step back and really understand bitcoin
hashpower alone is meaningless.. it doesnt matter if one pool has 50000 exahash and another pool only has 50petahash.

the nodes will reject whatever block doesnt follow the rules.

yea the pools can play with themselves all they like but the nodes are what consensus agrees as what is acceptable
blocks get rejected many times a week it doesnt matter if the pool has 1% of the hash or 16% of the hash.. a bad rule breaking block is still a bad rule breaking block


your thinking more about how centralised banks work. EG only needing the UTXO set to act as bank account balances.
but thats backward thinking of the old world of fiat.
please move passed the centralist mindset of fiat banking setups and grasp the decentralised diverse symbiotic relationships of a peer network.
i know you find it complicated. but thats the beauty of its security. it cant be messed with that easily if no one has control.

stop thinking that bitcoin needs to be controlled and that once controlled bitcoin doesnt need the chain.. otherwise you might aswell just go play with fiat banks.

bitcoin is different, diverse, decentralised for good reason. please learn it.


it add potential new features.. but agreed there are far more issues that this threads 'proposal' has not counteracted.

Maybe you can ask Clif High to join this forum, review comments in this thread, and give his feedback.

Sure, and if there are no other blocks available, then those nodes just stop working.  The point is that blocks that are made by the "bad guys" follow the rules perfectly and in PoW, the rule is then that the bad guy wins.  The rule in PoW is that someone with sufficient hash rate can undo all the transactions of the 50 last blocks, by just presenting an alternative chain with more PoW than in these 50 blocks.  The rule is to orphan the "good" 50 last blocks. 
If all miners now decide to follow the rule (what else could they do ?), and build only upon the chain (the bad guy chain) with most PoW, then that's the only chain that is available.  If your node doesn't agree, then your node will simply stop.  I've been explaining this 50 times to you, but you don't want to understand this, because you are stuck to the myth that non-mining nodes have power.