Pages:
Author

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

legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
Quote
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:

Quote
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
legendary
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
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?
legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
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.
legendary
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
Quote
so you try to calculate the hash only for the parts that changed?
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.

When you talk about an Account tree... you mean an Address tree in Bitcoin terminology?
legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
Quote
so you try to calculate the hash only for the parts that changed?
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.
legendary
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
Quote
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 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).

Interesting.

Hmmmm....   so you try to calculate the hash only for the parts that changed?    I guess this a merkle tree?
legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
Quote
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 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).

Quote
Will a version of this using the GHOST protocol work?
I don't see why not.
legendary
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
Will a version of this using the GHOST protocol work?

That is, a block may have multiple parents?
legendary
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
Quote
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?
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).

Quote
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?
http://bitfreak.info/mbc-wiki/index.php?title=Transaction_Signing

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?
legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
Quote
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?
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).

Quote
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?
http://bitfreak.info/mbc-wiki/index.php?title=Transaction_Signing
legendary
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
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?

legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
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.
legendary
Activity: 1536
Merit: 1000
electronic [r]evolution
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.
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.
member
Activity: 85
Merit: 11
Is there any chance the mods could move this back to "Project Development"? It is much more suited to the audience there.
member
Activity: 85
Merit: 11
What language is the code written in?

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.



legendary
Activity: 1652
Merit: 1265
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 Cheesy
legendary
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
What language is the code written in?

member
Activity: 85
Merit: 11
Any additional devs please contact me as I'm sure you'll be able to add something to the team.

member
Activity: 85
Merit: 11
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.
member
Activity: 85
Merit: 11
When you say on the wiki page describing the Account Tree that it should be easy to reference an account by "offset and address" I'm guessing that by "address" you mean the key needed to spend to that account, but what do you mean by "offset?"

It wouldn't be hard at all to make it easy to reference an account by address alone.  That would make it equally simple to just ignore some extra data called an "offset" as being something I don't really need to find the account -- unless you mean that you also want to be able to look it up by offset alone, without needing the address for this other kind of search?

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).
Pages:
Jump to: