Author

Topic: The real achilles' heel of bitcoin? (Read 1252 times)

legendary
Activity: 1400
Merit: 1013
August 08, 2011, 09:09:16 AM
#11
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?
hero member
Activity: 1148
Merit: 501
August 08, 2011, 08:52:58 AM
#10
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.
kjj
legendary
Activity: 1302
Merit: 1026
August 08, 2011, 08:09:44 AM
#9
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.
hero member
Activity: 563
Merit: 501
betwithbtc.com
August 08, 2011, 07:46:44 AM
#8
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.
legendary
Activity: 1176
Merit: 1280
May Bitcoin be touched by his Noodly Appendage
August 08, 2011, 06:53:48 AM
#7
Completely agree with OP
See the current situation of Namecoin...
newbie
Activity: 24
Merit: 0
August 08, 2011, 06:46:54 AM
#6
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?
hero member
Activity: 531
Merit: 505
August 08, 2011, 06:40:23 AM
#5
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.
full member
Activity: 126
Merit: 100
August 08, 2011, 06:32:13 AM
#4
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. 
legendary
Activity: 1896
Merit: 1353
August 08, 2011, 05:10:53 AM
#3
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.



legendary
Activity: 1050
Merit: 1000
You are WRONG!
August 08, 2011, 05:07:39 AM
#2
microtransactions does not have to be fast. they have to be small.
full member
Activity: 201
Merit: 100
Decentralized Ascending Auctions on Blockchain
August 08, 2011, 05:03:50 AM
#1
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
Jump to: