LittleDigger
|
|
May 15, 2013, 03:29:52 AM |
|
Most of the names suck... Even "Bitcoin"..
I know that I'll catch flak for saying it, it might be fine amongst geeks and cryptocurrency enthusists,but your average person on the street just doesn't like the sound of the name.. It doesn't sound official, It doesn't sound like something you'd discuss on wall street, It doesn't sound right in a bank ( I know I had a conversation with my bank manager about cryptocurrencies ) and it sure as hell doesn't sound right coming out of the presenter on the finnacial news show... and wide spread adoption is the aim after all...
So why not call it something that does sound a little more professional... like "Global Trading Credit(s)"
I like the part where the global trading credits were used to pump and dump trillions in mortgages, no one went to jail, and even the foreclosure process is kicking the wrong people out of their houses, and even the govt gave up trying to clean up the mess. Yes banks are entirely trustable. Like that time in Cyprus when they froze all the accounts then took a %age of everyone's savings to save the banks and the economy from their mismanagement... examples abound. I like how when I fill up my car, shop for groceries or pay my utilities I keep getting asked "can we have that in bitcoin"....... I mean seriously just get rid of MTGOX and watch the value soar...
|
|
|
|
kibu
Newbie
Offline
Activity: 55
Merit: 0
|
|
May 15, 2013, 03:48:28 AM |
|
Hazard, are you still planning on releasing this?
|
|
|
|
Hazard (OP)
Legendary
Offline
Activity: 980
Merit: 1000
|
|
May 15, 2013, 03:49:24 AM |
|
Hazard, are you still planning on releasing this?
Yeah
|
|
|
|
truckythin
|
|
May 15, 2013, 03:50:28 AM |
|
i think he wont since the FC2 has just been released, but keep it till FC2 to the end, we will have another alt-coin
|
|
|
|
thaile4ever
Newbie
Offline
Activity: 42
Merit: 0
|
|
May 15, 2013, 03:52:11 AM |
|
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.
|
|
|
|
achillez
|
|
May 15, 2013, 03:53:44 AM |
|
coiioioins ruleleuleueul
|
|
|
|
Hazard (OP)
Legendary
Offline
Activity: 980
Merit: 1000
|
|
May 17, 2013, 12:10:09 AM |
|
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?
|
|
|
|
Vorksholk
Legendary
Offline
Activity: 1713
Merit: 1029
|
|
May 17, 2013, 12:14:54 AM |
|
Looks very interesting, watching this one.
|
|
|
|
|
alex_fun
|
|
May 17, 2013, 12:31:19 AM |
|
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
|
|
|
|
xorxor
|
|
May 17, 2013, 01:14:38 AM Last edit: May 17, 2013, 01:48:32 AM by xorxor |
|
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
|
fuck deeponion, fuck bitcoincash, all glory to one BITCOIN
|
|
|
Kinetic915
|
|
May 17, 2013, 06:46:44 AM |
|
Looks cool to me How is development coming?
|
|
|
|
Kinetic915
|
|
May 17, 2013, 06:51:06 AM |
|
Would this coin address the inevitable dump that comes after a coin reaches a exchange?
|
|
|
|
Hazard (OP)
Legendary
Offline
Activity: 980
Merit: 1000
|
|
May 17, 2013, 06:56:00 AM |
|
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. 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.
|
|
|
|
mladen81
Member
Offline
Activity: 66
Merit: 10
|
|
May 17, 2013, 07:55:11 AM |
|
42 trillion
|
LTC LbDkEKTAGrPYVuAujfVwSeU6RLT3sUuAVQ BTC 1KZ8z3J3U5381xdQeNiEgRzN69JwGCf5hx DOGE DGR7JCC5YXVywPJ3cQKkuBBQqVJL2FqJFC
|
|
|
xorxor
|
|
May 17, 2013, 09:28:40 AM |
|
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.
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.
|
fuck deeponion, fuck bitcoincash, all glory to one BITCOIN
|
|
|
freigeist
|
|
May 17, 2013, 01:43:12 PM |
|
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?
Can't you use existing time services to sync the clients something like this maybe: http://www.ntp.org/ ?
|
|
|
|
Hazard (OP)
Legendary
Offline
Activity: 980
Merit: 1000
|
|
May 17, 2013, 03:01:55 PM |
|
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. 2. difficulty based reward
nothing is changed, just another altcoin.
False, this solution also addresses all the issues I laid out in the OP.
|
|
|
|
sor.rge
Newbie
Offline
Activity: 42
Merit: 0
|
|
May 17, 2013, 04:04:07 PM |
|
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.
|
|
|
|
thesnoo23
Newbie
Offline
Activity: 56
Merit: 0
|
|
May 17, 2013, 04:18:07 PM |
|
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.
|
|
|
|
|