Topic: A proposal for a scalable blockchain. - page 2. (Read 6232 times)

Perhaps some terms are confusing.

A visualization of the idea:

Balance Block 0 (Anchor hardcoded into application)
+---------------------------------+
|Genesis Balance Sheet Hash   |
+---------------------------------+

Balance Block 1
+---------------------------------+
| Previous Balance Sheet Hash |
+---------------------------------+

Balance Block 2
+---------------------------------+
| Previous Balance Sheet Hash |
+---------------------------------+

Balance Block 3
+---------------------------------+
| Previous Balance Sheet Hash |
+---------------------------------+

Balance Block 4
+---------------------------------+
| Previous Balance Sheet Hash |
+---------------------------------+

Current Balance Sheet
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
|  Bitcoin Address | Balance Value |
+------------------------------------+
^
All known bitcoin addresses, possibly only those with balance value above zero.

Clients only need the most recent balance block to participate. Older balance blocks can be used to check historic data.

(The transaction block chain keeps existing to stabilize the balance sheet, which will be considered stable after 1000 or 2000 blocks, the transaction block chain can later be thrown away up to the most recent/current balance sheet, or it can be stored for checking/verification purposes at the expensive of more harddisk usage, up to user/application to decide.)

The real question is why not ?

You can change the balance, but it will not be accepted by other clients, because your balance would be a mismatch.

The mismatch can happen in two ways:

1. The traditional way by: length wins, which is what bitcoin does.

2. The voting way: confirmations.

An attacker could create a fake balance chain, which could be longer, and broadcast it to you.

However this should not happen because of majority of processing power, so majority has ultimately longer balance chain.

Unless you are disconnected from the real network and you connect to a fake network, and you cannot connect to real network, same problem as with transaction block chain.

Other attacks could exist too.

The hashes in the balance chain also protect against modifications, make a single modification and you will have to find a hash collision, or re-do an entire fake balance chain which becomes computationally expensive. A balance chain might not even be necessary. Only one balance sheet needs to be stored the previous one. However balance sheets could also function as checkpoints, but that's probably not necessary.

My suggestion was also to make the difficulty 1000x greater than the blockchain, if the blockchain is allowed to be 1000 blocks ahead, if this leads to 1000x hash search times remains to be seen, maybe it will become too difficult, examination of this idea will have to be done.

So the concept of a balance-chain could be dismissed, instead a single balance sheet is stored by all clients.

It could be considered a "sliding balance sheet". It slides along the transactions over time.

However if the concept of a balance chain is dismissed, then the race can no longer happen, nobody wins.

This becomes a problem, there is no winning selection criterium anymore, except perhaps the voting situation. Though that's a bit shakey.

Therefore the idea could be simply:

Store the hashes of the balance chain only.

The balance sheets themselfes are thrown away, except the last one.

At least this makes it possible for people who have all transactions and know exactly when to calculate a balance and a balance hash to check the chain for consistency.

This also preserves the proof-of-work idea.

An attacker would have to re-do those balance chain hashes, computationally expensive.

It's even very interesting, since an attacker might not have the necessary data to make the balance chain.

Therefore attacker is restrained to new data only, less attack surface for him. This would be a lazy attacker, however it's good to assume default intense attackers which have all data.

By storing balance chain hashes only, the old transactions can be thrown away, the old balance sheets can be thrown away, what remains are the balance chain hashes, about 256 bits per hash and a recent balance sheet.

So why should we trust a balance-blockchain? Should we also have a balancechain for that, and then another for that?


Humor me. Please explain.

The balance-blockchain (=ledger-blockchain ?) would work the same as the transaction-blockchain.

The concept of a blockchain can be applied to anything.

This includes all the blockchain-mechanisms for rejecting and accepting, etc.

This should not need to be re-explained.

Perhaps the proposal of the original/first poster is weak/insecure or worriesome.

My slightly different proposal is to make a seperate balance-blockchain which should be stronger... assuming the original/first proposal is rejected because of security concerns or incomplete proposal.

I'd like to hear objections or security concerns against my proposal the seperate balance-blockchain.

Skybuck, Gavin is not saying you should trust anybody. Can you provide a link where Gavin talked about balancechain?

Nothing is stopping you from trying to make it coherent.

Let me/us know when you figured out how to make it coherent ?!?

This is kinda funny.

So on one hand/side you consider a blockchain safe ?

But on the other hand/side you consider a balancechain to be unsafe ?

You can't have it both way ?!?

The only difference so far is that the blockchain is anchored into the application and fully available vs throwing information away, but what remains could be anchored as well so not much difference there ?!?

Though how important such an anchor is remains to be seen ? Perhaps it's not important and can be worked around ?!?

If it is important then maybe a balancechain anchor could be build in as well ?

Either the bitcoin is flawed or it's not, which is it gavin ?

