TradeFortress 🏕

Legendary



Offline



Activity: 1176

Merit: 1023







VIPLegendaryActivity: 1176Merit: 1023 [C3] Coin Brainstorming / Ideas / Proposals thread April 04, 2013, 12:11:47 AM

Last edit: April 04, 2013, 10:41:35 PM by TradeFortress #1



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 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., this coin would be decided upon by community consensus.Also, this is not just about proposing your ideas,. Feel free to +1 those you like, point out flaws that you can see, or stuff you don't want.

TradeFortress 🏕

Legendary



Offline



Activity: 1176

Merit: 1023







VIPLegendaryActivity: 1176Merit: 1023 Re: [C3] Coin Brainstorming / Ideas / Proposals thread April 04, 2013, 12:13:48 AM #2 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 🏕

Legendary



Offline



Activity: 1176

Merit: 1023







VIPLegendaryActivity: 1176Merit: 1023 Re: [C3] Coin Brainstorming / Ideas / Proposals thread April 04, 2013, 12:23:03 AM #3 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



Offline



Activity: 28

Merit: 0









NewbieActivity: 28Merit: 0 Re: [C3] Coin Brainstorming / Ideas / Proposals thread April 04, 2013, 12:42:13 AM #6 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 🏕

Legendary



Offline



Activity: 1176

Merit: 1023







VIPLegendaryActivity: 1176Merit: 1023 Re: [C3] Coin Brainstorming / Ideas / Proposals thread April 04, 2013, 12:50:42 AM #7 Quote from: strunberg on April 04, 2013, 12:37:00 AM 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 & 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. 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.

dreamwatcher



Offline



Activity: 1064

Merit: 1000







LegendaryActivity: 1064Merit: 1000 Re: [C3] Coin Brainstorming / Ideas / Proposals thread April 04, 2013, 01:38:26 AM #13 Quote from: strunberg on April 04, 2013, 12:58:56 AM Quote from: TradeFortress on April 04, 2013, 12:52:36 AM Quote from: Vuxil on April 04, 2013, 12:36:00 AM 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?

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.

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.





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.

TradeFortress 🏕

Legendary



Offline



Activity: 1176

Merit: 1023







VIPLegendaryActivity: 1176Merit: 1023 Re: [C3] Coin Brainstorming / Ideas / Proposals thread April 04, 2013, 04:21:37 AM #15 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 🏕

Legendary



Offline



Activity: 1176

Merit: 1023







VIPLegendaryActivity: 1176Merit: 1023 Re: [C3] Coin Brainstorming / Ideas / Proposals thread April 04, 2013, 05:57:25 AM

Last edit: April 04, 2013, 06:30:33 AM by TradeFortress #18 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.

