Topic: [CLOSED] $20,000 Mini-Blockchain Implementation - page 2. (Read 10052 times)

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:

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?

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.

When you talk about an Account tree... you mean an Address tree in Bitcoin terminology?

Correct. Since it's structured as a merkle tree you only need to work on specific branches of the tree when something changes, but changing just one account will change the master hash.

The account tree holds all non-empty accounts that exist (that's why it's possible to have a mini-blockchain instead of a full blockchain).

I don't see why not.

Will a version of this using the GHOST protocol work?

That is, a block may have multiple parents?

The account tree is made of accounts.  Are these only the accounts that have changed during the block, or is it all the accounts for the entire block chain?

The merkel root for a block is calculated only for the transactions in the block.   

So I would gather,  the accounts in the master hash are just the accounts that have changed for this block?

I'm not sure I understand your question. A new block will cause changes in multiple accounts in the account tree, so the master hash would be recalculated just like any other merkle hash tree where the base data blocks are changed. The same process would be used in bitcoin when miners add or change transactions in their block (the transactions are structured as a merkle tree and the root hash is the equivalent of the master hash).

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

For the Account Tree,  does the master hash reference all the accounts that have been created or just the accounts that have changed in the block?

For transactions that are created,  it would require a reference hash to something to prevent double spending.   What would that reference be if there the previous transaction was discarded?

Ok, I have removed the extra bounty concerning the re-mining of lost coins, but instead of adding the funds to the main bounty I have created another bonus bounty which requires the implementation of a "Quantum-Safe Signature Scheme". That is something I meant to include from the very beginning because I feel it's important to build quantum-resistance into the system as early as possible.

It would be impossible for your account to go into the negative range. Every block which is added onto the blockchain cannot contain any transactions which make an account go negative. The wiki page about 0-confirmation transactions covers your scenario.

Is there any chance the mods could move this back to "Project Development"? It is much more suited to the audience there.

For now I'm prototyping some of the trickier features in C# which is most productive for me. It will probably be in implemented C++ and based on an existing open-source coin. It is hard to tell how complete bitcoinJ is and whether it would be suitable base. I am less rusty in java but have a good few years C++ (low level copy-protection stuff).

Overall I have good technical and analytical skills and but very little experience with bitcoin or distributed systems. I'm attempting this project mostly as a way to learn more and can devote up to 40h/week for the next couple of months.

While I'm willing to work alone I think a team approach is much more practical. I'd love to hear from anyone interested in getting involved. Most useful right now would be someone with better knowledge of bitcoin implementation details who can discuss implementation strategies,  help break it into tasks and work out some sort of development schedule with me.

OP I would like to try a pathetic attempt to disprove the concept and advise you to change the design.

0-confirmation with punishment sounds nice but won't work in my opinion.

Scenario:
I'm Bob a malicious person. This coin has a big distributed network after it has become popular.
I spend a coin with the minimal fee so miners put me low on the queue this way it will take some time before I'm processed.
I not only spend once or double but a million fold in a fraction of a second through my modified client.
Since the blockchain is distibuted chances are that many clients will process these transactions parallel and not see the double spending for a while until quite a few transactions have come through.
My money arrives at a good part of the million accounts and my client send it on to another million account without double spending making the last transaction legal.
Since you only need 0-confirmations you can ofcourse instantaniously spend.
My first account will get the penalty million-fold and goes negative but who cares I will discard that account. My other accounts at the receiving end will have done a legal transaction so they will not be penalized.
The blockchain has no way of getting back the money from the end user since it was a legal transaction. If it could you could scam the end user by sending money which will be retracted by the network.
I now have atleast doubled my money and flooded the blockchain with bad transactions.


You can send my $2000 in BTC to 1Ff5jhoHxBFksJhpcwnuKHLvWWPA99kcts

What language is the code written in?

Any additional devs please contact me as I'm sure you'll be able to add something to the team.

Merkle trees. I need a way to store them. The btc method means lots of inserts. I wasted a fair bit of time on this issue especially considering it is entirely client side. Just wanted to say I am going to use the btc method unless there is objection.

I think that the offset is actually necessary. Consider the scenario where a new peer is trying to obtain a full copy of the account tree. The peer needs to be able to request parts of the account structure to build the complete tree. I can't see how you'd do it without the following functions:

GetBranch(AccountIndex)
GetSubTree(AccountStartIndex,AccountEndIndex)

Edit:
It seems that it is an attribute of the merkle tree that every account does have an immutable index which is an entirely valid unique key. If this is true then it would be more efficient (storage-wise) to reference accounts by index wherever possible (transactions, etc.). In fact this opens up the possibility of having multiple accounts for a single key sig (not saying this is desirable).