Topic: With "Balance sheets" most of the block chain can be forgotten. (Read 22533 times)

And how can you be sure that bitcoins in wallets that you created for your kids education will be valid in the future?

Thank you theymos for taking the time to criticize the scheme in some detail.


After a new block is found the balance sheet is recalculated (possibly incrementally) and the hash of the balance sheet is encoded in a special transaction that serves to encode the data which is then broadcast round the network the same as a normal transaction. This is done by exploiting the broadband subchannel in ECDSA mentioned in another post of mine. There are some details to be fleshed out such as "who generates this balance sheet hash transaction" and "how do you cope with a malicious balance sheet client supplying incorrect data" but I believe there are multiple adequate ways of addressing these problems.

Thanks for supplying some real numbers. I'm afraid that "balance sheet" is not really an accurate description of what is stored. See
We need to store enough information about all the transactions which credit an address to allow appropriate references to those crediting transactions to be recorded in the transaction when you spend money from that address. It's like the stubbing-off-merkle-tree-branches idea in the white paper except that the stub hashes don't need to be stored and neither do the blocks. I doubt at the moment the "balance sheet" idea would save a significant amount of space but that's because Bitcoin is so thinly exchanged. As the fraction of spent transactions rises, the storage savings of the balance sheet method become more persuasive.

I'm not quite sure what you mean. I think this is the same objection that gavinandresen raised earlier in the thread in response to me misunderstanding exactly how transactions worked. After he put me right I changed the scheme. After reading my reply, if you're not satisfied, please explain the problem with my scheme in more detail.

Isn't it true that when you download the block chain you process it all in the current scheme? It seems to be that your criticism is more appropriately leveled at the current scheme because new "balance sheet"-using clients download the current credit list from other similar clients. The client then updates the balance sheet with all the incoming transactions to stay in sync. No processing of spent transactions ever takes place.

I'm not sure what you mean by a "parallel network" or why it would be necessary. I believe it would use the current network, as a "balance sheet"-using client looks, to the network, (mostly) like the existing client. You can't however download the older portions of block chain from it as that's data it has "forgotten". You are right in thinking that the "balance sheet" scheme becomes unmoored from the root hash. You are correct in thinking that this is a problem which needs to be addressed and I believe that my scheme can offer roughly equivalent security guarantees to the current scheme but the details are complex.

Implementing "balance sheets" without altering the current protocol is rather complex and that makes it unattractive. However I believe that Bitcoin will have little choice but to either change the protocol or to move to a client implementation in which nobody remembers all the transactions, such as "balance sheets". There's nothing stopping a small group of people spamming the network with transactions possibly encoding the latest Lady Gaga video or child pornography etc. As a method of storing data on the internet for free it has the benefit of designed-in complete permanence, distributed reliability and plausible deniability. Before becoming bandwidth or CPU limited I believe that the block chain+transaction data could grow at about 30TB a year with the rate only increasing. This is going to exclude the vast majority of people from running full clients. Either Bitcoin would have to give up the p2p label or it's going to have to start forgetting old transactions. Of all the ways of doing the latter, "balance sheets" is the best.

ByteCoin

The simplified payment verification system is already in place. The Merkle root required for its functioning is included in all blocks. Blocks do not include the hash of a balance sheet.

The size difference would not be significant. SPV is ~80 bytes per block plus 32 bytes per transaction, whereas balance sheets would be 20 bytes per unique address. Currently there are 132415 unique addresses in the system and 134267 transactions. SPV: 11.29 MB; balances: 2.65 MB. This is assuming that balance sheets will not have any header-like overhead, which they almost certainly will.

SPV looks through the Merkle tree to get the number of confirmations and prove that transactions and their prev_outs were not double-spent. This is the point of SPV. How would balance sheets solve this? If you're just going to download the most recent 5 blocks or whatever (an insecure method), why even have balance sheets? You can't generate with balance sheets, as you are unable to verify referenced signatures.

Using balance sheets with the current system would require receiving and processing every transaction ever made, which will become difficult as the block chain grows. SPV requires no such processing, and the amount of data stored on disk is the amount received through the network.

A balance sheet system written from scratch would not be any better than the current system. Generators need to know the contents of every non-spent transaction, so a parallel network similar to the current one would have to be kept. Clients would need to download every block header (as in the current system) because the current block with the balance hash can only be verified if you have every block in the chain.

We should not modify a software protocol just to allow it to fit to particular devices.  For mobile devices, a connection to a distant machine is good enough.   Isn't that what "mobility" is about ?


