With "Balance sheets" most of the block chain can be forgotten.

[ByteCoin]

I acknowledge that eurekafag posted before me about a similar idea in http://bitcointalk.org/index.php?topic=473.0

In the near future there's a decent chance that BitCoin will be run on mobile phones and used as a substitute for cash and cards. The main barrier to adoption will be that while the block chain is not ridiculously large, it's larger than it needs to be and as the rate of transactions ramps up, it's going to get larger faster.

Also, people are already annoyed with downloading the whole block chain and hacks have sprung up to get around this. This shows that it's already a problem and it's just going to get worse.

When we're calculating a balance we're not interested in the detail of transactions that happened a year ago although the block chain will happily tell us. We just crunch all this data to work it out. Let's say that a "balance sheet" is a sorted list of all public keys with positive balances followed by the amount of BitCoins they have received. When any block is published we should all be able to calculate identical balance sheets.

I propose that the hash of the balance sheet for block n be hashed into block n+1.  When a new client starts up, unless they're interested in all the historical detail they ask for the current block and balance sheet. In my other suggestion, block numbers are tied to times so, if the client knows the time, they know which block number to ask for. They work out how paranoid p they are. They then ask for the previous p blocks. Using the current balance sheet and undoing transactions they recalculate the previous p balance sheets and they check that the hashes match the blocks. They are then up-to-date and can make transactions and participate in block generation if they wish.

If p is chosen to be at least twice as large as the number of blocks required to make a transaction to go confirmed then the scheme is at least as secure as any normal BitCoin transaction.

Similarly clients could keep a historical balance sheet and reclaim the disc space taken by all the preceeding blocks.

The size in bytes of the balance sheet has to be considerably smaller than that of the block chain. Could some kind person please calculate the current size for me?

In order to keep balance sheets small we could agree to omit from the balance sheet keys "containing" small amount of BitCoin but this sophistication introduces some complications.

The cost of my proposal is one more hash field per block. It would save a lot of network traffic from nodes getting historical blocks, a lot of storage space and a fair amount of users time.

I imagine that this scheme is superior to the Merkle hash tree, which could be dispensed with for some considerable saving in code complexity.

ByteCoin

[1713311079]

1713311079

[1713311079]

1713311079

[1713311079]

1713311079

[Bitcoiner]

Subscribed; definitely something to debate. Even on the pc, downloads will eventually reach an unwieldy point. It's an inconvenience to first timers even today. This could also help with privacy if it "flattens" the older transactions.

[FreeMoney]

Similarly clients could keep a historical balance sheet and reclaim the disc space taken by all the preceeding blocks.

It all sounds good, but this especially.

[r!chb]

Long time lurker first time poster:

Seriously - can someone either shoot this down or acknowledge that there is some validity to it? The block chain is a barrier to many things, new adopters, mobile applications - basically the things that will help BC grow...

The paranoia metric 'p' method as proposed gives an elegant trade off.

This goes hand in hand with the method for guaranteed time length blocks.

Would be good to see at least some debate

Satoshi... any comments?

Rich

[knightmb]

Seriously - can someone either shoot this down or acknowledge that there is some validity to it? The block chain is a barrier to many things, new adopters, mobile applications - basically the things that will help BC grow...

New Adopters can be solved with preloaded blocks in the install like I have for download here http://knightmb.dyndns.org/files/bitcoin/

Mobile clients would just be "terminals" to servers that are already running the full software that keeps up with the full block chain. No different than a credit card processing gateway.

Many solutions to these have already been discussed and others are working on them as I type.

[r!chb]

Doesn't this create the role of a payments processor? Or 'terminal' - the current strength of the system is that we all participate as potential payments processors if we generate the block. Creating a market niche for a trusted terminal provider (who would guarantee they'd get your transactions into the block chain, have up-time, not be compromised etc.) breaks away from that model.

I accept your point that you can just add the entire block chain to the download, it just seems a dead-weight. It's a question of mathematical certainty versus real world pragmatism - at some point a transaction is confirmed enough for me to send you the goods you bought - 'p' blocks... if that's enough history for us to do business - for me to risk my livelihood - then why is my standard of proof any different elsewhere?

Either way - thanks very much for replying to me. Nothing's ever as black and white as it looks at first!

Rich

[Quantumplation]

I like this idea, though I can't figure out how to work it in without making it a breaking change... It could be incorporated pretty easily as a breaking change, but breaking changes are difficult in a distributed system... The "new" software would look like a vagrant and be pretty much inoperable (it would see everyone else as "hackers") until over half the people updated.  Until then, everyone else would see the newer software as a "hacker", and both groups would reject eachother's blocks, resulting in a bifurcation of the block chain.  Then, old->old transactions would be lost. to the "newer" split blockchain.

[Bitquux]

A mobile device can just connect to a web interface for your wallet that sits on a home computer (or router). The block file on that server will still get huge, but you don't have to tote it around with you.

[Anonymous]

A mobile device can just connect to a web interface for your wallet that sits on a home computer (or router). The block file on that server will still get huge, but you don't have to tote it around with you.

Cant mybitcoin just provide an interface for this?

[Bitquux]

Cant mybitcoin just provide an interface for this?

If the site works on your mobile device (should for most), they already do.

[Red]

I like this idea, though I can't figure out how to work it in without making it a breaking change...

If the balance sheet referenced the block, instead of the block referencing the balance sheet, then you could probably implement this system without breaking existing nodes.

Newer nodes would send the balance sheet in a separate message from the block. it would only ask for the balance sheets from nodes of the appropriate system version.

But I could be talking out of my ass too. ;-)

