Topic: Building the Next Generation of Crypto-Currency (developers required) - page 6. (Read 23571 times)

Great insight, except these slots can be reused if the balance reaches 0.  To safely use just offsets would require that the slot be empty for 24 hours or so before being reused.

It is just theoretical work. We would need already implemented stable libraries.

But why we actually need an accumulator here? Can we just add the transactions to the block and mine it as usual? We can have a separate account ledger for any other currency to store balances.

We should also choose the "slot" size optimaly for the Account Ledger tree.
We can use the results from http://ecommons.library.cornell.edu/bitstream/1813/5655/1/TR2004-1944.pdf

I recently stumbled across these two papers which show that it is possible to prove a 'hash' exists in a fixed sized accumulator.  This is the basis behind ZeroCoin.

http://www.cs.stevens.edu/~mdemare/pubs/owa.pdf
http://spar.isi.jhu.edu/~mgreen/ZerocoinOakland.pdf

I think we should put design together in wiki before touching code.
I already made a page regarding account tree implementation. I think we should just stick with binary tree.
http://bitfreak.info/mbc-wiki/index.php?title=Account_Ledger

EDIT:
As for merged mining I think it would be nice to include it, but I need to think it over. Do you know any good quality resources where it is described?

I think we should treat account ledger as just list of accounts. Account never changes its place on ledger unless it is emptied. This way we can address accounts by just its offset in ledger. This would enable us to make transaction a lot smaller because offset would fit in 5 bytes while public key is 32 bytes.

It looks like the solution posted on the wiki is the same solution I came up with, so we are all on the same page!   

I have done Java, though c++ is my primary language.    I think that we need to solve some of the design details that are language independent first and if there is a solid java implementation then I could be tempted to go that route.  

I have a strong need for many parallel chains with combined proof-of-work as a means of providing scaling beyond what a single chain could do.   So off of the top of my head some small changes I would make:

1) move the nonce to the proof chain and replace the block-hash with an accumulator (see ZeroCoin), this would allow all mining efforts for all chains using the same 'proof of work' to support as many chains as possible with almost no extra work.   The nonce would only add 8 to 12 bytes per proof header and thus would not really affect the result.

2) Define sector sizes and what goes in each sector.  Assuming you use something like sha224 you incur 28 bytes of overhead for each level in the merkel tree.  If you have a deep tree, then to 'address' a particular change would require 28 bytes per layer.   If you have a 'flat tree' then recalculating the root hash would require hashing your entire data set.    From a purely big-O stand point you want a hash tree that grows in depth as your data set grows.   The only question you have to consider is the 'branching factor' with 2 being the lowest and something on the order of 1 MB of accounts being the 'largest'.   From a network perspective, having each 'sector' of the dataset fit in a single UDP packet may be the right sector size.   Assuming each account is 48 bytes this means about 32 accounts per sector and each node in your merkel tree would in turn contain about 32 hashes 'children'.   The end result would be log32( total accounts size ) * sizeof(sha224) to prove a prove a particular 'account' has membership in the root hash.       Something to consider regarding making the sector size too large is the probability of a random transaction causing a change to a sector.   If 1% of all addresses see changes in every block and your sector size is 128 then chances are *every sector* will change every time and thus you have little savings.  

    To counter this 'random' behavior, free slots should be deterministically selected from the most-frequently changed sector first.   In fact each block should not just update/replace certain sector, but instead should 'sort' the addresses by least-recently accessed.   So, assume 5 addresses change in 5 different sectors resulting in 5*32 addresses that are part of a changed sector.   Users would have to fetch entire sectors at a time anyway so we might as well use the fact that these sectors have 'changed' to re-sort all 5 sectors moving the 5 changes into the same 'new sector' and moving the least recently changed into other sectors.   This will result in a 'hot set' and a 'cold' set and thus minimize the total number of sector fetches that must occur.  

   Ultimately you need all accounts to be accessed via a hash table and to validate that you have the 'entire hash table'.   Moving addresses around within the sectors would cause significant overhead in updating your hash-table index that allows you to find the addresses quickly.  This might be 'unavoidable' if you want to minimize sync overhead as you would be trading CPU time for network time.  

3) Identify how splits / remerges will be handled.  I think the white paper fails to properly handle this issue along with handling multiple transactions from a single account in a single block.

This initial scheme wasn't as bad as you say. You could include any number of tx in same block, because versions changes was applied only during block inclusion.
Anyway I spotted weakness in this approach already and posted refined proposal in wiki few days ago.
http://bitfreak.info/mbc-wiki/index.php?title=Transaction_Signing

That's a good observation which I hadn't realized. Although I'm having a bit of trouble seeing how your proposed solution would allow multiple transactions using the same account... my brain isn't working well today.

We will have a github repo up very soon and it would help if you could contribute to the project. We plan to work with bitcoinj, are you any good with Java?

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.

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.   

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

https://bitcointalksearch.org/topic/fixed-size-merged-mining-proof-of-work-1000s-of-chains-230120

Why hasn't anyone used the term "credits" yet? Is it because it assumes a debt relationship?  XCC- Exchange Credits sounds so universal tho. 

Yeah I agree we should make the currency code begin with an X. And I would prefer to leave "coin" out of the name unless someone thinks of something extremely clever which hasn't been used already.

if you need a name, how about NanoToken (NNO)

BetterCoin ?
Better Crypto Currency => BCC ?

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.