I don't know.  But I guess there is a difference, since the bitcoin client has a -server option.


As I said, this has already been addressed in Satoshi's white paper.  The solution is to use Hash trees, and it seems efficient enough.

Satoshi already addressed the issue of the size of the block chain in his white paper (http://www.bitcoin.org/bitcoin.pdf).  I'm pretty sure it will never be a real problem.

Idea sounds interesting, but I'd like to hear satoshi opinion on this very much.
Satoshi, where R you ?

The core bitcoin network should remain how it is. The core network should not be concerned with helping ordinary end users run lightweight clients. The core network should always remain as simple and lean as possible, staying within the theory laid out in the white paper, nothing more, except for fixing real bugs and security holes if they are discovered.

As was said in an earlier post, the balance sheet functionality can be layered on top of the existing core network. Clients in balance sheet mode can connect to each other on a second network to exchange information that relates blocks to the balance sheet. Older, ordinary clients will not need to know that this other network exists.

Using the same definition, "Balance sheets" is essentially done as well! 

ByteCoin


PS

The current Bitcoin client has the undeniable advantage of existing.

Neither the lightweight whitepaper client nor a "balance sheet" based client exist but both are compatible with the current protocol.
They are therefore equal on that basis.

I contend that a "balance sheet" based client is superior in every other practical way to the lightweight whitepaper client or the current client. If it were implemented correctly, it would be superior to the current client. If a new Bitcoin-like protocol were correctly  designed and implemented with "balance sheet" and other improvements in mind then it would be superior to the current protocol.

This is essentially already done. Bitcoin uses a hash tree structure for transactions that makes it possible for nodes to:
- Do everything except generation by downloading just the block headers and Merkle tree for each block, which is a tiny amount of data.
- Discard outputs that have been spent (referred to by a later transaction), even if you're a generator.

Neither of these are actually implemented yet, but the system of capable of doing it.

You could even generate while running in header-only mode (using getdata messages to get transactions you're missing), though the entire network could not do this.

Thank you for rejuvenating an old thread! I'm glad you're taking an interest and you have strong opinions but there's no rationale in your post which would cause anyone to take them seriously.

Why would it not make sense for a mobile phone application to have essentially the same functionality as a full client? All the clients being the same simplifies interactions.

You seem to be making a distinction between a Bitcoin 'client' and a 'server'. What's the difference?

There are three resources which could possibly limit Bitcoin's performance: CPU, storage and bandwidth.
Let's say 1MByte per second of uncompressible incoming transaction data which needs to be recorded in the block chain.
This is a high but plausible bandwidth requirement. It might result in 10k per second ECDSA verifications which is again high but plausible in today's multi-core world. However the block chain would grow at a terabyte in under two weeks or over 30 terabytes a year which strikes me as implausibly large. This makes me think that the size of the block chain will be the first hard limit to be reached.

Do you still think it's not an issue?

ByteCoin

Mobile phone application won't have to be a full bitcoin client nor server.  It wouldn't make much sense.

It would be much simpler for mobile phones to use a service such as mybitcoin, or to connect via ssl to a Personnal Desktop.

I don't think the size of the block chain is an issue.  At all.  I don't care if it bothers some users.  Some people will always be unhappy about something.

Please don't touch the protocol.  It is fine as it is right now.

That is not going to happen though.

Your anonymity is not good if it relies on other people forgetting things.

Let me clarify...

I'd like it if EVERYBODY forgot the old transactions. It doesn't make much sense from an anonymity perspective for just some people to forget them.

And yes, I understand Merkle trees. It's a nice feature.

This "Balance Sheet" concept does not need to be separately implemented.
You can already forget as many transactions as you'd like.
It is covered in section 7 of the whitepaper pdf.

(And you actually only need to remember the 'TxOut' portion of any transaction.)

Either way you'll have to store about the same amount of data.

Ok, I was again thinking of RSA. For this type of public key crypto it's true, you have relatively little control over the public key value. Of course if I generate a large number of public keys I could perhaps end up with about 16M =2^24 keys each with a different 3byte pattern encoded at a certain position. It would take a transaction with 11 receiving accounts to encode a 32byte hash of the balance sheet. 65536 different public keys would need 16 receiving accounts per transaction.

Of course, when you do a transaction you're just sending it to a public key. Nobody checks whether anybody has the private key so if you don't mind wasting 0.01BTC per block then you could encode two hashes in one transaction if you wanted as the public key takes 64 bytes. 50BTC would last you a bit over one month. The money would of course be completely lost. I believe you could encode arbitrary data into the block chain at a cost of 0.16BTC per 1024 bytes. Or about 312k for 50BTC. This data would live forever in servers round the world under the current scheme.

The benefit of the balance sheet is that you only have to receive it once when you need to sync back up if the size of the blocks you'd need to process to get back up to speed is larger than the balance sheet. Once you're up-to-date you keep the balance sheet updated in memory as the transactions go through and you just check that the hashes in the block chain agree with the hash of the balance sheet in memory.

So basically the balance sheet is never sent out unless you ask for it. Similarly at the moment the entire block chain is not sent out with every new block but it is sent out if you ask it to be when you start a new client.

ByteCoin

I like the balance sheet concept because it allows the network to forget most of the historical transactions. That suits me fine.

It is worth pointing out that the balance sheet associated with a given transaction block, will very likely be much larger than the transaction block itself. It is much smaller than the entire block history, but that is a one time transmission cost. A balance sheet would be recurring.

If you generated one balance sheet a day, or week, then wiped previous blocks that would suit me fine.

I don't think that's how public keys work.  You can't arbitrarily choose a public key, it has to be generated in a very specific way, paired in a very specific way with a very carefully chosen private key.

I just had a bit of a brainwave as to how we could implement "balance sheets" as a non-breaking change.
Presumably when you generate a new address you have, if you want to exercise it, complete control over what the public key part looks like.

I take the hash of the previous block's balance sheet and split it into chunks. I make new public keys that contain these chunks of hash as parts of the public key values. I make a small transaction of 0.01BTC from a fixed address to each of these new hash-chunk-encoding public keys as soon as I have calculated the hash of the balance sheet. Each of these 0.01BTC accounts has about a month to "live" before I transfer the money back to the fixed address. If I did this earlier then in theory, the information could be at risk from the Merkle tree branch pruning.

Modified, clients using the balance sheet method would of course treat the transactions as valid just like all other valid transactions but they look out for all transactions signed by the fixed address as encoding balance sheet hashes. If, as well as storing the balance sheet hash, the transactions encoded an IP address of a "balance sheet server" then new clients would know where to go to get it.

As an aside, BitCoin is a great way to record arbitrary information permanently. One problem is that it thinks that the marginal value of thousands of people's disk space is zero.


ByteCoin

I'd just like to clarify that "balance sheets" as I outlined them were not "lightweight things" designed to augment the existing system. In order to make balance sheets reliable, the balance sheet hash needs to be included in the block chain as explained. This is a breaking change, so there's no incentive to hold back from other beneficial breaking changes.


You start off with 0BTC and one person sends you 50BTC. So there's a transaction in block x which they've signed and your public key is marked as the recipient.
Someone else sends you 50BTC.  So there's another transaction in let's say a different block y which they've signed and your public key is marked as the recipient.
Next you want to send 50BTC to someone else. Now with a bank there's no concept of where the money has come from, it loses all it's identity when it hits your bank account. Not so with BitCoin! A new transaction (apart from coin mining) has to refer to one or more transactions in the block chain which resulted in a credit to you. So when you talk about spending the first lot of 50BTC the new transaction would refer to block x and if you wanted to spend the second it would refer to block y. I presume the choice is made for you by the current software and the user does not have any input.

So to correct my balance sheet idea in one fashion, as well as the balance for each individual public key, the balance sheet would also have to keep enough information about the blocks which contain the transactions crediting the public key to enable references to those crediting transactions to be generated when spending the money. So instead of storing the public key and the balance, the balance sheet would have to store the public key, a list of crediting references and their corresponding credit amounts - the total credit being the balance. Anything more?

We'd probably have to change the name from "balance sheet" to "complete current credits list".

If we made a client that used the credits list method and we magically crammed the appropriate credits list hash into the block list somehow then the modified software would perform transactions which would reference credit transactions in blocks long since thrown away and the current software would be happy.

There doesn't seem to be much the point of storing references to the crediting transactions in the new transaction. It's easy to see that the money is there and it's not as though we can trace coins forever even if we wanted to. In the example above, if you'd made a transaction to yourself for 100BTC before spending 50BTC then the identity of the original coins is lost. If the requirement of referring to crediting transactions is lifted then the block chain would be considerably smaller, the super light weight balance sheet method is useable and the software's a little less complex.

ByteCoin

^.^ Woops, sorry, was just trying to defend a fellow bitcoiner.  And sure thing on the clarification.  It's a huge issue faced by any distributed system like this, ESPECIALLY if you're dealing with money/something of value.