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

[bytemaster]

2) 'account tree' which I call 'unspent transaction outputs'

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.

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

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

[1714184471]

1714184471

[1714184471]

1714184471

[1714184471]

1714184471

[1714184471]

1714184471

[1714184471]

1714184471

[1714184471]

1714184471

[bitfreak!]

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. 

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.

[bytemaster]

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. 

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.

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.

[bitfreak!]

In theory the limit you face is on total unique accounts rather than transaction volume.

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.

[bytemaster]

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.

[bitfreak!]

Have you actually calculated the total number of unique addresses with non-0 balances vs the total unspent?

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.

[bitfreak!]

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.

[bytemaster]

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. 

[bitfreak!]

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

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

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

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.

[aaaxn]

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. 

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.

[bitfreak!]

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.

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.

[BrightAnarchist]

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

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.

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

[fishy]

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

[bitfreak!]

Personally I can't stand writing code in Java (checked exceptions...),

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.

Also, recommend you call the unit XPC

Yes that is the currency code we are going with.

[bitfreak!]

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

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.

[lexxus]

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.

[daybyter]

What will be your target plattform? J2SE or Android?

[lexxus]

What will be your target plattform? J2SE or Android?

J2SE.

[daybyter]

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

[lexxus]

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.