Yeah plenty of household computers in the US could handle it, but the US isn't the world, and we are designing a global crypto-currency which will be used by people all around the world, many of whom will have fairly slow connection speeds, especially upload speeds. One of the benefits of the mini-blockchain scheme is that mining doesn't have to become a highly specialized and centralized industry because almost anyone can handle the size of the mini-blockchain. The aim should be to exclude the minimal amount of nodes possible, meaning we need to take into consideration the connection speeds of people all around the world. So even though many people may be able to handle a huge number of transactions per second will still need to balance it and place a cap on it. This is why I believe a dynamic max block size is necessary, because this isn't something which will remain the same over time. In the future the majority of people will have much faster connection speeds.

The code quality of bitcoinj doesn't look too bad either, apparently it was written by a guy from Google. And it has been under development for more than 2 years now, which seems to be a lot longer than bitsofproof has existed.

And bitcoinj code is far more documented. My first impression was wrong, bitcoinj seems to be more suited for our needs.

Ok well we can all agree on that. I might add to the opening post that we plan to work with bitcoinj and thus require Java developers.

Ok well we can all agree on that. I might add to the opening post that we plan to work with bitcoinj and thus require Java developers.

That's an excellent decision.While you are gathering a team, I will try to create an adhoc performance test for a database/tree-storage of "account tree", i.e. generate 100million accounts, pack in the Merkle tree, store them and run common queries.

Also I really-really wish to make it extendible from the beginning. For example, I think it's not hard to assume that you can have more than "account tree", mini-block chain, etc.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.

No we haven't set up a main repository yet because we are still deciding on some of the details. If you read through the thread you'll see we decided to go with bitcoinj instead of bitsofproof, so if you want to start anywhere, start by looking at bitcoinj. Hopefully we'll have a repository set up soon so some of you can get to work, we also need to decided on a nice name for the coin before we can set it up.

I like the idea of using bitcoinj to start with. Already we are a step up from the myriad bitcoin-qt copycats.

Silly name ideas: EverCoin (already suggested by another poster, b/c coin is sustainable, forever) SmallCoin TinyCoin LittleCoinShortCoin OneCoin (the one coin, to rule them all!) Ethercoin (because the rest of the blockchain just vanishes into the ether) BalanceCoin (b/c entire ledger history is not necessary, just the balance!)

Silly name ideas: EverCoin (already suggested by another poster, b/c coin is sustainable, forever) SmallCoin TinyCoin LittleCoinShortCoin OneCoin (the one coin, to rule them all!) Ethercoin (because the rest of the blockchain just vanishes into the ether) BalanceCoin (b/c entire ledger history is not necessary, just the balance!)

Instead of another "******Coin", it's better to take a good ISO currency code from the beginning, like Ripple did with XRP. It must start with X then. Something like XCC, i.e. CC for Crypto Currency.

I believe that merged-mining was part of this next-gen crypto-currency, I would like those following this thread to consider a new approach to scalable merged-mining that allows a 'fixed-size' proof-of-work regardless of the number of chains involved in merged-mining.

I believe that merged-mining was part of this next-gen crypto-currency

I don't believe that merged-mining is part of this scheme, although it would be a part of something like the ultimate blockchain compression scheme. It seems like you still aren't fully understanding the way this new scheme is designed to work.

I believe that merged-mining was part of this next-gen crypto-currency

I don't believe that merged-mining is part of this scheme, although it would be a part of something like the ultimate blockchain compression scheme. It seems like you still aren't fully understanding the way this new scheme is designed to work.

I have read a lot of different papers on this forum, so I may have gotten some parts confused. I went back to re-read the white paper to check to see what I thought I rememberd and what I was actually thinking of was the 'proof-of-work chain' in this system. I was suggesting that it could be updated to use the accumulator method to allow any number of 'proofs' to be stored in the same proof-of-work chain and therefore it would be usable by every blockchain out there without increasing the size.

The account tree structure and mini-block-chain approach is 100% the way I think things need to go. I am attempting to implement a new blockchain and started designing something very similar to the white paper. So on closer look, I have to give this approach strong backing.

In order to make sure the same signed transaction isn't processed by the network more than once, the signer of the transaction will need to include in the transaction the hash of any accounts referenced as inputs for the transaction (we don't need to worry about the outputs because we have no control over how those accounts change). After the transaction is applied the accounts will have a different hash and therefore nodes will know not to accept that same signed transaction again because they can see the account hashes don't match.

The challenge here is that in the event of a chain split, this transaction could not be applied upon re-merging of the forked chain. It also limits transactions to 'one per account per block' where as bitcoin could in theory have many different transaction per address provided they were all based upon different outputs and incoming transactions would not interfere with outgoing transactions.

To address this issue transactions will need to include an 'initial and final' block number that they may be stored in, then the hash of the transaction must be stored until the 'final' block number in which it will expire to prevent double-spends. Otherwise you assume all transactions make it into the account any other changes to that account and no one person has control over all changes to an account (after all someone else could send the account funds at the same time you send your trx).

Conclusion, all transactions must have an expiration block number and must be stored until that date. This could be as simple as including all transactions in the 'mini-block-chain' until they fall of the end, though I suspect they would only need to be kept around for 48 hours or so.