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

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.

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



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

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.

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

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.

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.

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

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.

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.

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.

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.

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.

*EDIT* it could happen that the last block is invalid, but the probability for that is quite low. Why would anyone try to mine an invalid block, because after a few seconds/minutes everyone has all block contents and would discard the block.

If that would work then Bitcoin could propagate just block header and achieve same thing. Problem is that without block contents you cannot verify if block is valid and without knowing included transactions you can't start working on next block.

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

+1
I hope this will be a priority, because the concepts of proof-of-stake are now available and working. It just doesn't make sense to further waste energy and resources. Why would someone want to create a new alt-coin with inferior techniques if new ones are available?
*EDIT* you could even use this approach to implement incentives to not have too many different addresses in the account tree, right?

Just another thougth (don't know if it was mentioned before):
The mini-blockchain has also the advantage that new blocks can be propagated through the network much faster because it just needs to propagate the proof cell(~ 100 byte) without propagating all transactions (~1 MB). So it should be 10000 times faster to propagate. Of course you would have to wait a little until you see the included transactions, but to start mining the next block it would be enough to have the proof cell... Is that correct?

Generally my idea is in principles similar to yours. It uses account withdrawal limit to ensure that offender cannot empty his account in alternate chain in less than 6 blocks so honest transaction still can be included even after 5 block chain reorganization. This is coupled with double spend detecting and punishment. Detail needs to be ironed out yet but I think it would work. I am currently exploring idea to make this thing working universally for all accounts by prioritizing small payments over large. Large payments wouldn't be executed at moment of inclusion in blocks but later. If in mean time some smaller transaction were included big tx is cancelled. Result would be that small payments (for less than 1/6 account) would be instant while larger would take more than 6 blocks to confirm. I don;t have details yet.

Description is added to wiki.
http://bitfreak.info/mbc-wiki/index.php?title=Secure_0-confirmation_transactions
http://bitfreak.info/mbc-wiki/index.php?title=Punishing_double-spending

BTW We should really name this project. It don't need to be final name. Maybe evercoin [like coin sustainable for ever;]?

Love the project. New features are key.

Here is what I would like to see:

1) proof-of-stake

There are multiple reasonable ways of doing this. Once I understand your design better, I'll suggest some simple proof-of-stake system that is compatible with your approach.

2) reduced blockchain size

What you are doing sounds great. I will be reading and thinking about your paper carefully. Don't stop here though.

3) improved wallet security

Basic idea is an account with restricted authority. You could keep the account online 24/7 without risking loss of all its coins. You would not need to mess with paper wallets under normal circumstances. This would make a hot wallet almost as safe as a bank account.

This account does the following:
a) specifies a single trusted address when it first receives coins (the address cannot be changed subsequently, address could belong to an online service provider, an offline paper wallet, a friend, whatever)
b) specifies an amount of coins, x, when it first receives coins. Account can send x coins per month (or week) to any address. Once this limit is up, further spending is not possible with one exception.
c) emergency withdrawal; account can send any amount of funds to its unique trusted address at any time.


4) zero-conf txns

I suggested something for zero-conf txns here: http://www.reddit.com/r/CryptoCurrency/comments/1evxuk/how_toalt_coin_with_secure_zeroconf_txns/
I think aaaxn must have proposed something similar. Aaaxn, what's the link for your idea again?


BTW 2864285 is cunicul keyed into a touchtone phone

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?

Yeah bitcoin is tested so it works good as bitcoin. You know what is the problem with messy code-base? Any little change can cause some serious bugs. And we are not planning to do little changes. After our modification extensive testing would need to be done no matter on what code we will base it.
I don't insist on btcd, they won't probably finish anytime soon anyway.
Litecoin developers recently announced they are doing some serious work around their code so i may be good choice.

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.