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

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.

In theory we should avoid using bitcoin source, because it's a mess, but it also represents massive amount of work and it wouldn't be so easy to implement such thing from scratch.
Ideally conformal will finish their bitcoin implementation in Go (https://blog.conformal.com/) and we could base on that. It seems to be nicely abstracted and use much nicer language than C++. That would really speed up development.

Idea is to drop scripts and replace it with transaction/account types defined in source, so tx would be Turing-complete, but each new type would need to be accepted by majority.

I think we could leverage on a few libraries/technologies as a building blocks:

We could usde zeromq as a basic commnuncation library
DHT for client discovery and additional data storage (libtorrent?)
A lightweight (non-sql?) database for account tree and mini-blockhain indexing (leveldb?)

Also I would love to see a Turing-complete yet secure language for scripts.

It would be good to separate a project into several modules like connectivity, account tree, mini blockchain and assign them to different developers so we can start working on them in parallel.

PS: The last thing I want is to start a flame war on programming languages, but I would give a little time to consider other languages like Java/C#/Python/Ruby instead of C/C++ for the reference implementation.

Great proposal, I will donate to the bounty.

-Including a zerocoin-esque feature would be great, even if it's just what aaaxn described above. 
-Including certain features commonly requested in BTC would be great. Throwing Coin Control into the GUI, perhaps M of N support, etc.
-Heck, going the extra mile and throwing in cold wallet support in the GUI (like Armory) would give people even MORE reason to celebrate an alt-coin that is NOT just a copy-pasta with a couple minor changes.

I realize it's quite the laundry list, and all you really want to to is try out this new blockchain idea, which is a great idea, but also think of the potential success of an cryptocoin that really "Gets it right" - not just with one major innovation, but that major innovation with a few key features that folks are really looking for.

If you release a copy of the bitcoin-qt/litecoin-qt client with the only change being the smaller blockchain... well, it'll be simple, but it won't stand out quite as much as if you spend some time putting in some great features that people have been asking for in BTC for a while.

The problem with alt-coins is not just that they are copypasta of the bitcoin concept, but also that they are copypasta of the CODE, complete with spaghettification and ugly external dependencies and magic numbers. Many people have called for completely reconfiguring it to comply with good coding practices, and reduce the risk of nasty bugs that might show up later on. I know this is not your intention, to change too much at once, but anything you can do to this effect would be welcomed by the alt-coin community who, after FTC and CNC, have had it up to here with pointless copypasta introduced entirely for speculation. I think if I run another ______-qt executable that shows the same flash screen, same GUI, with no new features... I will facepalm. A major back-end change like what you've proposed with the blockchain almost makes it forgivable.

I think we can get secure coin laundry without complications of zero coin with Chaum's blind signatures.

It seems complicated, but from user point of view it can be just special button 'Send anonymously' which would automatically divide specified sum into mixing intentions, send it to network and claim tickets. It would cost more than standard transfers to cover additional network load. Its main disadvantage is that if you won't claim your tickets in time you can loose your money.

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

In case you are not familiar with it, zero-coin is a very interesting proposal by a very smart guy. See his blog entry about zero-coin here: http://blog.cryptographyengineering.com/2013/04/zerocoin-making-bitcoin-anonymous.html

In a nutshell, zero-coin is an extension for BTC that allows for completely anonymous transactions.

It occurs to me that having the account tree as a separate module might actually make implementing zero-coin easier than with BTC.

Although the basic implementation is itself a chanlenge, I would still try to keep in a backlog possible advanced features like multi-sig transactions, zero-coin like strong privacy, etc.

I also would like to look into the differences between Account Tree and Ripple Ledger structures as they seem to have something in common.

Agreed.

Account ledger does not keep track of coins so you can't do it exactly same as in bitcoin. If it would be really needed then nothing stop us from creating special colored accounts which can only move coins to other accounts of same color or to new empty accounts which are colored upon creation, but... I don't see reason to worry about it now. We need to implement basic system first.

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.

Am I correct, that mechanisms like colored coins, would not work with this kind of chain?

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

Why do you think that GPU/CPU would be more energy efficient compared to ASIC's?
ASIC's are much more energy efficient. You just pay more for the custom designing/manufacturing of ASIC's, but in the end with ASIC's you have much less power consumption.

*EDIT*: So in principle you can say less power consumption would automatically mean more centralization. The only way to have both (decentralisation and power efficiency) at the same time is if you use a hybrid of proof-of-work and proof-of-stake

Yes, I do understand the need for having a difficulty and the ability to change the difficulty. If the presence of the proof chain doesn't present a possible path to generally lower difficulties, then perhaps a change to the sCrypt that would use registers or features present in a CPU but not (currently) present in a GPU or ASIC -- or something. I don't know what the answer is, but would suggest and request that we all keep our eyes open for methods that would 1) allow for less wasted energy/resources in the mining process, and 2) keep mining more distributed. Just imagine, the MBC coin client is light enough for any and every user to easily be a full node, and the mining process is gear to make it profitable for any user to commit a processor or two to mining. I would love to see millions of small users generating a few kH/s each, instead of a few hundred (or a few dozen) huge players generating 10s of MH/s or GH/s. (As John Lennon said, "You may say I'm a dreamer..., but I'm not the only one...".)


