[CLOSED] $20,000 Mini-Blockchain Implementation

[bitfreak!]

The account tree is a totally new concept, there is nothing like it in the bitcoin design. The account tree is basically just a database of all the non-empty addresses. It's structured as a merkle tree so that the network can easily keep track of changes and maintain the integrity of the data held in the database.

[1715028931]

1715028931

[FrictionlessCoin]

The account tree is a totally new concept, there is nothing like it in the bitcoin design. The account tree is basically just a database of all the non-empty addresses. It's structured as a merkle tree so that the network can easily keep track of changes and maintain the integrity of the data held in the database.

So one Account has multiple addresses?   Are these Accounts broadcast to the network?  How does an Address know that it is associated to an account?

With Bitcoin, the only two object that are broadcast are Blocks and Transactions.

Are you saying that in your system,  there Proofs,  Blocks, Accounts and Transactions that are broadcast?   Are there transactions?

[bitfreak!]

So one Account has multiple addresses?   Are these Addresses broadcast to the network?

Sorry I misunderstood your earlier question. Yes I suppose you could call the account tree an address tree because it holds information about all the non-empty addresses. The account tree is simply a hash tree where the data blocks represents individual accounts. The reason we call them "accounts" is because they hold more than just the address, each data block will also hold the balance of that address and some other information about the address. Each account will hold information about a single address only. All nodes will have a copy of the account tree just like the blockchain. The mini-blockchain works just like a normal blockchain and it holds transactions just like a normal blockchain, the only difference is that it gets trimmed after a certain period of time. When a new block is generated and propagated to all the nodes in the network, those nodes will use the transactions in that block to update their copy of the account tree and then they will recalculate the master hash of the account tree and make sure it matches the master hash specified in the block header, if it doesn't match then the block is considered invalid. I suggest that you read the mini-blockchain wiki properly, it explains everything in detail.

EDIT: it's also important to keep in mind that the transactions wont use scripts:

Script is not used within the mini-blockchain scheme. Since the account tree holds the final balance of all non-empty addresses and is not a continuous ledger of transactions like Bitcoin it's not possible to use scripts which must be solved at a later time because transactions in the mini-blockchain are discarded after a relatively small period of time (the length of the mini-blockchain cycle time). However, this is not really as much of a disadvantage as it may seem.

It is still possible to allow more complex types of transactions by defining special account types which support things such as a multi-signature transactions. By not utilizing script we get the advantage of making many aspects of the system exceptionally simpler and at the same we get an increased level of security because every type of possible transaction will be very well defined, eliminating the risk of an unforeseen script causing havoc on the network.

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

[FrictionlessCoin]

So one Account has multiple addresses?   Are these Addresses broadcast to the network?

Sorry I misunderstood your earlier question. Yes I suppose you could call the account tree an address tree because it holds information about all the non-empty addresses. The account tree is simply a hash tree where the data blocks represents individual accounts. The reason we call them "accounts" is because they hold more than just the address, each data block will also hold the balance of that address and some other information about the address. Each account will hold information about a single address only. All nodes will have a copy of the account tree just like the blockchain. The mini-blockchain works just like a normal blockchain and it holds transactions just like a normal blockchain, the only difference is that it gets trimmed after a certain period of time. When a new block is generated and propagated to all the nodes in the network, those nodes will use the transactions in that block to update their copy of the account tree and then they will recalculate the master hash of the account tree and make sure it matches the master hash specified in the block header, if it doesn't match then the block is considered invalid. I suggest that you read the mini-blockchain wiki properly, it explains everything in detail.

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.

[bitfreak!]

In Bitcoin,  Blocks and Transactions are what are broadcast in the the network.

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.

[FrictionlessCoin]

In Bitcoin,  Blocks and Transactions are what are broadcast in the the network.

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.

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.

[bitfreak!]

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

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.

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

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.

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

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.

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

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.

[FrictionlessCoin]

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

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.

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?

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

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?

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

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?

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

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.

[bitfreak!]

It is pull based,  so any node can request older transactions.

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.

Does an account have an identifier or hash that will distinguish it from other version of itself in the network?

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

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?

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

So are you saying that, once a transaction is included in a block it is never accessible or propagated through the network?

I believe my first answer should answer this too.

[FrictionlessCoin]

It is pull based,  so any node can request older transactions.

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.

Does an account have an identifier or hash that will distinguish it from other version of itself in the network?

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

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?

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

So are you saying that, once a transaction is included in a block it is never accessible or propagated through the network?

I believe my first answer should answer this too.

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?

[bitfreak!]

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

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

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?

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.

[FrictionlessCoin]

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

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

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?

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.

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?

[bitfreak!]

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

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

Because transactions are removed,  won't users lose the ability to have a record of their transaction?

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.

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?

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.

[FrictionlessCoin]

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

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

Because transactions are removed,  won't users lose the ability to have a record of their transaction?

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.

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?

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.

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?

[bitfreak!]

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?

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.

[FrictionlessCoin]

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?

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.

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

[bitfreak!]

Not sure what you mean. Please elaborate.

[FrictionlessCoin]

Not sure what you mean. Please elaborate.

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.   

[bitfreak!]

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.

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.

if you want on only with a years worth of transactions, you query until the account tree of a year previous.

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

[FrictionlessCoin]

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.

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.

if you want on only with a years worth of transactions, you query until the account tree of a year previous.

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

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.