We will have a github repo up very soon and it would help if you could contribute to the project. We plan to work with bitcoinj, are you any good with Java?

I don't believe that merged-mining is part of this scheme, although it would be a part of something like the ultimate blockchain compression scheme. It seems like you still aren't fully understanding the way this new scheme is designed to work.

Yeah I agree we should make the currency code begin with an X. And I would prefer to leave "coin" out of the name unless someone thinks of something extremely clever which hasn't been used already.

No we haven't set up a main repository yet because we are still deciding on some of the details. If you read through the thread you'll see we decided to go with bitcoinj instead of bitsofproof, so if you want to start anywhere, start by looking at bitcoinj. Hopefully we'll have a repository set up soon so some of you can get to work, we also need to decided on a nice name for the coin before we can set it up.

Well if you've written trading software in Java you should be able to help out with some of the coding, perhaps not the hardest parts but I'm sure there's a lot you could contribute.

BTW I want to thank who ever made that recent donation. When we create a website for the new coin we might need to add a section for recognizing donators.

Ok well we can all agree on that. I might add to the opening post that we plan to work with bitcoinj and thus require Java developers.

Yeah plenty of household computers in the US could handle it, but the US isn't the world, and we are designing a global crypto-currency which will be used by people all around the world, many of whom will have fairly slow connection speeds, especially upload speeds. One of the benefits of the mini-blockchain scheme is that mining doesn't have to become a highly specialized and centralized industry because almost anyone can handle the size of the mini-blockchain. The aim should be to exclude the minimal amount of nodes possible, meaning we need to take into consideration the connection speeds of people all around the world. So even though many people may be able to handle a huge number of transactions per second will still need to balance it and place a cap on it. This is why I believe a dynamic max block size is necessary, because this isn't something which will remain the same over time. In the future the majority of people will have much faster connection speeds.

The code quality of bitcoinj doesn't look too bad either, apparently it was written by a guy from Google. And it has been under development for more than 2 years now, which seems to be a lot longer than bitsofproof has existed.

I hadn't ever heard of that, it actually looks fairly decent and well tested. The only one potential problem I can see with it is that it seems to be slightly commercialized software. But I doubt that would really lead to any problems.

You do also make a valid point about having to re-write the payment verification part. And I do like the GUI of the MultiBit client (it uses bitcoinj). I would definitely be open to using this because I know it has a lot of testing.

If you guys are really set on making this in Java I could accept using bitsofproof or bitcoinj as long as the other develops who come along agree with it. Personally I would prefer to go with bitcoinj if we did go with one of them.

What would be the point of building a whole new implementation when we've already got a lot of the code done for us. This is not a project to build a totally new crypto-currency from the ground up, it's more like an effort to "re-factor" the existing Bitcoin code into the mini-blockchain scheme. There is no good enough reason that I can see to move away from C++.

The Bitcoin client is artificially limited to 7 tps because of blockchain bloat. If the transaction rate was much higher the blockchain would grow extremely quickly and no one would be able to handle the growth. But with a mini-blockchain which is trimmed we don't have to worry about that problem so much and we can increase the transaction rate by a lot. And also as aaaxn mentioned, each transaction should be reasonably smaller in size.

Yes, it is certainly a problem.

That is a valid point but we will still be able to re-use a fairly large portion of the existing code base because many things will stay the same. I also think we need to keep in mind the speed factor, how fast is the Go language?

C++ may not be the nicest language but it is the fastest and Satoshi made Bitcoin in C++ for a reason. Remember the goal of this project is to try and take the safe road, stick as close to Bitcoin as possible. Using an entirely new Go implementation which has just been built from the ground up is simply for asking for trouble. Maybe if it had already been tested for a year or two I would go for it but at this point I would be strongly against such a plan. It can't be that hard to work with the C++ code considering how many Bitcoin variants now exist. Even if the code really is as bad as some people make it out to be, at least we know it's tested and secure with many years of operation in the wild. Plus there is probably way more information and references concerning the default implementation, at the end of the day it'll probably be easier to fork a C++ implementation such as Litecoin and alter the code to fit our needs.

The ability for zerocoin-like anonymity and also the ability conduct secure 0-confirmation transactions are definitely two things at the top of the to-do list after we get a working implementation. The GUI can always be made more complex as we move along so I don't think that should be of particularly large concern right now. But I do feel what you are saying, the Bitcoin GUI could definitely use some more features, especially the ability to easily import private keys.

Thanks for the donation btw, every little bit helps.

Based on my rather poor understanding of zerocoin I would say that you are correct because you could create special zerocoin accounts in the account tree or something along those lines. But the implementation of such a system would probably increase the rate of growth of the account tree by a lot, and this scheme does provide a bit of extra anonymity already.

On an unrelated note, I found this new forum advertisement kind of ironic:
"I'm sure that in 20 years there will either be very large transaction volume or no volume." -- Satoshi

Agreed.

I'm not really sure how colored coins work but my guess would be that the account tree ledger system in this scheme may not provide the facilities for colored coins.

Excellent, even if you cannot help with core development we need as many heads as we can get on this and I appreciate the help. So far we have aaaxn and you, hopefully we'll get a few more experienced developers soon and then we can start to put something together. We also need to decide which coin we are going to start off with, I'm thinking a straight up Bitcoin fork (although Litecoin or something may be better if we plan to have scrypt-based mining).

It's impossible to keep the difficulty down at a CPU-friendly level because the difficulty must shift according to the total amount of hashing power miners are throwing at the network. Without changing the difficulty in that way we cannot control the rate at which new coins are created. Obviously though we do plan to include some sort of scrypt-based mining system to make it more ASIC resistant.

I don't think that is necessarily a good idea, the decimal point never needs to change within the protocol, it can simply be represented differently when displayed, for example you can denote BTC in mBTC etc. The reason you have so many decimal places in the first place is to account for large shifts in value, there's no need to further complicate it by shifting the decimal place within the protocol as you seem to be suggesting. One quadrillion units is certainly enough to provide sufficient granularity (but I don't see any real reason we couldn't make it much higher).