The Mini-Blockchain Scheme

[cryptocurrencylive]

The Mini-Blockchain Scheme

http://cryptonite.info/files/mbc-scheme-rev2.pdf

Abstract

Almost all P2P crypto-currencies prevent double spending and similar such attacks with a bulky “blockchain” scheme, and the ones which do not typically use some sort of pseudo-decentralized solution to manage the transactions. Here we propose a purely P2P crypto-currency scheme where old transactions can be forgotten by the network. Since nodes only require the newest portion of the blockchain in order to sync with the network, we call this portion of the chain the “mini-blockchain”. We argue that the loss of security this trimming process incurs can be solved with a small “proof chain” and the loss of coin ownership data is solved with a database which holds the balance of all non-empty addresses, dubbed the “account tree”. The proof chain secures the miniblockchain and the mini-blockchain secures the account tree. This paper will describe the way in which these three mechanisms can work together to form a system which provides a high level of integrity and security, yet is much slimmer than all other purely P2P currencies. It also offers other potential benefits such as faster transactions and lower fees, quicker network synchronization, support for high levels of traffic, more block space for custom messages, and potentially even increased anonymity.

[jmw74]

Sounds great to me. 

I was wondering how a new node can bootstrap and be sure it has a valid set of balances, when all the other nodes have discarded the transaction history. Just having proof of work doesn't tell you that all the transactions in those blocks are valid to you, just that they were valid to whoever mined them. But it sounds like that issue is addressed fairly well at the bottom of the "Proof Chain" section.

Shouldn't it still be possible to bootstrap using a torrent of the entire transaction history, and then just throw it away when you need the disk space?

[idev]

Come join us testing on the testnet

Code:

https://bitcointalk.org/index.php?topic=643758.0

[minerpumpkin]

Is this in any way different than just cutting the blockchain off at certain intervals and just start off a specific state? That way the initial download will be capped, and yet everything's still 'there' and can be verified at any given point in time.

[AnswerQuestion]

Is this in any way different than just cutting the blockchain off at certain intervals and just start off a specific state? That way the initial download will be capped, and yet everything's still 'there' and can be verified at any given point in time.

This would make sense to me. We could for example have block "x" contain all of the unspent outputs that were spendable at block "x-1000" and the new chain would pickup at block "x+1" and all blocks "x-999" to block "x" would have the same TX as the blockchain as it is now.

[rgm108]

It does make sense but...

It means someone, somewhere, has to look at balances now and then go back (on the blockchain) and 'delete' old transactions where addresses have a zero balance now.

Correct me if I miss-understood something but this sounds like centralization?

[minerpumpkin]

It does make sense but...

It means someone, somewhere, has to look at balances now and then go back (on the blockchain) and 'delete' old transactions where addresses have a zero balance now.

Correct me if I miss-understood something but this sounds like centralization?

No, we devise a system where the blockchain's state is being frozen every 10000 blocks (or any number that makes sense). Now we only redistribute that small blockchain to 'reduced' nodes. They could still be sure that blockchain is a correct copy by comparing it's hash or merkle sum or whatever to other instances. That way we wouldn't have to download the whole freaking chain, which doesn't make sense for various applications. Light wallets don't rely on downloading the whole chain already.