Topic: [CLOSED] $20,000 Mini-Blockchain Implementation (Read 10068 times)

UPDATE: I am going to close this bounty within the next week because I've had this bounty open for a very long time and it looks like no one is currently working on it and I have several people interested in working for me directly in return for a weekly wage. I feel that this project will get done quicker if I pay a team of developers to work for a weekly wage, so unless there are any objections I will close this bounty within a week. If you are interested in joining the team and working for a weekly wage please send me a PM.

Ok.   I  see your point.  Transactions can be saved by parties interested in saving the transactions, but these don't need to be globally broadcast.   

The whole purpose of the mini-blockchain scheme is to increase scalability. Just imagine if Bitcoin were to reach the level of traffic that Visa must handle on a daily basis, there is no feasible way that all those transactions can be stored within a blockchain which records every transaction forever. The transactions are the bulkiest part of the whole bitcoin scheme, so what the mini-blockchain scheme aims to do is limit the number of transactions which are required to be stored by every node down to only a week or less of transaction history.

There isn't really any trade off involved because users can save the transactions which correspond to their addresses if they want to keep a record of the transactions they have made, but there's no need for them to store any of the other transactions longer than the cycle time of the blockchain. But any node that wishes to save a year or more worth of transactions can do so if they are willing to give up the disk space required; the key thing is that no node is required to store any transactions longer than the cycle time of the mini-blockchain, and that enables anyone to quickly synchronize with the network instead of having do download gigabytes worth of transaction history.

Yes you can discard transactions after a period of time so long as you have a method of maintaining a secure ledger which records the exact balance of each address. That is what the account tree does. It is a compact snapshot of the entire system in a sense, but it's a snapshot which gets updated with every new block. The transactions in each block don't link back to other transactions like they do in Bitcoin, they simply issue commands which say "take X number of coins from the balance of address A and give them to the balance of address B". So long as the balance recorded in the account tree for address A holds at least X number of coins and so long as the transaction is signed with the private key of address A then the transaction will be accepted by the network. There is no need to look back at historical transactions, so they can be safely discarded when they fall outside the mini-blockchain.

Actually I look at is as if the Account tree is a tradeoff.  

You need to keep transaction up to a certain period.  That is just how it works for any payment system.  and that is what users will expect.

However, for a duration say greater than 1 year or 3 years,  you want to archive those transactions.  To do so needs what you call the account tree that servers just as a snapshot of the transactions at a certain point in time.  

I think your proposal is interesting,  however I don't think you can discard transactions.

Transactions are stored in the blocks the same way as in Bitcoin, so there will be a merkle root in every block just like Bitcoin.

It probably wouldn't be possible to get transactions from the previous year because the cycle time of the mini-blockchain wouldn't be anywhere near that long.

I still get the feeling you aren't really grasping the concept properly...

What I mean is that instead of just the master hash on the block, there is also a merkle root that points back to the transactions in the block just like bitcoin.

Clients then may query for all the transactions or only the transactions up to a certain block.

That way you get the best of both worlds,  if you want the entire block chain you query all transactions,  if you want on only with a years worth of transactions, you query until the account tree of a year previous.   

Not sure what you mean. Please elaborate.

What about a solution that has both a Transaction Block and an Account Tree?

I haven't really thought much about this but I believe it would be possible to do something similar. You could get the proof chain and all the headers from the mini-blockchain and then to check the balance of any given address you could just request a specific branch of the account tree which corresponds to the account you are interested in. The advantage of using a merkle tree is that you can acquire small pieces of the whole tree and confirm them against the master hash without needing the whole tree.

Is a SPV client feasible with this kind of setup?

If you discard the transactions (and likely the merkle roots in the blocks) you aren't able to do a Simple Payment Verification that a transaction exists in a block.   Is there something similar where you can have a lightweight client?

Not necessarily a cache of transactions, a cache of the changes made to the account tree would make more sense.

Yes, without a blockchain which saves every transaction that ever happened it wont be possible to go back and examine old transactions. This may offer a little bit of extra anonymity however it's likely that some people will choose to store every transaction for historical purposes. Each node will have the ability to change how long they want to store transactions, but it cannot be any shorter than the cycle time of the mini-blockhain.

If you're going to save so many transactions you may as well just go back to using a full blockchain. The whole point of the mini-blockchain is to make the blockchain as small as possible so that the network becomes extremely scalable. The account tree is just a way to keep track of the address balances without requiring all transactions to be recorded forever.

So it may make sense for an implementation to have a LRU cache of transactions in the case of forks?

Because transactions are removed,  won't users lose the ability to have a record of their transaction?  Would it make better sense to hold like a year's worth of transactions and the Account tree is really just there for a check point mechanism?

Yes in that case there would be two competing blockchains and two account tree corresponding to each chain.

Yes that is correct. If the losing chain is just a couple of orphaned blocks then there should be enough of a backup stored in memory to undo the orphaned changes. But then the nodes would need to query the network to catch up to the correct chain. In the case where the nodes cannot undo the changes then they will have to go through the resynchronization process.

What happens when the block chain is forked?   Would there not be two sets of competing account trees?

In the case that an account tree becomes the losing tree,  I gather the protocol needs to go out in the network to refresh its info?