I see your point. So, I guess I would vote for more units from the beginning. I think lots of granularity will be useful and beneficial in the long run.

Count me in as a C/Java dev.
Unfortunately I'm not experienced with current bitcoin protocol implementation, so I definitely won't be able to tech lead the development, but I'm glad to support it to the extent possible.

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

I read the white paper again this afternoon, and a couple of ideas came to mind. I admit that I am not yet completely up to speed on all of the terminology and concepts, so the following may be impractical or even stupid questions.

As you mentioned, in Bitcoin, proof of work is the primary thing that provides security against 51% attacks. I can see that, in this mini-blockchain system, it is still necessary to have proof of work to secure the network. But I wonder whether having the proof chain in the picture might make it possible to reduce the amount of work that needs to be proved for every block in order to keep the network secure. My idea (intention) would be to keep the work/difficulty down to a level that would allow CPU mining instead of GPU. The purpose behind the intention would be to reduce the amount of wasted energy/resources that currently goes into mining (even sCrypt-based) coins with high-end GPUs. The other purpose behind the intention would be to make it realistically possible for more people to participate in mining the proposed currency, thus making it much more decentralized. Alternatively, if the amount of work that must be proved mustn't change, perhaps we could work out some modification to the sCrypt that would make it even more ASIC-resistant, and perhaps even more GPU-unfriendly -- again for the same energy/resource conserving reasons.

On the subject of coin supply, it occurs to me that, if the proposed coin were to be wildly successful and be around for many years, even a quadrillion units might not be sufficient to account for small transactions, if the value of a single coin were to reach (the future equivalent of, for example) thousands or tens of thousands of dollars. To account for this possibility (without requiring a future hard fork or a new coin) what if the coin were developed with a bit/flag to indicate the location of the decimal point? For example, if at some future time, the value of one coin became so great that it was inconvenient to price small items in milli- or micro-coins, the currency could easily do a "split", similar to a stock split. After the split, every holder of every coin would find themselves with (say) a thousand times as many coins, each of which was worth one thousandth of the former amount. No one would gain or loose any value, the prices of things would just come down, as expressed in MBC (mini-blockchain) coins. Such a split would need to be well orchestrated, so that merchants and consumers alike were prepared for the change. But, having such a mechanism already built in might save a lot of headaches in the future. There are certainly some details of this that would need to be worked out, but I thought I would throw out the idea.

If the above is completely crazy, I'm sure someone will be willing and able to point out the flaws.

Most of the rest of the whitepaper makes excellent sense to me. I'm definitely in agreement with the overall plan.

I hope we can find some good coders to help produce a trial version.

No need to hurry. I won't have time to use it until Wednesday anyway.