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

That's a good point to keep in mind as well. Now looking at the current average block size for the Bitcoin network it appears to be at about 0.125MB. At a rate of 1 block every 10 minutes the Bitcoin blockchain should be growing at a rate of something like 125MB every 7 days. I think a full week is an ideal amount of history for the mini-blockchain. So adding it all up, if the Bitcoin network were to be converted into a mini-blockchain scheme right now each node would only need to download something close to 200MB in order to become fully synchronized with the network and operate as a full node. Compared to the 8 gigabyte blockchain the advantage is clear.

I think a lot of addresses are created "by accident" because of change sending. User wouldn't intentionally create them so account number in ledger system might be smaller.

Probably even smaller because I'm sure there will be ways to compress data in the account tree.

Well what I can conclude is that incentive isn't enough and if we want to take crypto-currency to the next level we need something like a mini-blockchain scheme. Although if you are forced to use the old transaction model for BitShares then your only hope may be to provide incentives.

Those are some very interesting numbers, 1.6 million addresses each of which requires the following information:

1) Block              4 bytes (last change)
2) Balance           8 bytes
3) out Script       40 bytes
4) Unit                2 bytes

The result would be about 100 MB scaling with the number of users.   

The bitcoin block transaction fee system is perverse and does not encourage users to combine outputs and in fact makes it uneconomical to do so.   There are about 1M net new unspent outputs every month for the past several months.   Many of these outputs are SDICE and mining pools which are making small transactions. 

What I can conclude is that with proper incentives you could cause the unspent outputs to approximate actual accounts in number. 

http://bitcoin.stackexchange.com/questions/2828/how-many-bitcoin-addresses-are-have-been-carrying-a-balance

If that link is anything to go by the number of non-empty addresses stayed at about 600,000 through 2011 and 2012, although it might be higher now. I can't be certain exactly how large each account in the account tree will be, but you can see how that is an extremely small number even using the most conservative estimations.

EDIT: here's another interesting link:
http://bitcoin.stackexchange.com/questions/10850/how-many-bitcoin-addresses-are-there?rq=1

The top answer states that as of 12th May 2013 there were 1.6 million Bitcoin addresses which carried a positive balance, although the writer of the answer doesn't provide any links our sources for his answer, unlike the answer in the first link.

No I don't think I have. I have done what I just said though, I calculated how fast the account tree should grow but I can't really remember the result which I why I didn't give exact figures (based on all unique addresses seen by the network). I'd have to do the calculation again when I have a free moment.

Have you actually calculated the total number of unique addresses with non-0 balances vs the total unspent?  I suspect the majority is people with automatic mining pool payments every .01 BTC that have not 'spent' them together yet.  Create financial incentive (like dividends / fees) to combine this kind of thing and we are not far off in data requirements.

Yes that is correct, but you don't really need to do any of the calculations you did to work out how fast the account tree will grow. Simply look at what fields each account in the account tree holds to workout the size of each account and then you can look at how fast new addresses are introduced into the Bitcoin blockchain to get an idea of how fast it will grow. Even if you take every single address the Bitcoin network has ever seen it's still quite small in size. But obviously not all the addresses that the Bitcoin network has seen remain unempty, and the account tree can drop all the non-empty addresses.

Trust me I know it doesn't take much to be superior to the bitcoin blockchain.  It just takes a lot to actually work without compromising security.    In theory the limit you face is on total unique accounts rather than transaction volume.

I did an analysis of the Bitcoin blockchain and looked at just unspent transaction outputs over time.   You immediately get a 8:1 compression.   If you can eliminate the need to store the inputs to the unspent outputs you end up with 16:1 compression.     Lastly, when you provide fees for creating new unspent outputs and don't charge people for large transactions that merge dust along with taxing all unspent outputs over 1 year old (to keep them fresh and prove private key ownership wasn't lost) then you end up with about 32:1 compression on the data that must be stored.  In effect, the current bitcoin transaction volume / user base would only require about 400 MB of data that would grow proportional to the user-base rather than proportional to transaction volume. 

In your system you compress it one step further by always merging all 'balances' into one address.   In my system I create economic incentives for users to do this but do not require it due to other implementation/security challenges.  Therefore, I would guess that the theoretical gains of compressing down to just one output per address would be very small compared to where I think BitShares is now and it comes at a cost that limits flexibility on dividends.

