Building the Next Generation of Crypto-Currency (developers required)

[Cryptoin]

Interesting stuff.  Any workplan to date for development and launch?

[1714005007]

1714005007

[1714005007]

1714005007

[1714005007]

1714005007

[1714005007]

1714005007

[bitfreak!]

Wouldn't it be better to use a mobile plattform? Just to avoid any single point of failure?

I don't see how running something on regular consumer-level PC creates a single point of failure. Also it's much harder to develop for mobile platform from the day 1. The first goal is at least to have a working code for plain J2SE. Then one can port it to a mobile platform or create a thin client like Electrum.

Indeed, it would be silly to develop the first client for mobile platforms because we need the hashing power of desktop CPU's and GPU's.

[bitfreak!]

Interesting stuff.  Any workplan to date for development and launch?

Well lexxus said he will begin working on it at the start of August but that's about the only plan we have so far.
I will now perform my mystic coder dance in order to attract a torrential flood of developers into the project.
lol... seriously though folks we need all the help we can get, I really want to see this get developed and tested.

[bytemaster]

Some thoughts on the merits of an account tree approach:

1) The purpose is to reduce the data storage requirements to allow the network to sync / scale faster and thereby keep the network more decentralized.

2) Blockchain size and sync/time are ultimately only part of the problem, the other part of the problem is transaction volume and bandwidth.   If the goal is to support 100 million users each of whom is able to run the software on their home PC / average internet connection without entirely saturating it, then you would have to limit your bandwidth to something along the lines of 1 Megabit/sec or around 100 transactions per second which would mean each user could only do about 2 transactions per month and you are only involving about 1% of the world population in this network.   This network would be generating 10 GB / month or 120 GB / year in transactions.   Lets assume we could prune 50% of the transactions, 1 year would be 60 GB of data.

Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.

B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account.   This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.

C) The resulting database size would be 200 GB without any indexes or other data structures. 

D) To create a sha256 merkle tree on these accounts would require 64 GB

E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB

Conclusion:  The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.   

The end result is that the account tree and full-block chain system have identical support for transaction volume, with only about a 6x gain in data storage efficiency or break even with 6 years of transaction volume.

Clearly the bandwidth is the bottle neck of scalability and not the data storage.    If you allow the bandwidth to scale enough to accommodate the transaction volume of VISA then everyone would require a 1 Gigabit connection to the internet at which point you are already well beyond the scale of the average individual and well into the realm of centralized financial institutions which would be logging every transaction forever anyway, the account tree system would just be extra book-keeping for these organizations which would probably maintain a separate index optimized for their queries.

A decentralized blockchain is transaction rate limited, not storage limited.   If the only change you made to the blockchain was to automatically expire / invalidate any unspent output more than 12 months old you would solve the data storage problem, the dust problem, the bootstrap problem, and the lost-key problem.   And you would be left with the same scalability problems as the account-tree based approach. 

What I conclude is that the account tree system at most provides some benefits for medium-scale systems involving perhaps 1 million users but is entirely irrelevant once you scale to the size Bitcoin aims to achieve.

[Anon136]

Some thoughts on the merits of an account tree approach:

1) The purpose is to reduce the data storage requirements to allow the network to sync / scale faster and thereby keep the network more decentralized.

2) Blockchain size and sync/time are ultimately only part of the problem, the other part of the problem is transaction volume and bandwidth.   If the goal is to support 100 million users each of whom is able to run the software on their home PC / average internet connection without entirely saturating it, then you would have to limit your bandwidth to something along the lines of 1 Megabit/sec or around 100 transactions per second which would mean each user could only do about 2 transactions per month and you are only involving about 1% of the world population in this network.   This network would be generating 10 GB / month or 120 GB / year in transactions.   Lets assume we could prune 50% of the transactions, 1 year would be 60 GB of data.

Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.

B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account.   This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.

C) The resulting database size would be 200 GB without any indexes or other data structures. 

D) To create a sha256 merkle tree on these accounts would require 64 GB

E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB

Conclusion:  The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.   

The end result is that the account tree and full-block chain system have identical support for transaction volume, with only about a 6x gain in data storage efficiency or break even with 6 years of transaction volume.

Clearly the bandwidth is the bottle neck of scalability and not the data storage.    If you allow the bandwidth to scale enough to accommodate the transaction volume of VISA then everyone would require a 1 Gigabit connection to the internet at which point you are already well beyond the scale of the average individual and well into the realm of centralized financial institutions which would be logging every transaction forever anyway, the account tree system would just be extra book-keeping for these organizations which would probably maintain a separate index optimized for their queries.

A decentralized blockchain is transaction rate limited, not storage limited.   If the only change you made to the blockchain was to automatically expire / invalidate any unspent output more than 12 months old you would solve the data storage problem, the dust problem, the bootstrap problem, and the lost-key problem.   And you would be left with the same scalability problems as the account-tree based approach. 

What I conclude is that the account tree system at most provides some benefits for medium-scale systems involving perhaps 1 million users but is entirely irrelevant once you scale to the size Bitcoin aims to achieve.

wow you clearly have a deep understanding of the limitations of the bitcoin protocol. this post alone has caused me to value your input so if you dont mind me asking, how do you believe the scalability problem will be addressed?

[bytemaster]

The solution to scalability must be parallel chains each supporting perhaps 500K users max.   Unfortunately, this would mean that there would be 1000's of crypto currencies and markets for trading between them as they would not be fungible.   You would need a crypto-currency that had some other properties that drive its value so that it is effectively pegged against some outside unit of value while still remaining 100% trust-free.  As a result it wouldn't matter which 'alt-chain' you were on, your unit of account would be dominated in 'silver'.

I believe there is a continuum between decentralized, trust-free and expensive and centralized, trust-based, and cheap.    

I believe a blockchain must make a commitment to a maximum bandwidth that makes the chain accessible to everyone who can afford the fees for transacting on the network.   Enable efficient cross-chain-trading and most users would only need to live on one chain and could easily trade / spend to other chains as necessary.

The reason why I have thought about this problem very in depth is because of my work on the BitShares protocol which was attempting to utilize an 'account tree' like system.   There are significant space requirements for large merkle trees that only update a small fraction of the tree.  If you opt to save space on your merkle tree, you quickly become CPU bound.  Ultimately you realize you want a lot of 'mini-merkle trees', say one every 10 minutes, and that is when I realized why Bitcoin had to be implemented like it is.    

*edit*   One additional feature of all of these chains is the requirement that all transaction outputs be spent within 12 months so you can limit your long-term storage requirements to something that the average user could support.   This means that each user is committed to 1 transaction per year min and that will put an upper limit on the number of users who can possibly use a given chain to something around 1 million for a reasonable bandwidth and only a few transactions per year per user.

[bitfreak!]

Compare the traditional block chain to an account tree:
A) Lets assume we have an account tree where each account consists of a public key & balance and a some other relevant accounting totaling 200 bytes per account.

B) Lets also assume that the goal is for this to scale to 100 million users world wide and that each user has exactly one account.   This is not viable from a privacy perspective, so you would have to assume 10 accounts per user that rotate over time.

C) The resulting database size would be 200 GB without any indexes or other data structures.

D) To create a sha256 merkle tree on these accounts would require 64 GB

E) Assume you keep 1 month of transactions on hand for the mini-chain: 10 GB

Conclusion:  The account-tree chain would require ~300 GB of storage and each user would still be limited to about 2 transactions per month.  

The main thing that you are not taking into consideration is the fact that we wont reach 1 billion accounts in the account tree for an extremely long time, and by then it wont be unreasonable to expect people to deal with those sorts of large data sets (presumably). Now calculate how long it would take for the bitcoin blockchain to reach 300GB at the current rate of growth. Not too long I'm willing to bet, even with good pruning.

Furthermore, each account will be much smaller than 200 bytes, it will be closer to the 54 byte example you gave on the last page. No higher than 80 bytes in the worste case. If we assume 60 bytes instead of 200 bytes per account you'll find that it's only 55 gigabytes required. Also, the mini-blockchain will probably keep 1 weeks history or less, a full month is far too long if we need to account for very large transaction rates.

EDIT: But I do agree the system is not perfect and has its limitations, like any decentralized system. The answer is multiple competing crypto-currencies as you mentioned in your last post. But I don't think we would need thousands or even hundreds of coins, if we were to use the mini-blockchain / account tree scheme for those crypto-currencies, a few dozen or so could handle the entire worlds transaction needs I believe.

[lexxus]

Some thoughts on the merits of an account tree approach:
...

Btw what do you think about scalability of Ripple?

[slothbag]

Btw what do you think about scalability of Ripple?

Great question, something I'd like an answer too also.. Ripple seems like the perfect fit for a multi currency scenario, dozens of crypto currencies could be traded seamlessly and easily using another decentralised solution.  But then if Ripple was capable of sustaining world wide transaction volume then why bother with a dozen other crypto's? Just stick with XRP or something similar using the protocol.

From what I understand of the consensus approach is each transaction is actually broadcast amongst validators multiple times until consensus is reached, therefore I would assume bandwidth consumption is perhaps higher than bitcoin when comparing similar transaction volume.

Edit: Oh yeah, and after only 6 months of low transaction volume the storage requirements for ripple are more than the bitcoin blockchain after 4-5 years.

[bitfreak!]

Some thoughts on the merits of an account tree approach:
...

Btw what do you think about scalability of Ripple?

Well until we actually have a purely P2P and open source version of Ripple in operation that seems like a mute question to me.
The only reason Ripple is able to do some of the things it does is because it makes use of centralized servers.

[lexxus]

Some thoughts on the merits of an account tree approach:
...

Btw what do you think about scalability of Ripple?

Well until we actually have a purely P2P and open source version of Ripple in operation that seems like a mute question to me.
The only reason Ripple is able to do some of the things it does is because it makes use of centralized servers.

Yeap. I think if you want fast VISA-like transaction processing centalization (like Ripple today) or at least fedearation (like OT today and hopefully Ripple in the future) is inevitable. But frankly speaking scaling is still a minor problem unless you really want to compete with VISA. I would happily trade it for additional "extensibility" and rich functionality.

[Anon136]

The solution to scalability must be parallel chains each supporting perhaps 500K users max.   Unfortunately, this would mean that there would be 1000's of crypto currencies and markets for trading between them as they would not be fungible.   You would need a crypto-currency that had some other properties that drive its value so that it is effectively pegged against some outside unit of value while still remaining 100% trust-free.  As a result it wouldn't matter which 'alt-chain' you were on, your unit of account would be dominated in 'silver'.

I believe there is a continuum between decentralized, trust-free and expensive and centralized, trust-based, and cheap.    

I believe a blockchain must make a commitment to a maximum bandwidth that makes the chain accessible to everyone who can afford the fees for transacting on the network.   Enable efficient cross-chain-trading and most users would only need to live on one chain and could easily trade / spend to other chains as necessary.

The reason why I have thought about this problem very in depth is because of my work on the BitShares protocol which was attempting to utilize an 'account tree' like system.   There are significant space requirements for large merkle trees that only update a small fraction of the tree.  If you opt to save space on your merkle tree, you quickly become CPU bound.  Ultimately you realize you want a lot of 'mini-merkle trees', say one every 10 minutes, and that is when I realized why Bitcoin had to be implemented like it is.    

*edit*   One additional feature of all of these chains is the requirement that all transaction outputs be spent within 12 months so you can limit your long-term storage requirements to something that the average user could support.   This means that each user is committed to 1 transaction per year min and that will put an upper limit on the number of users who can possibly use a given chain to something around 1 million for a reasonable bandwidth and only a few transactions per year per user.

