Quote from: Cryddit on December 14, 2013, 01:38:55 AM

Quote from: Bitcoin-hotep on December 13, 2013, 04:36:49 AM

Has anyone made a coin recently they want to let us know about?

I checked out the bitcoin source a couple weeks ago.

I've hacked colored coins into the daemon, blockchain, and protocol (they cannot be destroyed or 'decolored' by an unaware client that mixes them with other coins). Including coin colors that are allowed to float against each other, and coin trades directly on the blockchain. I envision a future in which these additional colors of coins are digital stocks and the system works as a distributed stock exchange.

I've encrypted the protocol messages for privacy - all anyone can get is that you can tell by the pubkey what IP the message is for, but you cannot tell who's talking and you cannot read the message out of the protocol traffic. In principle you don't know what IPs are involved in a new transaction when it appears, but that can be compromised if an attacker adds enough "sybil" nodes to the network.

I've updated the source code and build defaults to c++2011.

I've changed the reward structure to start out rewarding 4 coins (of color zero) per solved block and inflate the mining rewards at a rate of 3% a year forever, so there's no particular advantage for early miners.

Now I'm elbows-deep in the code that selects coins, trying to make "standard" coin denominations - so the only denominations issued will start with 5, 10, 25, and 75, followed by some number of zeros. This makes it somewhat harder to "track" users by their transactions.

After that I'm going to try fixing it so each transaction works (with no input from the user) like a little coinjoin between sender, receiver, and some fairly small random number of others.

I have plans to try to "fix" the mining algorithm so it's based on proof-of-stake rather than proof-of-work, and pays everyone who maintains an active full node approximately proportionally to the amount of coin they have, rather than paying one "winner" per round.

After that I'm going to fix it so when transaction volume gets too high, the system splits into multiple blockchains and each client only has to listen to part of the traffic. For example, if it needs to scale up to 2000 transactions per second, you'd find the clients split into 25 "channels", each of which is listening to and serving 25 total blockchains - 24 of the total of 300 'normal' blockchains and one 'universal' blockchain. -- that is, one blockchain for every *other* channel, so that any two users would have at least one "normal" blockchain in common, and one blockchain that's shared among *all* channels, so that transactions involving clients in three or more different channels have a place where they can be. That would mean each client has to download, verify, and store only one twelfth or so of the total 2000-per-second volume. Which is still a lot, but which, by the time we get to 2000 transactions per second, I hope will be possible with "ordinary" hardware. Each block would record the blockhashes of the most recent blocks found in the other blockchains.

After that I'm going to try and limit the tracked depth of the 'normal' blockchains. Every 144 blocks or so (meaning approximately once per day) there'd be a larger "day block" that records the outstanding txouts. And the depth of the blockchain down to that block would be all you need to download and keep when 'syncing' with the system. Only the 'universal' blockchain would reach all the way back to the genesis block.

Once all of that is done, I'll be ready to launch beta version one.

Once I hack in 'awareness' of other coins' blockchains and atomic (if slow) distributed trading between different types of existing cryptocurrencies, I'll be ready to launch beta version two.

Wow I did not understand most of that but good luck with your coin