Yeah but the mini-blockchain scheme will be much more efficient than the ultimate blockchain compression scheme and it should be easier to implement. Plus it should have several new features including secure 0-confirmation transactions and other things which no other alt-coin has. Once it has been implemented you will be able to fully understand why it is so superior to the old blockchain scheme, assuming it works of course.

I understand that you are merging all unspent outputs with the same script into a single balance.  After much thought and consideration, using account balances creates challenges that are intractable when it comes to paying dividends and several other things.   By using unspent outputs and charging fees anytime a transaction creates more unspent outputs than it consumes and several other things market forces will align to minimize the number of unspent outputs. 

If you do create the next generation crypto-currency then it should probably offer something other than just reduced resources.  There is already someone working on ultimate blockchain compression. 

That is just really confusing. The account tree isn't a collection of unspent outputs, because all the unspent outputs are merged into a single balance for any given address. When dealing with an account tree you're probably over complicating the matter by referring to is as such.

Yes I suppose that would be possible but at this point we're still going with Java and if we did fork BitShares we couldn't start coding our project simultaneously. BitShares seems like it will be fairly complicated and I doubt much of it will really be what we need for Peercash anyway. And the more sensible way to do it would be to build Peercash first and then build BitShares on top of that if we were going to work together.

I have a team of 3-4 developers that will be working to implement BitShares in c++ over the next couple of months.  BitShares will be implementing many of the features described in this thread in an attempt to reach the same goals.   

I have significantly revamped, updated, clarified, and extended the BitShares white paper:

https://docs.google.com/document/d/1RLcjSXWuU9vBJzzqLEXVACSCdn8zXKTTJRN_LfoCjNY/edit#

It will have the following characteristics described in this thread:

1) Rolling / Minimal Possible Transaction History (mini-blockchain)
2) 'account tree' which I call 'unspent transaction outputs'
3) Merged Mining / Proof-Chain
4) Potentially the 0-confirmation (spend limit)

While BitShares will implement many other features, they could be easily removed in a fork that implemented only the subset described here. 

The white paper is open to comments on google docs and I am actively looking for additional feedback and developers.  To the extent that we can pool resources the better.

Yes we do but it's still empty: https://github.com/peercash/peercash

We are still lacking a team of core developers but if anyone wants to start working on the code I would welcome it. It's harder than I expected it would be to get some good programmers in on this project. I think once we get started on the code things will naturally progress at a faster rate and more programmers will be attracted to the project. And it's not like the project is totally unfunded so contributions will be rewarded.

And I'm still not entirely sure whether working in Java is the best idea. Would you prefer to work in C++ or Java? It seems most of the good bitcoin programmers are better with C++ so I'm not sure that building it in Java is the best idea after all. We need to decide this carefully before writing the first line of code.

Awesome! I have proposed the "rolling chain" concept myself. It's the future for sure.

Do you have a code repository up yet? I absolute would like to contribute to this project.

Well when I read the MC2 white paper a few weeks ago I noticed that it does also make use of a "novel hash tree" but the use of the hash tree is much different. MC2 appears to use a polymorphic hash tree as part of the PoW mechanism, where as Peercash will use a hash tree database for storing information about non-empty addresses so that old transaction data can be discarded. As the MC2 white paper states "The principles of both LTC and PPC are extended in Memcoin2", meaning MC2 is mainly focused on making the PoW protocol more robust and memory-hard and combining that with the PoS concept.

Peercash changes things on a much deeper level. We are totally rethinking the way that crypto-currency needs to work in order to create a more scalable and speedy coin. This is achieved with new mechanisms such as the account tree and mini-blockchain. We most likely wont integrate PoS into the system but are developing concepts which will allow secure 0-confirmation transactions and a dynamic max block size. I hope this has answered your question, but you can always read the wiki or white paper if you really want to understand the idea.

Can someone indulge me on how is MC2 and Peercash different in handling the blockchain?

Thanks in advance!

Interested. Keeping an eye on this.

So you're suggesting that the length of the mini-blockchain should be dynamic? I'm not sure if that's really a good idea because many other calculations depend on the length of the mini-blockchain. The concept as it is now is to use a statically sized mini-blockchain (as in the number of blocks is fixed) which would probably hold something like a day to a few weeks of transaction history. However nodes could have the ability to store more older blocks if they wanted. And as aaaxn mentioned, new nodes could ask for those older blocks as a way to help them detect fake chains. Although there would be no requirement for anyone to save the older blocks and things should work perfectly fine without them.

That works, so the contribution I believe I made is that by looking at the most difficult block difficulty you can determine the maximum mini-blockchain length required.... you may be able to go shorter.