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.
Topic: [C3] Coin Brainstorming / Ideas / Proposals thread - page 3. (Read 3336 times)
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.
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.
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.
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.
Quote
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.
Quote
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
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.
Quote
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
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.
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.
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.
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.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 & 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.
If ASIC becomes the future,and is not up rooted for some better technology. Should we talk about optimization for ASIC's?
The MEME "will it run crisis" is a really bad one as alot of folks say the game's engine is really badly optimized.
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.
So, PoS sounds like a good idea. I'm not sure about PPC difficulty and block reward calculations though.
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? 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.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 & 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.
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.
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.
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
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
Changing the encryption algorithm gives people incentive to start using C3 because it would be "ASIC-proof" for a short while
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.
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.
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?
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?
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
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
Jump to: