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

[aaaxn]

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow

I would add that application have typically only small portion of code which must be really optimized (in bitcoin it is probably tx verification) and if our coin would become so widely used so that would become bottleneck this small part can always be rewritten in C without modifying anything else.

But that's the whole idea of the proof-chain. You can verify the proof-of-work without needing the whole block.
Of cause if you start mining the next block and you just have the previous proof-cell and not the transactions, you could only include transactions which are not very old to be sure that they were not already included in the previous block.

Yes you can verify proof of work, but you cannot verify what node was working on
If you don't know which tx were included in previous block you cannot verify if tx is valid (maybe account was emptied in previous block?) and you don't have previous ledger state so cannot compute new ledger state for next block.

[1715397266]

1715397266

[1715397266]

1715397266

[1715397266]

1715397266

[1715397266]

1715397266

[Anon136]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

[aaaxn]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

Blockchain bloat is not only about storage. Every node must verify every tx ever done from block 0 in order to synchronize with network it can take a lot of time. As for tps limit I think we can make single transaction significantly smaller than in bitcoin (2-3x reduction for average tx) so we can get more tps with same block size limit.

[cunicula]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

What is the bottleneck here? bandwidth? verification speed? Could someone explain for me.

[bitfreak!]

Any little change can cause some serious bugs. And we are not planning to do little changes.

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?

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow

Yes, it is certainly a problem.

[bitfreak!]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

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.

[lexxus]

Any little change can cause some serious bugs. And we are not planning to do little changes.

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?

Speed for client is not a problem. Go was just 10x slower than C++ in benchmarks. But I don't see it as a problem.
see, http://stackoverflow.com/questions/2704417/why-is-go-language-so-slow

Yes, it is certainly a problem.

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:

1. It's almost the same speed as C/C++ (worst case it's 3x slower only)
2. It's objectively the most secure, battle-hardened, portable virtual machine ever created
3. It has a huge set of libraries to boost the development (p2p, cryptography, UI, etc)
4. It supports a lot of languages Java, Scala, Clojure, JRuby, etc.

[bitfreak!]

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:

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

[aaaxn]

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:

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

Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.

[lexxus]

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:

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

Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.

There is also http://code.google.com/p/bitcoinj/

bitcoinj implements both the lightweight "simplified payment verification" mode of Satoshis paper which does not store a full copy of the block chain

This is a part we have to re-write anyway.

[bitfreak!]

Well, I still don't see it as a problem.
If you believe this is the problem, then I would advise looking into Java VM:

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

Speaking of java. There is fairly complete(?) implementation of bitcoin in java:
https://github.com/bitsofproof/supernode
It is already fairly tested and under active developement.

I didn't look into it yet, but I guess it is well structured and would me easier to modify than satoshi client.

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.

There is also http://code.google.com/p/bitcoinj/

bitcoinj implements both the lightweight "simplified payment verification" mode of Satoshis paper which does not store a full copy of the block chain

This is a part we have to re-write anyway.

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.

[scooter]

Java is for chumps. 
FORTRAN 4 EVER!

[aaaxn]

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.

I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.

[Anon136]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

What is the bottleneck here? bandwidth? verification speed? Could someone explain for me.

bandwidth

[lexxus]

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.

I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.

I'm neutral between bitsofproof and bitcoinj.

[nomailing]

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.

I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.

On the other hand bitcoinj is probably used in more open-source wallet applications. This would be very useful if the new coin is successful.

[johnyj]

The problem with blockchain is that when transactions get more and more, the whole network will be stalled due to the same transaction must be broadcasted to the whole network no matter how small they are. I don't see how this new design can prevent that from happening

I agree that recording all the transactions is stupid, should be enough with a ledger of account balance

[bitfreak!]

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.

I vote for bitsofproof. Its commercial nature is a plus, because it usually comes with better code quality. And imagine our project is successful and new coin is almost automatically compatible with businesses of all bitsofproof clients. Good for us.

On the other hand bitcoinj is probably used in more open-source wallet applications. This would be very useful if the new coin is successful.

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.

[aaaxn]

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.

And bitcoinj code is far more documented. My first impression was wrong, bitcoinj seems to be more suited for our needs.

[cunicula]

blockhcain bloat isnt really the big problem here. ordinary computers come with a terabyte of storage space these days. what you really need to solve is the limitation on the total number of transactions per second that bitcoin can process without causing the system to become more centralized.

What is the bottleneck here? bandwidth? verification speed? Could someone explain for me.

bandwidth

Is 200 kB/s managable? That is like 400 txn per second for transmitting txns. And then blocks of about 100 MB every 10 minutes, so a total of about 400 kB/s.

Plenty of household computers in the US could handle this, right? I'm still not understanding the problem.