Ummm, yes.

It seems to me miners will have an incentive to lie about the transaction ledger, and put fake ledger hashes in their blocks. Either so their transactions might be considered 'unspent' by unsuspecting nodes that trust them, or so that other miners that don't have the full block chain create invalid blocks (eliminate the competition!)

And I don't see a proposal that everybody check the ledger and reject blocks that contain invalid ledger hashes.

I also don't see what the ledger hash accomplishes.  If you're going to trust some other node's version of unspent-transaction-reality, then you could just ask "send me the ledger state before (or after) the block with THIS block hash".

But if you're going to trust one or more nodes anyway... then it seems to me sending an ever-increasing-in-size ledger is a bad way to get scalable. If size-of-full-blockchain becomes a problem before the mining pools and big exchanges/merchants/transactions processors all have transaction processing clusters with a terabyte of ram and petabyte hard drive array then I think extending the protocol to make it easy to request all transactions involved in a given Merkle branch will probably be the way to go.

But before then I expect the bitcoin network will look very different from the way it looks today, and I expect there will be several different solutions for how to scale up. If (when!) Bitcoin gets that successful, there will be serious money hiring the same smart people who figured out how to scale up PayPal and Visa.

It's worth noting that this method would reduce block validation time considerably, something which merkel pruning would not help with. I agree that there are better optimisations that can be implemented first but I still think it might be worth discussing for the future. Can you see any obvious flaws in the proposal Gavin?

As Mike said, help on "initial headers-only download" would be much appreciated.

Work-in-progress is here:  https://github.com/bitcoin/bitcoin/tree/blockheaders

... and my notes on issues that have to be worked out are here:  https://gist.github.com/1059233

As for scalability in general:  it looks to me like CPU time to validate transactions will be the bottleneck before bandwidth or disk space, so I don't see a strong reason to switching to a 'ledger' or 'balance sheet' method. Effective optimization/scalability is all about identifying and eliminating bottlenecks.

Namecoin is icky 

Seriously, I think it won't be in the long run and can be addressed in future core development. For the time being focus should be on useful things.

If you agree that the current limitations on growth are software performance related (and not exchanges or economy size or whatever) then there are plenty of simpler optimizations that don't require protocol extensions, which still aren't implemented. That'd definitely be the first thing to think about. Gavin is planning to work on the most important of these, but I'm sure he'd appreciate help. Otherwise you could contribute to MultiBit/BitcoinJ which already implement a form of lightweight mode.

What is the maximum theoretical bandwidth of fiber optics? Unknown. Scalability problem will be solved through hardware in the short term, Bitcoin core development in the long term.

Not really, the balance chain would be something extra.

It could even start locally for each client without any additional protocol, a balance chain protocol could be added later on.


I don't see how it would be incompatible since bit coin addresses start with a balance at 0.

Instead now bit coin addresses can be at an arbitrary value, which is validated by the balance chain, and thus inputs and outputs could be resolved up to that balance value ?!? So instead of solving it to 0, it is solved to balance value.

If you believe otherwise, then please try to explain why this would not work, or where problems/incompatibilities would be.

+∞^∞

Explosive growth in Bitcoin use = explosive growth in Bitcoin value. Internet speed and storage space are growing exponentially. As Bitcoin grows in value, miners with full clients will be connected to fiber optic networks operating at multi GB speeds and everyone else can use lite clients. There is plenty of time to explore other options.

Disclaimer: I have no idea what Im talking about.

With that out of the way, would it be possible (or even a good idea) to have all clients store the most recent blocks + a random subset, say 5% of the blockchain? The entire network would still hold countless copies of the blockchain, and as the network (and blockchain) grows you could reduce the subset each client has.

You can prune all the spent outputs and mine away. What you can't do is run a lite headers-only node to mine— unless you just want to mine for the subsidy and not process any transactions. Though with a commitment to open transactions in the prior block, you could mine txn which provide the connecting fragments for the prior block for all of their inputs.

One hundred years of headers is about 400 mbytes of data.

Why are you wasting our time with this drivel?


Superior versions of what you're describing have been suggested before: https://bitcointalksearch.org/topic/merkle-tree-of-open-transactions-for-lite-mode-21995

I say superior, because arranging the ledger summary into a hash tree allows nodes to participate without even knowing the complete ledger— other nodes can present ledger fragments to them with the branches which connect the ledger to the tree root— and the whole ledger is constantly current. Bytecoin went further and suggested that you can actually flip the direction of the chain and track the ledgers alone, leaving the coin holders to track the fragments connecting their own coins to the chain.

But none of this is required because of block header sizes.

interesting

I've modified to the original proposal to simplify to process of generating a ledger.

I don't believe the merkel tree pruning proposal by Satoshi is workable. If a client cannot validate blocks then it cannot be trusted to have any network participation.