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.

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.

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.

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.

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.

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.

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.

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.

Well that's why it uses RSA public key encryption to secure the private keys. The RSA keyset is generated using a Javascript interface within the client window so the server will never be aware of the private key.

In any case, it should help you with generating bitcoin addresses in PHP. What you want to look at is the lib/bitcoin.lib.php file.

Take a look at my Bitcoin SCI script for help with generating bitcoin addresses in PHP:

http://bitfreak.info/?page=tools&t=bitsci

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.

I'm not sure what you mean by "how does the mini-chain agree on the initial condition", I assume you mean how do new nodes agree on which mini-blockchain is the correct one. An attacker trying to build upon the real proof chain would need to keep up with the hash power of the real chain for a full cycle in order to pull off the attack you brought up. And the attacker would have to do it in secret for a full cycle of the mini-blockchain before broadcasting the fake chain in order for new nodes to be unable to detect it was fake. Obviously such an attack would be extremely difficult to pull off, and I doubt it would ever actually happen. But if it did then the contingency plan described by aaaxn is perfectly adequate for dealing with it. If a new node detects two competing chains which originate from the same proof chain and it cannot determine which is the real one it will simply refuse to participate in the network until the situation is resolved or until the client is updated with the latest checkpoint.

I really don't understand what you are talking about, the transactions are stored within the mini-blockchain like the normal blockchain. When a block is trimmed from the mini-blockchain the transaction data is discarded with it but the block header (or proof cell) is kept as part of the proof chain. When a new node connects to the network it doesn't rely at all on validating transactions, the new node simply attempts to obtain the proof chain with the highest cumulative difficulty and then obtains the mini-blockchain associated with that proof chain. If the new node detects two competing chains which originate from the same proof chain it will execute the contingency measures described by aaaxn. There is no point for a new node to validate transactions when synchronizing because the whole idea is to discard old transaction data and rely solely on the proof chain to prove which mini-blockchain is the right one. Once the new node is properly synchronized with the network it will then start validating new blocks as it receives them, like any normal node. There is no need to track all the unspent outputs or anything else, and in fact there is no such thing as unspent outputs in this system because it uses an account ledger.

Oh ok, well that makes a bit more sense then. Personally I think the bit postage idea is worth building first because even if you can't support massive file attachments it would still be nice to use bitpostage coins to pay for postage, or something like that, instead of having to generate the proof of work with each new message you want to send. That was the basic idea right?

Well so far it seems like BitShare is going to function as a Decentralized Exchange / Messaging System / Storage Network. It's a very different project from this project, it will require much more work and effort to build a system which is capable of providing all that functionality in one package.

This project is an attempt to bring together many new ideas, but those ideas are basically just focused on creating a more efficient and speedy crypto-currency, not to build a multi-function alt-coin designed to do all sorts of weird and wonderful things. It is designed and streamlined for one job only: to be a virtual currency.

BitShares sounds like a decent idea, but then again I think some of these systems simply work better by themselves and don't need to be integrated into one unified platform. Torrent technology and file upload services already provide all my storage needs and I wouldn't care about using BitShare for that.

Likewise, all my messaging needs are already taken care of by free email and chat services. For secure encrypted email I some times like to use Bitmessage because it provides all the functionality I need and avoid spam. If I needed to safely send a large file I'd just encrypt it and then upload it to the net.

However I will say that if a decentralized system can be designed which is capable of handling messages and large file attachments, with the ability to pay to have messages sent quickly, that would provide advantages over Bitmessage, but I'm sure there will be scalability issues and other difficulties in attempting to build such a system.

And what would happen if the balance of the receiving account changes before the transaction is accepted into a block? What you suggest would still produce signed transactions, the data being signed is simply different, and signing the balances is not the best way to do it.

The proof chain is simply a container of expended energy, all it needs to do is prove that some sort of work was done. aaaxn already gave a link to where we discussed the issue you brought up. It's really a minor issue because chances are it would never happen and if it does happen we have a good failsafe plan mentioned by aaaxn:


It's really only new nodes which would be at risk so dealing with it in that way is acceptable.

Ok after some discussion with other members, the name has been decided and a github repo has been created.

The name we are going with is Peercash and the repo can be found here (it's still empty right now):
https://github.com/peercash/peercash

Currency code: XPC

The name probably isn't as awesome as it could have been but it was hard to come up with something unique and with the domain name still available. Still I think it's a pretty good name and describes what the project is about so I'm not unhappy with the decision.

The concept is still being fully developed in the project wiki and aaaxn probably wont be around for a little while, so the real development still hasn't started yet. However if anyone wants to start contributing to the project repository that is fine.

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.