[C3] Coin Brainstorming / Ideas / Proposals thread

[🏰 TradeFortress 🏰]

This thread is for open discussion of the Community Cryptocurrency Foundation's coin.

Ideas and proposals that are improvements or localized changes can be more easily implemented and tested, versus complete overhauls. Please keep this in mind when suggesting & discussing changes.

Everyone is welcome, this coin would be decided upon by community consensus.

Also, this is not just about proposing your ideas, but also discussing others. Feel free to +1 those you like, point out flaws that you can see, or stuff you don't want.

Links
Foundation topic

[🏰 TradeFortress 🏰]

Personally, I want to focus on more lightweight - allow everyone to download the blockchain. Less dust and unspendable outputs.

Such as:
Reduce the divisibility to 0.0001 units instead of 0.00000001. This reduces the size of transactions by a small amount, as it is stored as an integer in each transaction, but also makes creating dust and unspendable outputs impossible

Trimming prevBlockHash and merkleRootHash to the first 192 bits. This should still provide adequate security, while reducing the size of block headers.

Full ECC public key-recovery, and Ed25519.

Should we keep the base58 encoding system? Addresses are hardly said out loud. I think we should still remove characters which look the same or similar (eg I and l), but perhaps symbols like !, #, &, *, <, >, . , . can be added.

How fast should blocks be, while balancing storage space with less variance?

[🏰 TradeFortress 🏰]

What about the mining subsidy / coinbase running out after 3 years? The distribution rates could be 30 coins for first year, 20 coins for 2nd, 10 coins for 3rd, and that's the end.

Would be interesting to see the network hashrate, difficulty and security in a post-coinbase environment.

And of course.. what hashing algorithm? I like SHA256, for greater compatibility. There's a point to be made regarding favouring CPUs but that can bring botnets.

[Vuxil]

Changing the encryption algorithm gives people incentive to start using C3 because it would be "ASIC-proof" for a short while

[strunberg]

The Minimal
1.Transactions must be atleast fast as Lite coin.
2.It must be limited in how many coins there are created.
3.It needs to have power saving capabilities of PPC for long term growth.
4. It must be ASIC proof.

The Priority/ies
1.It takes forever for new users to sync with the network when it comes to bit coin. How can we resolve that?

pipe dream/s
1. We need non government organizations to be able to some how tap the computing power of the coin's community.  
200 TH/S is fucking crazy, how can we allow organizations who use super computers to cure cancer to tap that power?

2. Some one suggested the idea of a PRIME coin.
 Perhaps we can use the computation power of the C3 network to improve the encryption or the security of the  coin,as the coin's computing power increases ?
Therefore the coin becomes harder to hack as the popularity increases. Eventually Bit coin will have a network power of 1 PH/S

[Vuxil]

I want to put up a counter-argument though of why ASICs are no big deal.

Eventually ASICs will hit economies of scale and demand will level out. These machines will eventually be cheap enough for casual miners to own; it's only short-run scarcity we are witnessing right now.

I think a better model is tying network security to something other than constant hashing power. PPC is a good model of a coin that is starting to do this. We could make something secure against having a hostile party buy up a bunch of power for a 51% attack.

[🏰 TradeFortress 🏰]

The Minimal
1.Transactions must be atleast fast as Lite coin.
2.It must be limited in how many coins there are created.
3.It needs to have power saving capabilities of PPC for long term growth.
4. It must be ASIC proof.

The Priority/ies
1.It takes forever for new users to sync with the network when it comes to bit coin. How can we resolve that?

pipe dream/s
1. We need non government organizations to be able to some how tap the computing power of the coin's community.  
200 TH/S is fucking crazy, how can we allow organizations who use super computers to cure cancer to tap that power?

1. I'd like that too, but we need to balance long term blockchain size too.
2 & 3: Could we do proof of stake based on transaction fees instead of inflating the monetary base? What proof of work focused on IO?
4. Why? Like what Vuxil said, the current situation with ASICs is like early GPUs or FPGAs. Soon most who want to mine will buy an ASIC.

1. This is what I'm trying to address through protocol changes, block header size reduction, etc. Keep in mind that block headers take up a set amount of space, so faster blocks wouldn't be too good.

[🏰 TradeFortress 🏰]

Changing the encryption algorithm gives people incentive to start using C3 because it would be "ASIC-proof" for a short while

What about scrypt with different parameters, or triple step SHA256 that would break existing ASICs but still be simple to implement miners for?

[chriswen]

I don't think coinbase running out in 3 years is a good idea.

So, PoS sounds like a good idea.  I'm not sure about PPC difficulty and block reward calculations though.

[🏰 TradeFortress 🏰]

Changing the encryption algorithm gives people incentive to start using C3 because it would be "ASIC-proof" for a short while

What about scrypt with different parameters, or triple step SHA256 that would break existing ASICs but still be simple to implement miners for?

I edited my original post. Check it out.

Off the top of my head, I can't think of any way to "use" the computational power for something without introducing centralization to the process. Interesting idea through, I'll try to think of something.

[dreamwatcher]

Changing the encryption algorithm gives people incentive to start using C3 because it would be "ASIC-proof" for a short while

What about scrypt with different parameters, or triple step SHA256 that would break existing ASICs but still be simple to implement miners for?

I edited my original post. Check it out.

My idea for the CPU friendly coin has to do with using the tuning parameters in scrypt alone or in conjunction with the normal hash targeting to increase/decrease the "difficulty"

For example: The network hash rate is too high and blocks are being generated too fast. To increase difficultly the daemons would increase the N parameter in the scrypt tuning.

The effect of that kind of change would hit a GPU much harder then a CPU. The CPU is much better at memory functions, buffers and moving large chunks of memory, whereas the GPU is much better at the small mathematical steps needed for SHA-256 hash.

Remember that scrypt and its peers were designed to thwart brute force attacks by requiring large memory buffers and alot of memory handling. What happens with today's scrypt coins is the tuning is fixed, so as GPU gets more powerful, it can overcome the memory barriers with computational speed.

I believe by making the tuning parameters variable and incorporating it into the difficulty logarithm, a coin can be produced that is truly GPU resistant.

I have only experimented with it a small amount. So I do not know all of the issues that will need to be overcome.

If anybody is serious about it, I can start the project back up open source-with a team.

This may be more of a project then the C3 is looking for however, But I thought I would throw it out there.

[strunberg]

Off the top of my head, I can't think of any way to "use" the computational power for something without introducing centralization to the process. Interesting idea through, I'll try to think of something.

I was talking about this,but thanks for that input as well.

2. Some one suggested the idea of a PRIME coin.
 Perhaps we can use the computation power of the C3 network to improve the encryption or the security of the  coin,as the coin's computing power increases ?
Therefore the coin becomes harder to hack as the popularity increases. Eventually Bit coin will have a network power of 1 PH/S

I like your Idea, and it seems rather easy to implement.

What about scrypt with different parameters, or triple step SHA256 that would break existing ASICs but still be simple to implement miners for?

My idea is that as the network power increases over certain "bench marks" , the SHA256 increased on how many times it's multiplied by a predetermined number.
Right now Bit coin has a combined computing power of 200 TH/s.
Let's say if C3 reaches 400 TH/S, then SHA25 is doubled. This happens every time the networking power is doubled. These events would be  hard coded in the source.

Maybe we could introduce Prime numbers as security as well. Therefor folks  will have to compute a higher prime number as the network power increases.

 Prime numbers are very important in the Cryptography  world.
So If we can't lend actual computing power to universities to cure cancer,why not  give out the prime numbers to organizations to improve data security for the world?
Surely we would love want to give a huge finger to the central planners, or the mass murderers of history?


http://upload.wikimedia.org/wikipedia/commons/thumb/4/4d/Holomor_Art_Denysenko_1.jpg/448px-Holomor_Art_Denysenko_1.jpg

[🏰 TradeFortress 🏰]

Doesn't it become harder over time to find another prime number? Thus, the 'difficulty' would always increase, unless you allow people to generate the same prime number which wouldn't work.

I think the idea to tweak parameters / mining as the difficulty increases is a novel idea, however my personal opinion is that it's overengineering it. Why not find a set of parameters for scrypt that makes GPUs useless for the next 10 years or so, and by then there wouldn't be a coinbase.

We can't do as the network difficulty doubles, more iterations of SHA256, because then you'd just get ASIC or FPGAs that repeats SHA256 x many times depending on the network difficulty.

[🏰 TradeFortress 🏰]

I created a poll here to see which direction we should be going (should it be CPU only, or CPU+GPU, or CPU+GPU+ASIC)
Please vote!

[CryptoJunky]

I'd like to see a coin that is different enough from the current crypto currencies that it requires it's own technical paper, or whitepaper. However, it should share enough of the basic concepts from Bitcoin's whitepaper that it could be considered a cryptocurrency still.