Why would a node want to request an older transaction that is not being relayed? Oh... you mean transactions that have been previously included into blocks and not orphaned transactions? So what you're asking is what determines when the the transactions in old blocks are discarded? The answer to that depends on the length of the mini-blockchain cycle. If the cycle is set to a week then transactions will be kept by nodes for a week before they are discarded. Then the remaining block header becomes part of the proof chain.

Since the account tree is structured as a hash tree, yes, every single account in the tree has a corresponding hash obviously.

http://bitfreak.info/mbc-wiki/index.php?title=Network_synchronization

I believe my first answer should answer this too.

It is pull based,  so any node can request older transactions.  So in this implementation,  a node may request a transaction that does not exist in any node.   So therefore,  there is some criteria when to throw away transactions.  What is that criteria?



Yes obviously the accounts are relayed through the network for other nodes to reconstruct the account tree. The account tree will be created after the first genesis block is created. Nodes will reconstruct the account tree when they are synchronizing with the network.
[/quote]
Does an account have an identifier or hash that will distinguish it from other version of itself in the network?




In order to determine which version of the account tree is the correct one, a node must first obtain the full proof chain and the mini-blockchain with the highest cumulative difficulty. The master hash of the account tree is contained in every block header so that when the node has reconstructed the account tree they can make sure it contains the right data. The block height can be calculated from the number of block headers in the proof chain and mini-blockchain so it doesn't necessarily need to be stored in the account tree, but it would probably add a bit of extra security to do so.
[/quote]
How is the account information requested from a node?  Do I ask the node, "give me account for block height 13?"   If the block height is already at 15, do I return an error?



I'm not sure what you mean. I get the feeling you still aren't fully understanding the concept of how the mini-blockchain and account tree are supposed to work. What do you mean "when addresses are sent"? Do you mean when are portions of the account tree propagated across the network? Like I said, that should only happen when a node is synchronizing with the network. The mini-blockchain wiki has the answer to all of these questions, please read it properly.
[/quote]
So are you saying that, once a transaction is included in a block it is never accessible or propagated through the network?   The problem is,  the P2P network is never certain until a number of blocks whether a transaction is in the block chain or not.   So you can't start transmitting account information until you have the requisite number of confirmations.

I'll be honest,  unless there is a specification of the network protocol, then this specification is incomplete.

Like I said, transactions are collected into blocks in the same way as Bitcoin transactions, so nodes would stop relying transactions in the same way as they do with Bitcoin. To be honest I'm not exactly sure how a Bitcoin node decides to stop relaying transactions.

Yes obviously the accounts are relayed through the network for other nodes to reconstruct the account tree. The account tree will be created after the first genesis block is created. Nodes will reconstruct the account tree when they are synchronizing with the network.

In order to determine which version of the account tree is the correct one, a node must first obtain the full proof chain and the mini-blockchain with the highest cumulative difficulty. The master hash of the account tree is contained in every block header so that when the node has reconstructed the account tree they can make sure it contains the right data. The block height can be calculated from the number of block headers in the proof chain and mini-blockchain so it doesn't necessarily need to be stored in the account tree, but it would probably add a bit of extra security to do so.

I'm not sure what you mean. I get the feeling you still aren't fully understanding the concept of how the mini-blockchain and account tree are supposed to work. What do you mean "when addresses are sent"? Do you mean when are portions of the account tree propagated across the network? Like I said, that should only happen when a node is synchronizing with the network. The mini-blockchain wiki has the answer to all of these questions, please read it properly.

Ok.  

Bitcoin is a P2P network,  so I have to understand what messages are sent.

(1) When are transactions no longer relayed by a node?   In other words,  when are they baked into an account such that they no longer are relayed?  What determines when a transaction is not relayed anymore?

(2) When the account tree is created.   Are accounts relayed through the network for other nodes to store and reconstruct?

(3) Which version of an account should a node accept?   Is there a block height embedded in the account? Is there a hash that relates the same account to a previous version of it?

(4) I need to understand the interplay of when transactions are sent and when addresses are sent.  I also need to understand what happens when a transaction is in conflict with an address and how to determine if there is a conflict.

It's the same thing here... what is so hard to understand about what I said. Miners will collect the transactions into blocks and then when a miner solves their block they will release it to the network. Then the other nodes will add that block onto their mini-blockchain just like they would for a normal blockchain. In Bitcoin that would be the end of it, and you'd need the entire blockchain to calculate the balance of any address because the blockchain has no concept of address balances, it's a continual ledger which keeps track of where coins are sent to work out the balances. However in the mini-blockchain design the balances are saved into the account tree, and when a new block is accepted onto the mini-blockchain the nodes will use the transactions contained in that block to recalculate the balances of the addresses in the account tree. A transaction will contain a simple command like "send X number of coins from address A to address B". So the nodes will simply carry out those commands by altering the balances in their account tree, if an account doesn't exist then it is added to the tree, and then when the changes have been made they will recalculate the hashes in the account tree.

Clearly there is something missing here.   In Bitcoin,  Blocks and Transactions are what are broadcast in the the network.

What is broadcast here?  

I would think that transactions are broadcast.

So they are collected in Blocks.  So blocks contain transactions.

Or.... not in this case...  how are transactions consumed?

I am missing something here.

Also, I don't understand how you can update the global account when a peer doesn't see all the transactions.