Bitcoin Forum
December 11, 2016, 04:17:53 AM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 [3]  All
  Print  
Author Topic: With "Balance sheets" most of the block chain can be forgotten.  (Read 11413 times)
grondilu
Legendary
*
Offline Offline

Activity: 1134


View Profile
October 25, 2010, 11:03:01 AM
 #41

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

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 ?

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

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

Quote
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?

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.
1481429873
Hero Member
*
Offline Offline

Posts: 1481429873

View Profile Personal Message (Offline)

Ignore
1481429873
Reply with quote  #2

1481429873
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
theymos
Administrator
Legendary
*
Offline Offline

Activity: 2506


View Profile
October 25, 2010, 10:15:39 PM
 #42

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

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.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
ByteCoin
Sr. Member
****
Offline Offline

Activity: 416


View Profile
October 26, 2010, 06:23:49 AM
 #43

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

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.

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.

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.
Thanks for supplying some real numbers. I'm afraid that "balance sheet" is not really an accurate description of what is stored. See
We'd probably have to change the name from "balance sheet" to "complete current credits list".
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.

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

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

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.
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
LZ
Staff
Legendary
*
Offline Offline

Activity: 1456


Satoshi everywhere!


View Profile WWW
October 29, 2010, 01:59:57 PM
 #44

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 how can you be sure that bitcoins in wallets that you created for your kids education will be valid in the future?

"Never invest unless you can afford to lose your entire investment." © S3052
Pages: « 1 2 [3]  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!