A few problems that are often cited with Bitcoin:
1. Confirmation Time (i.e. ~10min/block)
2. Growing centralization of mining pools
3. Deflation
4. Blockchain size

Potential Problem(s)
a. Transaction Fees

The Concept

A coin that wants to be spent. While Bitcoin was meant to augment traditional financial systems by removing the need for a third party mediator, this coin would augment Bitcoin by making purchases in real life much easier and more efficient. Currently Bitcoin confirmations take longer than is practical for many purchases such as restaurants, coffee, gas, etc. A coin with an optimized transaction time could better serve the purpose of a digital currency used in everyday transactions. Just how fast would be dependent on testing and could even change over time. Perhaps the confirmation time halves when the block reward does, such that it starts at 1 minute, then halves to 30 seconds, then 15, thus adapting to advancement in communications networks.

A faster confirmation would lead to a higher number of blocks, which could alleviate the centralization problem in mining pools. Users mine in pools to see more steady payouts. With a larger number of blocks in a given time, more/smaller mining pools might be possible.

On Deflation and Transaction Fees

It is yet to be seen whether deflation will be advantageous or not to Bitcoin in the long run. However, there are many that see deflation as a turn off to Bitcoin, especially some that are experienced and accustomed to the traditional financial world. Built in inflation after the initial distribution of coins could be advantageous in two ways.

1. It could eliminate transaction fees.
2. As fans of inflation often state it provides incentive for holders of the currency to spend it.

With the current implementation of crypto currencies there is a real possibility that in the somewhat distant future large mining consortiums could conspire to incorporate large fees into Bitcoin in an effort to retain mining's profitability. However, a coin with a built in inflation of say %1 annually, would allow for constant and consistent reward to miners, without users feeling they need to pay high fees to ensure their transaction is processed in a timely manner.

On Initial Distribution

Most cryptocurrencies follow a similar pattern with the block reward halving every four years. I'd suggest we accelerate this in an effort to mature the coin at a much faster rate. This would make even more sense if we were to include inflation as a way to account for miner's fees. The reward halving could occur at something on par with Moore's law, or even as short as every year.

Other Thoughts

Using a different hashing algorithm, one that has no special hardware or software, may help in maintaining a more even initial distribution between early adopters. Part of the success of the coin is getting it into as many different hands as possible early on. Specialized hardware may prevent this and make the currency harder to distribute. Furthermore, once individuals hold a significant amount of a coin they suddenly have incentive to help develop it or services for it. Having more individuals with incentive to help the currency is important.

This is more of a psychological benefit than a technical one, but coin denominations should not be measured from a whole coin into fractions. Rather, the smallest unit should be seen as a whole coin and the larger units should be expressed in scientific notation based off of that such that:

1 coin = 1 x 10^0
1 decacoin = 1 x 10^1
1 hectocoin = 1 x 10^2
1 gigacoin = 1 X 10^9

and so on.

That's it for initial thoughts, let me know what you think. I may have some more to add in a bit as well.

[🏰 TradeFortress 🏰]

Thanks for the nice writeup! Here's my thoughts:

The biggest problem with very fast blocks is that the block headers will need to be stored. If a client wants to rely on the full blockchain, then they'll need to download the blockchain which will become unfeasible on mobile phones and soon slow internet speeds. There's thin clients, but that still downloads headers (and that'll be unfeasible if we have a block every 15s).

Faster blocks also makes having connections to the most peers more important, it actually benefits mining pools to some extent. In addition, faster blocks does not make it faster for transactions to be more secure, it just reduces the variance of it. To get 6 confirmation "bitcoin-level" security you'd need 24 confirmations for litecoin for example. So we shouldn't overdo the block times.

Deflation is a tricky issue - why would people want to acquire an inflating coin, especially when the largest coin is deflationary? I think we will lose a large part of potential users.

I agree that we should change the block reward change schedule to make it release faster. However, perhaps it shouldn't have but instead is reduced by 25% every X months in block time? Would be less of a sudden jump.

The coin denominations - it is already that way really. In the code / transactions, 1 bitcoin is expressed as 1e+8 units. You can call satoshis the "bitcoin", and a millibit is just [blah] satoshis.. Either way this isn't about the core part of bitcoin but how the UI presents it.

If we want faster blocks, we really need to reduce the size of blocks and transactions in them. Like I mentioned before, my suggestions are:

1. Less unit divisibility (smaller ints stored in each transaction)
2. Reduced prevBlockHash and merkleRootHash for each block header

Maybe also a smaller address stored (160 bits instead of 200) - checksum would take a large hit to still provide enough address space.

[FortPotato]

Here are my brainstorming ideas I've had over the past few days. I had the old foundation thread open since this morning, posted in it, and THEN I saw this thread. I just went and deleted my other post and decided to bring it here.

I remember reading something about protecting a coin from a 51% attack by bookmarking the blockchain before the attack started. What if this new chain had automatic, even hourly, bookmarks/checkpoints. Should someone start up a 51% attack, just wait until it's over and revert to before the attack started.

One of the things that has made Litecoin so popular is the quick transaction confirmations. I think a new coin should be able to match or even beat LTC. (Maybe 2 minute intervals instead of LTC's 2.5?)

I think it should definitely be a more CPU-friendly coin. A lot of computers come with nicer dedicated graphics now, but higher end cards still blow these out of the water. If a GPU friendly coin was launched, it could easily be taken over by current BTC miners or ASICs. CPU-friendly coins more or less level the playing field, but, as mentioned, are vulnerable to botnet attacks. This is where the checkpoint system comes into play.

I don't know if a checkpoint system is the definitive answer to 51% attack protection, but there should be some sort of way to protect from 51% attacks. The coin I was thinking about looking into developing I wanted to call APC, or ArmoredCoin, or something along those lines, signifying it's strength and protection.

As for the amount issued, maybe follow this example: BTC is gold, LTC is silver, this new coin could be the copper equivalent. Issue 10x total amount relative to Bitcoins, and then make these coins worth 1/10th of a BTC once they become established.

I had a few other ideas, but this is all that comes to mind at the moment.

[🏰 TradeFortress 🏰]

Re: Automated checkpoints would make it centralized. We definitely will have checkpoints with each update through.

Also, what are your thoughts on "quicker blocks versus less storage for blockchain"? I don't think we need to continue the "litecoin is silver to gold" - I like a monetary base of around 20 million or even less.

[FortPotato]

Re: Automated checkpoints would make it centralized. We definitely will have checkpoints with each update through.

Also, what are your thoughts on "quicker blocks versus less storage for blockchain"? I don't think we need to continue the "litecoin is silver to gold" - I like a monetary base of around 20 million or even less.

With the quicker blocks vs storage, maybe make it so that each new wallet would have the option to go back maybe 2 checkpoints instead of to the beginning of the blockchain,with the possibility of deleting data earlier than 2 checkpoints ago when new checkpoints are reached. In addition to that, have a second option to include ALL blockchain history. With the first option, the client would take up significantly less space over time, but users could still keep a complete history if they wanted to by choosing the second option.

I agree that 20 mil is probably a better base. Making it the copper or platinum equivalent would make it easier for some to understand, but it's not necessary at all.

[crazy_rabbit]

The Minimal
1.Transactions must be atleast fast as Lite coin.

Faster please.

2.It must be limited in how many coins there are created.

Definitely. And it should be a low number- I prefer less then Bitcoin.

3.It needs to have power saving capabilities of PPC for long term growth.

Why exactly? Bitcoin has done pretty long term growth without saving power.

4. It must be ASIC proof.
Being ASIC proof means being Never Secure. Asics are a good thing. Even Litecoin Asics will eventually be built if it's successful enough. There is no such thing as ASIC proof. That said- without ASICS, the bad guys can always buy more GPU's then the good guys. Especially at the start. ASIC's make this much, much, more difficult.

The Priority/ies
1.It takes forever for new users to sync with the network when it comes to bit coin. How can we resolve that?

Better peering options? This has never been a real issue for me.

pipe dream/s
1. We need non government organizations to be able to some how tap the computing power of the coin's community. 
200 TH/S is fucking crazy, how can we allow organizations who use super computers to cure cancer to tap that power?

Unfortunately no- you can't do this. The whole point of the massive computing power is that they are computing things for which no one knows the answer to. If you tapped this power for something like curing cancer, someone will eventually feed the machine with a problem to which someone either already knows the answer to- or who can guess the answer to it. It's seems like a waste of computational energy, I know, but it has to be like that.

2. Some one suggested the idea of a PRIME coin.
Perhaps we can use the computation power of the C3 network to improve the encryption or the security of the  coin,as the coin's computing power increases ?
Therefore the coin becomes harder to hack as the popularity increases. Eventually Bit coin will have a network power of 1 PH/S
??