[eurekafag]

The idea is nice, however there may be flaws. I don't know exactly how coins are generated, are the numbers produced checked against previously generated coins? Is there a possibility to generate a coin twice if you don't have the whole chain? Anyway, something like this (snapshotting/sheets) should be implemented or we eventually get this chain grow like cancer. This will push away newcomers.

Everything in p2p is based on majority trust, so if most of clients create equal snapshots (of small size, of course), newcomers would trust it and assume the proof-of-work was done honestly. We even can delete the whole chain leaving only the snapshot after some time. If we do the sheet every 10k blocks, newcomers would download up to 9999 blocks, about 3 blocks/sec so it will take less than hour to start. Pretty acceptable I think.

[Quantumplation]

I like this idea, though I can't figure out how to work it in without making it a breaking change...

If the balance sheet referenced the block, instead of the block referencing the balance sheet, then you could probably implement this system without breaking existing nodes.

Newer nodes would send the balance sheet in a separate message from the block. it would only ask for the balance sheets from nodes of the appropriate system version.

But I could be talking out of my ass too. ;-)

Perhaps.  If it was a whole-nother "layer" on top of the existing algorithm, it'd definitely work.  And, you wouldn't have to worry as MUCH about the security of each balance sheet, because it's more of a shortcut anyway.  Anyone really worried can always fall back on the block chain.  Likewise, if someone every once in a while double checks the sheets vs the block chain, they can start "blacklisting" them, letting everyone know they're bad.  Or something.

[Gavin Andresen]

I think this won't work because there is not a one-to-one relationship between "unspent transactions" and public keys.

Example:  I start with 0 BTC.  Two people each send me 50, to the same receiving address "GavinPubKey".

Balance Sheet:  GavinPubKey: 100
I spend the first one:
Balance Sheet:  GavinPubKey: 50

If I'm dishonest, what stops me from waiting a few months and then spending that first 50 again instead of spending that second 50?  Double-spending that first 50 will look like a perfectly valid transaction to any nodes using the balance sheet method who weren't around to see the first time I spent it.

[Quantumplation]

gavin: The balance sheets are meant for more lightweight things.  If you run in "balance sheet only" mode, it allows you to get a quick glance at it, and operate with people you trust.  You trade at your own risk while in this mode.  If you're distrustful, make sure you're checking the whole block chain.  The balance sheets AUGMENT, not REPLACE the core functionality.

[eurekafag]

If I'm dishonest, what stops me from waiting a few months and then spending that first 50 again instead of spending that second 50?  Double-spending that first 50 will look like a perfectly valid transaction to any nodes using the balance sheet method who weren't around to see the first time I spent it.

Aren't those first 50 coins will be tracked and bound to the reciever address hence shown in the balance sheet? Everyone could check whether this particular 50 coins were given to anyone or are still yours. If I understand it right, balance sheet is generated from the existing chain so if at the time when you want to doublespend the balance shows these coins assigned to anyone else your transaction won't be accepted.

[Quantumplation]

eureka: No, the balance sheet is very lightweight and only stores balance, not actual coin ownership.  Though, that would be one way to solve that, is to store all 21,000,000 coins (identified by the hash of the block they were generated in) under the address they're "owned" by.  It'd be bigger than the chain is now, but it'd still be significantly smaller than the entirety of the block chain.

[joechip]

eureka: No, the balance sheet is very lightweight and only stores balance, not actual coin ownership.  Though, that would be one way to solve that, is to store all 21,000,000 coins (identified by the hash of the block they were generated in) under the address they're "owned" by.  It'd be bigger than the chain is now, but it'd still be significantly smaller than the entirety of the block chain.

Uniquely identifying each bitcoin is a very good idea.  Think of them then as separate claims of property, like lots of land.  By doing this and keeping track of who owns which one (or fractional bit thereof) would add a tremendous amount of trust to the system. 

I'm not at all savvy vis a vis the programming logistics (eeek, run away), I'm more interested in the monetary theory, so salt all comments to taste.

[Quantumplation]

eureka: No, the balance sheet is very lightweight and only stores balance, not actual coin ownership.  Though, that would be one way to solve that, is to store all 21,000,000 coins (identified by the hash of the block they were generated in) under the address they're "owned" by.  It'd be bigger than the chain is now, but it'd still be significantly smaller than the entirety of the block chain.

Uniquely identifying each bitcoin is a very good idea.  Think of them then as separate claims of property, like lots of land.  By doing this and keeping track of who owns which one (or fractional bit thereof) would add a tremendous amount of trust to the system. 

I'm not at all savvy vis a vis the programming logistics (eeek, run away), I'm more interested in the monetary theory, so salt all comments to taste.

*nods* It wouldn't be a reliable way to operate the underlying system, as coins are split and merged in blocks, 50 are generated at once, etc, but it'd be a nice way to provide a bit of verification and safety to the balance sheets.

[Red]

Upon reflection the ByteCoin's original proposal to link to the balance sheet from the block seems better, since the blocks are the canonical source of validation.

It appears at first glance that the serialization code provides for software versioning so adding a field has hopes for not breaking previous versions.

For any given block, any client should calculate the same balance sheet and the sorted sheet would reproduce the hash listed in the authoritative block.


Gavin is right about the current need to tie and validate transactions to prior transactions rather than bitcoin addresses. However, for me that is a bit of a non-feature. Interestingly, while generating the balance sheet, the node could generate (unsigned) merging transactions and insert them into the block. Merging transactions could be deemed valid if all inputs and the output went to the same bitcoin address. That would certainly break prior clients though.