How about using an algorithm that cannot be done on a GPU? Something that needs single threaded performance. RSA comes to mind, as I think the CPU performance is much higher than when you run it on a GPU. There is probably something better out there. This will put the currency in the hands of the users that want to use the coin, instead of miner that buy the most GPUs. Also, there are tons of scrypt based altcoins already.
Topic: [ANN] HazardCoin, a unique scrypt based coin based on time (Read 4990 times)
Would it be possible to track the number of non-mining transactions, and factor that into some kind of algorithm that would lower the block reward when transactions were high, and raise it when transactions were low? Within certain parameters, of course. Unbounded reward limits could lead to undesirable concentrations due to perfectly normal fluctuations in the amount of transactions that have occurred since the last adjustment.
So that the almost empty blocks will get most rewards? This will again benefit early miners.Good point, I hadn't considered that.
Hope2907 partially addressed that:
you should let the first thousand blocks no rewards
Also, you would keep the reward between an upper and lower amount, so that even when transactions are very very low, you still aren't getting a billion coins per block.
Another thing to add to it would be to make the number that you apply to your block reward calculations be a ratio of transaction amounts to mined coins, and then in the beginning, all someone would have to do would be to pass a small amount of coins between two wallets to prevent the block reward from going up. And it should be a % change to the block reward rather than an amount of coins
you should let the first thousand blocks no rewards
Would it be possible to track the number of non-mining transactions, and factor that into some kind of algorithm that would lower the block reward when transactions were high, and raise it when transactions were low? Within certain parameters, of course. Unbounded reward limits could lead to undesirable concentrations due to perfectly normal fluctuations in the amount of transactions that have occurred since the last adjustment.
So that the almost empty blocks will get most rewards? This will again benefit early miners. Would this coin address the inevitable dump that comes after a coin reaches a exchange?
There's nothing to prevent what people choose to do with their coin. But, by design, there won't be the "early miners with a ton of coins" scenario that we've seen play out multiple times, so people won't have tons of easily acquired coins that they could just dump.Would it be possible to track the number of non-mining transactions, and factor that into some kind of algorithm that would lower the block reward when transactions were high, and raise it when transactions were low? Within certain parameters, of course. Unbounded reward limits could lead to undesirable concentrations due to perfectly normal fluctuations in the amount of transactions that have occurred since the last adjustment.
I also thought about time-based reward, with the motivation to: a) remove the need for difficulty recalculation and b) limit the expansion of hashrate of the network. What about the following idea: blocks are defined by time. All transactions are timestamped by the issuers and block is formed from all transactions which fall within a specified time window since the last block. That way it's useless to start mining before the block 'matures'. Blocks which are broadcasted too early and do not contain all the transactions within the time window will be rejected.
well, this are 2 completely different concepcts, and none of them is even slightly close to the original
1. time based reward
this is fail by design. super unfair distibution. you cannot distribute by time based on global difficulty and current protocol.
False, this is exactly what the original concept hoped to be. If there is 1 coin generated per second, coins are effectively distributed by hashing power percentage.1. time based reward
this is fail by design. super unfair distibution. you cannot distribute by time based on global difficulty and current protocol.
2. difficulty based reward
nothing is changed, just another altcoin.
False, this solution also addresses all the issues I laid out in the OP. nothing is changed, just another altcoin.
Development update:
From the outset, the main problem with this concept was figuring out how to combat the timestamp manipulation vector of attack. As it is decentralized, there is no centrally agreed upon time in the bitcoin network. There exists a network mean time, and the bitcoin client will accept a block as a valid if the timestamp of a new block is within 2 hours of the network mean time. This is obviously an unacceptable window. It would be possible to decrease the window from 2 hours to something more reasonable, say, 30 seconds, but this would require every client on the network to synchronize their system clocks. Not exactly an elegant solution.
Development may shift towards a difficulty oriented method of deciding how many coins are minted if the community deems synchronizing times as an unacceptable solution.
Thoughts?
From the outset, the main problem with this concept was figuring out how to combat the timestamp manipulation vector of attack. As it is decentralized, there is no centrally agreed upon time in the bitcoin network. There exists a network mean time, and the bitcoin client will accept a block as a valid if the timestamp of a new block is within 2 hours of the network mean time. This is obviously an unacceptable window. It would be possible to decrease the window from 2 hours to something more reasonable, say, 30 seconds, but this would require every client on the network to synchronize their system clocks. Not exactly an elegant solution.
Development may shift towards a difficulty oriented method of deciding how many coins are minted if the community deems synchronizing times as an unacceptable solution.
Thoughts?
Can't you use existing time services to sync the clients something like this maybe: http://www.ntp.org/ ?
I'm currently considering either a time or difficulty based solution
Time based: X coins generated per hour. Coins are effectively distributed by the percentage of hash power you contribute to the network. Subsidy reduction not necessary.
Difficulty based: Amount of coins generated scales relative to difficulty. Amount of coins generated per MHash remains flat, no matter how many miners are on the network. Subsidy reduction would be in accordance with Moore's Law.
I believe both of these address a lot of the problems recent altcoins have had with their launches, although the difficulty based solution is far more easier to implement that the time based one.
Time based: X coins generated per hour. Coins are effectively distributed by the percentage of hash power you contribute to the network. Subsidy reduction not necessary.
Difficulty based: Amount of coins generated scales relative to difficulty. Amount of coins generated per MHash remains flat, no matter how many miners are on the network. Subsidy reduction would be in accordance with Moore's Law.
I believe both of these address a lot of the problems recent altcoins have had with their launches, although the difficulty based solution is far more easier to implement that the time based one.
well, this are 2 completely different concepcts, and none of them is even slightly close to the original
1. time based reward
this is fail by design. super unfair distibution. you cannot distribute by time based on global difficulty and current protocol.
2. difficulty based reward
nothing is changed, just another altcoin.
42 trillion 
I'm currently considering either a time or difficulty based solution
Time based: X coins generated per hour. Coins are effectively distributed by the percentage of hash power you contribute to the network. Subsidy reduction not necessary.
Difficulty based: Amount of coins generated scales relative to difficulty. Amount of coins generated per MHash remains flat, no matter how many miners are on the network. Subsidy reduction would be in accordance with Moore's Law.
I believe both of these address a lot of the problems recent altcoins have had with their launches, although the difficulty based solution is far more easier to implement that the time based one.
Time based: X coins generated per hour. Coins are effectively distributed by the percentage of hash power you contribute to the network. Subsidy reduction not necessary.
Difficulty based: Amount of coins generated scales relative to difficulty. Amount of coins generated per MHash remains flat, no matter how many miners are on the network. Subsidy reduction would be in accordance with Moore's Law.
I believe both of these address a lot of the problems recent altcoins have had with their launches, although the difficulty based solution is far more easier to implement that the time based one.
Would this coin address the inevitable dump that comes after a coin reaches a exchange?
There's nothing to prevent what people choose to do with their coin. But, by design, there won't be the "early miners with a ton of coins" scenario that we've seen play out multiple times, so people won't have tons of easily acquired coins that they could just dump. 
Would this coin address the inevitable dump that comes after a coin reaches a exchange?
Looks cool to me 
How is development coming?
How is development coming?
beautiful idea, but very hard to implement.
don't wait for it, not gonna happen....
it completely eliminates main security and synchronisation mechanism of all cryptos - blockchain height comparison.
you would have to make more work than all altcoins combined.
-distributed decentralised clock synchronisation
-new base for choosing the main tree branch, lets say the "power of chain" not height.
-PoC would have to be last n blocks mooving average difficulty.
-completely new protocol, choosing highest block in the time between blocks, not based on pre defined difficulty.
-temporary keeping of the highest block up to new_block_event
just my 30 sec idea, propably flaved
don't wait for it, not gonna happen....
it completely eliminates main security and synchronisation mechanism of all cryptos - blockchain height comparison.
you would have to make more work than all altcoins combined.
-distributed decentralised clock synchronisation
-new base for choosing the main tree branch, lets say the "power of chain" not height.
-PoC would have to be last n blocks mooving average difficulty.
-completely new protocol, choosing highest block in the time between blocks, not based on pre defined difficulty.
-temporary keeping of the highest block up to new_block_event
just my 30 sec idea, propably flaved
5 minute block target time
^ Both largely irrelevant because... Block reward will be based on the amount of time passed since last block found.
So if target is 5 min, it takes 5 constantly. Then block rewards based on amount of time between 2 blocks is constant. Instamine well make diff 1 at the start yet then still some people get more
^ Both largely irrelevant because... Block reward will be based on the amount of time passed since last block found.
So if target is 5 min, it takes 5 constantly. Then block rewards based on amount of time between 2 blocks is constant. Instamine well make diff 1 at the start yet then still some people get more
Looks very interesting, watching this one. 
Development update:
From the outset, the main problem with this concept was figuring out how to combat the timestamp manipulation vector of attack. As it is decentralized, there is no centrally agreed upon time in the bitcoin network. There exists a network mean time, and the bitcoin client will accept a block as a valid if the timestamp of a new block is within 2 hours of the network mean time. This is obviously an unacceptable window. It would be possible to decrease the window from 2 hours to something more reasonable, say, 30 seconds, but this would require every client on the network to synchronize their system clocks. Not exactly an elegant solution.
Development may shift towards a difficulty oriented method of deciding how many coins are minted if the community deems synchronizing times as an unacceptable solution.
Thoughts?
From the outset, the main problem with this concept was figuring out how to combat the timestamp manipulation vector of attack. As it is decentralized, there is no centrally agreed upon time in the bitcoin network. There exists a network mean time, and the bitcoin client will accept a block as a valid if the timestamp of a new block is within 2 hours of the network mean time. This is obviously an unacceptable window. It would be possible to decrease the window from 2 hours to something more reasonable, say, 30 seconds, but this would require every client on the network to synchronize their system clocks. Not exactly an elegant solution.
Development may shift towards a difficulty oriented method of deciding how many coins are minted if the community deems synchronizing times as an unacceptable solution.
Thoughts?
coiioioins ruleleuleueul
lol, 42 trillion coins 
.
I believe bitcoin is said to continue to produce coins for mining until 2140, so about 132 years after it was introduce.
So if we used that number in our calculation and figure that each block will take exactly 5 mins to mine. We'll get the reward for each block to be 3,026,843 coins or about 10,089 coins for each second it takes to mine a block.
.I believe bitcoin is said to continue to produce coins for mining until 2140, so about 132 years after it was introduce.
So if we used that number in our calculation and figure that each block will take exactly 5 mins to mine. We'll get the reward for each block to be 3,026,843 coins or about 10,089 coins for each second it takes to mine a block.
Jump to: