Which is why we have laws IRL. Otherwise people would go around raping and robbing people with no fear of consequence.
Who are these "people" exactly? Would YOU go around raping and robbing people if there were no laws IRL? How many of your friends or family would do this? 
Topic: The real achilles' heel of bitcoin? (Read 1255 times)
The achilles heel of bitcoin is that it's wide open and people can rob cheat and steal with little to no fear of consequence. Which is why we have laws IRL. Otherwise people would go around raping and robbing people with no fear of consequence.
If you had to prove you were legit in order to use bitcoin, we'd see alot fewer scammers floating around. Those turds would be flushed out of the system.
If you had to prove you were legit in order to use bitcoin, we'd see alot fewer scammers floating around. Those turds would be flushed out of the system.
The idea that 90% of the mining power would disappear at once is pretty silly. The literal end of the world would be more likely.
But, if it ever did happen, the remaining 10% would have plenty of time to agree to a change of algorithm and update their clients.
And yes, this have been discussed many, many times before, in dozens if not hundreds of threads.
But, if it ever did happen, the remaining 10% would have plenty of time to agree to a change of algorithm and update their clients.
And yes, this have been discussed many, many times before, in dozens if not hundreds of threads.
Your price drop scenario is extreme and highly unlikely. Rigs would be taken offline, proportional to the price drop. This would result in less coins being generated, lower supply, and ultimately a stabilization in price far above anything near $0.10.
Completely agree with OP
See the current situation of Namecoin...
See the current situation of Namecoin...
The solution is simple and is called transaction fees. If you do not want to wait e.g. 10 times longer for the next block, you will have to increase the fee accordingly to motivate the miners to run their machines again.
Is there a way to estimate wait time for transfering x coins with y fee?
The solution is simple and is called transaction fees. If you do not want to wait e.g. 10 times longer for the next block, you will have to increase the fee accordingly to motivate the miners to run their machines again.
As for now, everything's gone fine, since the difficulty has always gone up
This is not true. Difficulty has gone down once, and it did not kill it.
I'm sure it will happen again.
That's not what he is talking about. Going down isn't a problem, but it is if a lot of miners quit like they probably will when the downward trend continues. Less miners=less blocks resolves=a really long time until the difficulty is readjusted after blocks are completed. It's a valid concern, but far from its weakest point, which is the only part I disagree with.
As for now, everything's gone fine, since the difficulty has always gone up
This is not true. Difficulty has gone down once, and it did not kill it.
I'm sure it will happen again.
microtransactions does not have to be fast. they have to be small.
There is a lot of discussion about the 50+% attack, and as earlier threads have stated, that's pretty easily fixed by just ignoring the fork in the chain. However, the weekend's sell-off and the crash in the BTC/USD rate made me think of the major downfall of bitcoin - the algorithm used to determine the retarget.
Currently (https://en.bitcoin.it/wiki/Target), the difficulty is recalculated every 2016 blocks, which should take 10 minutes per block, i.e. in 2 weeks. As for now, everything's gone fine, since the difficulty has always gone up, and thus the next retarget has always been less than two weeks. However, let's assume the following scenario takes place: There is a major crash in the BTC/fiat exchange rate. This leads miners into quitting mining, since their rigs won't be profitable anymore -- let's for the fun of it assume that the exchange rate BTC/USD crashes to .1 USD per BTC, and let's furthermore assume that that leads into the network hashing power dropping by 90%. Let's also assume that the difficulty has just increased, so there's around 2000 blocks until the next difficulty.
The current bitcoin protocol waits for 2000 blocks, which would in the new scenario take 100 minutes per block, resulting in a retarget in 138 days. Currently, usage of BTC for transactions over the Internet is justifiable, since waiting 6 confirmations should take 60 minutes on average (and in the last 2 months even significantly less), however, in the scenario just laid down, a single transaction would take 600 minutes (assuming that it gets into the first possible block) on average. Waiting for 10 hours for something that BTC is good for - microtransactions - is atleast IMO not acceptable. So, this scenario leads into lowered usage of BTC due to the fact that the transactions take too long to process, resulting in even less people interested in BTC and even less miners, resulting in even longer until retarget.
How this could be fixed: change the protocol in a way that it retargets using one of the two criterion: a) 2016 blocks have been found, retarget in the same way as is done currently and b) three weeks have passed from the last retarget, in which case the protocol would take the amount of blocks and make an estimate of how long with the current rate the retarget would have taken, and adjust the difficulty accordingly.
I'm sorry if this has been extensively discussed before, I tried searching for a thread but couldn't find one.
Just my .02 BTC,
VP
Currently (https://en.bitcoin.it/wiki/Target), the difficulty is recalculated every 2016 blocks, which should take 10 minutes per block, i.e. in 2 weeks. As for now, everything's gone fine, since the difficulty has always gone up, and thus the next retarget has always been less than two weeks. However, let's assume the following scenario takes place: There is a major crash in the BTC/fiat exchange rate. This leads miners into quitting mining, since their rigs won't be profitable anymore -- let's for the fun of it assume that the exchange rate BTC/USD crashes to .1 USD per BTC, and let's furthermore assume that that leads into the network hashing power dropping by 90%. Let's also assume that the difficulty has just increased, so there's around 2000 blocks until the next difficulty.
The current bitcoin protocol waits for 2000 blocks, which would in the new scenario take 100 minutes per block, resulting in a retarget in 138 days. Currently, usage of BTC for transactions over the Internet is justifiable, since waiting 6 confirmations should take 60 minutes on average (and in the last 2 months even significantly less), however, in the scenario just laid down, a single transaction would take 600 minutes (assuming that it gets into the first possible block) on average. Waiting for 10 hours for something that BTC is good for - microtransactions - is atleast IMO not acceptable. So, this scenario leads into lowered usage of BTC due to the fact that the transactions take too long to process, resulting in even less people interested in BTC and even less miners, resulting in even longer until retarget.
How this could be fixed: change the protocol in a way that it retargets using one of the two criterion: a) 2016 blocks have been found, retarget in the same way as is done currently and b) three weeks have passed from the last retarget, in which case the protocol would take the amount of blocks and make an estimate of how long with the current rate the retarget would have taken, and adjust the difficulty accordingly.
I'm sorry if this has been extensively discussed before, I tried searching for a thread but couldn't find one.
Just my .02 BTC,
VP
Jump to: