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

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.

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.

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.

Btw what do you think about scalability of Ripple?

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.

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.

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?

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.

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.

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.

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

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.

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

J2SE.

What will be your target plattform? J2SE or Android?

If nobody else will kickoff the development, I will fork bitcoinj and start implementation in the beginning of August. I hope to be able to spend around 10-15 hours a week on this.

Well at this point I'm not too concerned with things such as the logo, but if you want to have a go at making a logo that's cool. I don't really know what info you need... the name of the currency is Peercash and the currency code is XPC. You shouldn't need anything more than that for the logo. I will use your logo if it's good but I can't guarantee it'll be used.

Well I don't really think Java is a bad language to write in, but I am feeling like C++ is a better option because most programmers who are familiar with bitcoin technology have worked with the C++ implementation and we might be able to get things done quicker if we go that way.

Yes that is the currency code we are going with.

I can make a logo if you would like, just shoot me a PM with the abbreviation and some info! 

Personally I can't stand writing code in Java (checked exceptions...), but I do acknowledge that bitcoinj and supernode are much furthur along than any other managed language implementation (such as bitcoin C#)

Also, recommend you call the unit XPC