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

[aaaxn]

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

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.

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.

[1714910925]

1714910925

[1714910925]

1714910925

[1714910925]

1714910925

[bitfreak!]

but... I don't see reason to worry about it now. We need to implement basic system first

Agreed.

[lexxus]

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.

[stellarman]

zero-coin like strong privacy, etc.

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.

[bitfreak!]

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

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

[aaaxn]

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.

First let's define Mixing Set.
Mixing Set consists of header and list of inputs to mix. Header includes:
- mixing denomination (1 coin, 100 coin, etc)
- mixing size (how many inputs)
- mixing public key
- time available for ticket redeeming
- input coins used as collateral

Mixing parameters should be standardized so it would be easier to find matching inputs.

Users sends to network intentions to mix which include
- sufficient amount of coins (denomination + fee)
- requested denomination
- requested minimum mixing size
- requested ticket redeeming window
- blinded mixing ticket = blind(random string + payout address). We need random string so every ticket is unique.

Miners monitor received mixing intentions and if miner find set which can be used for creating Mixing Set he can create one.
Miner generates new key pair just for single Mixing Set and includes this key in header. With this key he make blind signatures of all mixing tickets and include such transaction in block.
When Mixing Set is included coins are taken from all participants but are not deposited anywhere.

All mixing participants can now see that their mixing intentions were included in blockchain. They unblind their tickets and with it create output transactions against Mixing Set (their tickets are signed with blocks private key).
Redeem transactions can be included in any next block until redeeming time is up.
When redeeming is over we can have 3 outcomes
- there was less redeemed tickets than input. In this case outputs are credited normally and creator of Mixing Set gets free money.
- all tickets was redeemed. Outputs are credited normally.
- there was more redeemed tickets than inputs. This mean creator of Mixing Set cheated so he looses his collateral (miner who mined block containing first extra ticket gets it) and money is returned to senders. Users can't ever loose their money.

[BitcoinAshley]

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.

[maco]

Great recommendations BitcoinAshley. I have to concur with the following quote.

I am also a C++/C# and Web/Database Developer.. Oracle, Java, JavaScript, SQL, etc..

What area do you need others involved in and how many do you have on-board now?

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.

[lexxus]

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.

[aaaxn]

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.

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

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.

[bitfreak!]

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.

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.

[bitfreak!]

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

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.

[aaaxn]

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.

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.

[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?

[cunicula]

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

[aaaxn]

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

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;]?

[nomailing]

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.

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

[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

[aaaxn]

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

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?

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.

[nomailing]

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

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?

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.

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.