The purpose of the difficulty is to maintain a 10 minutes average delay between each block and by the way to ensure the Bitcoin emission rate.
The difficulty is adjusted every 2016 Blocks (2 weeks) to compensate the increase or the decrease of the network calculation power.
If the difficulty is so low that the network generates blocks in less than 5 seconds this would be highly unsecure because this would not let time for the blocks to be shared on the network. The result would be a lot of orphan blocks.
Some altcoins were launched with 15 seconds blocks target. Many of them like smallChange failled and doesn't exists anymore.
Thank you! Exactly what I was looking for. Is there a compromise between Bitcoin's intended 10 minute time and a consumer's ideal of "instantaneously"? In other words, what's the smallest time possible that still prevents the problems you outlined? Thank you so much in advance! – None – 2013-12-13T20:17:11.640
1As far as I know there is no altcoin with less than 15 seconds blocks target. Worldcoin is the only one that worked for some time using 15 seconds block target but they updated it to 30 seconds because of the orphan block problem. But having fast block target doesn't mean that transactions will be much faster. Look at Litecoin they have 2.5 minutes block target but they need 6 confirmations (about 18minutes) before a transaction is valid. Bitcoin has a 10minutes block target but it only needs 3 confirmations (about 30 minutes). – Jan Moritz – 2013-12-13T20:27:54.110
Thank you for your knowledge! Also, if the block size was limited to no more than 1 transaction, would the orphan problem still be an issue? Thank you so much in advance! – None – 2013-12-13T20:28:15.103
1I think that it wouldn't really help. Bitcoin is decentralized so every client is connected to about 8 other clients. If there are 8,000 clients it would still take some seconds independently on the block size before every body will get the new block. – Jan Moritz – 2013-12-13T20:32:47.887
Again, I very much appreciate you sharing your knowledge. How could the orphan problem for "instantaneous" verification be solved? Should I open up a new question? Thank you so much in advance for helping me to understand this issue! – None – 2013-12-13T20:35:28.747
1You can open a new question but I don't think "instantaneous" verification will ever be possible using a bitcoin like protocol. – Jan Moritz – 2013-12-13T20:38:12.057
Thank-you Jan. You've helped me so much, and it is much appreciated! – None – 2013-12-13T20:40:41.727
Thank-you Jan. You've helped me so much, and it is much appreciated! I've posted the new question here if you'd like to take a stab at it. Thank you so much in advance! http://bitcoin.stackexchange.com/questions/18692/instantaneous-transaction-verification
– None – 2013-12-13T21:04:51.1271Joe Pineda asked the right question : how much safety do you need? 99%, 99.99% 99,99999...%? If you are a bar selling beers you probably don't need to wait the payment to be included in any block. Like blocks, transactions are also shared to all Bitcoin clients. The honest miners will only try to include the first transaction they received and reject any double spend attempt. So if you wait lets say 5 seconds and your client not received any double spend attempt you can be pretty sure that you'll get the coins because all the miners should already have received your transaction first. – Jan Moritz – 2013-12-14T05:40:12.133
1If you are a ATM company it would not be an so great idea to not wait any confirmations because with so huge amounts in the game some people will may be try to mine their own block. They need just to create a block in which one they spend the money back to themselves letting the transaction to the ATM become invalid. Other miners will continue to work on this 'fraudulent' block because of course it's still a valid block. So the solution they implemented is to verify the identity of the customer. So if something goes wrong they can find him later to ask their money back. – Jan Moritz – 2013-12-14T05:50:17.463
Thank you Jan! I'd prefer the ideal: ~100% confirmation ideally. Just because it's not available now doesn't mean a bitgenius can't come along and contribute it to cryptonumismatics. Imo, I think these types of criteria are necessary for total displacement by cryptocurrencies. All costs must be compensated, so if only 17% confidence in a bitcoin transaction can be reached in 10 minutes, prices will need to be 6x what it would be otherwise for a seller who delivers after 1 confirmation. It may not be quite so extreme, but whatever the true risk is must be added to the price or bust. – None – 2013-12-14T20:56:13.723
1Hmmm 100% it is difficult to determine when you'll reach it. In 2010 a buffer overflow vulnerability allowed someone to create an unlimited amount of Bitcoins. To revert this a patch was published and the blocks of an entire day were reverted. So is one day really 100%? – Jan Moritz – 2013-12-15T00:17:49.483
Thank you very much Jan: you've helped me to understand this so much more! Assuming that creation rates are not expressly linked to difficulty, is it feasible that this could be solved with user defined difficulty? Thank you so much Jan! http://bitcoin.stackexchange.com/questions/18816/sender-defined-difficulty
– None – 2013-12-15T23:18:46.663The way I see it, you'll never reach 100% confirmation. Chances are, tomorrow an E.T. comes with very advanced quantum super-computers (or a US gov agent gets them, after a secret scientific breakthru) and decides to re-do all blocks in all crypto-coins after genesis block, accounting themself all the rewards. Should their hash power be minimum 51% of the total hash power of rest of the network, there's nothing the rest of mortals could do to stop it :( – Joe Pineda – 2013-12-17T19:25:51.043
In fact there is a hardcoded checkpoint in the Bitcoin client see https://github.com/bitcoin/bitcoin/blob/master/src/checkpoints.cpp Line 42-52. But it isn't updated very often. The checkpoints 'secure' it against 51% attacks even if you have huge computation power but you need to trust these developers who are setting the checkpoints.
– Jan Moritz – 2013-12-17T19:56:52.830