[CLOSED] $20,000 Mini-Blockchain Implementation

[jrslyrics]

interesting concepts.

[bitfreak!]

The bounty for 'Re-Mining' is set at $3000. This is a lot to pay for a feature that won't be utilized for at least 50 years. Even as a selling point it is only marketable to those extremely confident in the longevity of your coin.

Is there any possibility you would consider withdrawing the bounty and adding it to the basic implementation? I think this would offer much better business value for your money.

Yeah I was thinking about removing that bounty anyway because there are some downfalls with coin re-mining I want to keep this implementation as close to bitcoin as possible.

[CasualSam]

Dear existing/prospective developers,

With the bounty system on offer there are a number of reasons why a team approach is better value than attempting to complete this individually.

* Higher chance of receiving the bounty. A team is more likely to beat an individual.
* The effort/reward ratio is maintained.  Bounty would be split fairly by a predetermined method (e.g. Tasks completed/hours worked/value added/etc.)
* Peer discussion and review. Strategies and difficulties can be discussed and worked through as a team.
* Flexible commitment. Work as much or as little as you want. If you have specialist knowledge but limited time perhaps you could act as a consultant and receive a split of the bounty based on the value you add.

If anyone would like to join a dev-team, please PM (or post here). If there is a positive response I’ll set up somewhere private to discuss further (ideas?).

[CasualSam]

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

[CasualSam]

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.

[CasualSam]

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

[FrictionlessCoin]

What language is the code written in?

[Wilhelm]

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

[CasualSam]

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.

[CasualSam]

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

[bitfreak!]

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.

[bitfreak!]

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.

[FrictionlessCoin]

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?

[bitfreak!]

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

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

[FrictionlessCoin]

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

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?

[FrictionlessCoin]

Will a version of this using the GHOST protocol work?

That is, a block may have multiple parents?

[bitfreak!]

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

Will a version of this using the GHOST protocol work?

I don't see why not.

[FrictionlessCoin]

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?

[bitfreak!]

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.

[FrictionlessCoin]

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?