Hm i think off chain transactions for small to medium sided transactions and the blockchain for large transactions and as a clearing house to be used by the firms that provide the off chain accounting is a better solution than 1000 blockchains.

[bytemaster]

The market can balance the # of chains vs the trx fees vs the demand for decentralization.  You would only have 1000 chains if there was high demand for decentralization.

There is another technique that is probably just as effective as account trees and that is the use of smart compression of both the transaction data transmitted and the database.

In the current block chain there is a ton of redundant info:  same address in multiple transactions, trx id referenced once for each input is stored multiple times if a trx has many outputs.    These are all 32 byte numbers that could be reduced to 4 to 8 bytes and yield a 50% savings for the second use and 75% for each subsequent use.     With a proper protocol for agreeing on what these identifiers are (say first bits... ) I estimate you could double the transaction volume for equal bandwidth and half the data storage requirements.

Combine this with a financial incentive to generate transactions that have more inputs than outputs and a one year maximum chain size and a DHT for storing 'pruned' transactions and you would have a solution that would probably be about the same size as the account tree.

[bybitcoin]

Hi BitFreak!
Nice idea and scheme, actually had an open eye on this thread for about a month. But since I didn't know how I can help, didn't jump in before.
I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)
Still if the problem is about finding developers to implement it, then why don't you try to use the Python framework (as the head and glue) to define and construct the building codes and then write integrate the parts into it by using other proper languages like c or java or whatever. In that case, I may also be able to contribute a part to the development.

[lexxus]

I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)

Will you be interested in trying out a strong privacy schemes like zerocoin? When the prototype will be ready, you could really help with that as there are not many people around who really understand all the details of it.

Regarding doing everything in Python: there is no solid codebase like in case of bitcoinj that we can use and python won't give much of the advantage in development speed compared to Java. So it doesn't make much sense to do a rough prototype in Python and then throwing it away.

[bybitcoin]

I am a math graduate, with specialty in Algebraic Number Theory, but not much of an expert programmer (don't like it much)

Will you be interested in trying out a strong privacy schemes like zerocoin? When the prototype will be ready, you could really help with that as there are not many people around who really understand all the details of it.

Yes I will
Regarding doing everything in Python: there is no solid codebase like in case of bitcoinj that we can use and python won't give much of the advantage in development speed compared to Java. So it doesn't make much sense to do a rough prototype in Python and then throwing it away.
[/quote] I just meant using python as a glue and accelerator, but you seem right, Java would be a cleaner and wiser choice.

[stellarman]

What other help is needed on this project. I believe in what you are doing, and would like to help, but I am not a programmer.

Is some development occurring?

[fellowtraveler]

Is this project going to support colored coins and multi-sig ?

Both are important to my own project.

[bitfreak!]

Is this project going to support colored coins and multi-sig ?

Both are important to my own project.

Yes it should be capable of handling multi-sig transactions and other types of complex transactions like bitcoin, but probably not all the types of transactions that bitcoin supports. And I'm not exactly sure how colored coins are supposed to work, but it seems like something which is layered on top of bitcoin and I see no reason it couldn't be layered on top of the mini-blockchain scheme in a similar way. Of course we could include something in the protocol which makes it easier to "color" coins. I'd need to look into the colored coin idea more before giving you a proper answer.

[fellowtraveler]

Is this project going to support colored coins and multi-sig ?

Both are important to my own project.

Yes it should be capable of handling multi-sig transactions and other types of complex transactions like bitcoin, but probably not all the types of transactions that bitcoin supports. And I'm not exactly sure how colored coins are supposed to work, but it seems like something which is layered on top of bitcoin and I see no reason it couldn't be layered on top of the mini-blockchain scheme in a similar way. Of course we could include something in the protocol which makes it easier to "color" coins. I'd need to look into the colored coin idea more before giving you a proper answer.

Colored coins allow you to use the blockchain for issuing real-world assets. Like issuing "gold ounce" units that are tracked on the blockchain.

In OT, this is useful for divorcing the issuer from the transaction server. (It works in combination with multi-sig.)