i have some statements i believe to be true.
overall security never changes no matter what the target block time is. only time and blocks being generated will make coins more secure.
shorter times would allow us to get past the initial "uncertainty". because once you get a transaction inside a valid block, you are for the most part more secure than if you just accepted an unconfirmed transaction. this is the only benefit to decreasing block time, otherwise it only has negatives like more space required to store the chain (overhead) and more times when 2 or more blocks compete to become part of the chain.
if it were up to me i would decrease it to 2-5 minutes.
Topic: Suggested MAJOR change to Bitcoin - page 3. (Read 9442 times)
No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.
The global hash rate is important, it's just assumed to be static in the comparisons because there is no way to know what the proper hash rate should be or would be. But if one assumes that the pool of honest hashing power is the same regardless of the target interval, a 2 minute block does represent roughly one-fifth the brute force security of a 10 minute block. The statistical analysis of a confirmed block does matter somewhat, but isn't the most important factor in the security of the blockchain, the difficulty of reversing the honest block is. No matter how you look at it, the difficulty of reversing a confirmed 10 minute block is about 5 times harder than reversing a confirmed 2 minute block...
I understand that, but that is not a meaningful distinction in the context of this thread or in the practicalities of attacking bitcoin. If I have 30% of the global hash power and overnight bitcoin changes from 10min blocks to 2min blocks, my likelihood of executing a double-spend after X confirmations is negligibly different before and after.
Yes it is would be 5 times harder if the honest network magically increased to 5x it's original size, but that's not what will actually happen if the block interval is changed.
...Latency will matter if Bitcoin is ever successful enough to process significant numbers of transactions comparable to Visa or Paypal, particularly for the sole miners and end user nodes on the edges of the network. The core miners (and pools) will probably be very well connected to one another, but the edges is where the latency will be greatest.
If bitcoin ever reaches Visa-level of adoption, we will likely see many federated, industrial mining operations connected by direct fiber-optic connections. Latency will be no higher than it currently is with bitcoin or Visa (a few seconds, typically).
Maybe, maybe not. The interval is still arbitrary and the logic for 10 minutes remains as sound as it would be for 2 minutes. IT would certainly be much longer for edge of network solo miners. Keep in mind, at a Visa level of transaction processing, each block would be around 10 gigs. At 2 minutes, each block would still be around 2 gigs, but the multi-connection thing multiplies the burden upon the nodes.
to ensure your safety, you would have to wait a hour anyway.
it does not matter if you wait 6*10min or 30*2min.
its the same security, the blockchain is only proof of time.
No, that's simply not true by any meaningful measure (see my previous post), although it's a commonly repeated myth on these forums.it does not matter if you wait 6*10min or 30*2min.
its the same security, the blockchain is only proof of time.
That statement is equating security/safety with number of hash operations needed to undo a transaction. But that would only be true if work stopped on the honest chain. In actuality, the only thing that matters (and the math shows this) is percentage ownership of the global hash rate, and the likelihood of pulling off that attack decreases geometrically with the number of confirmations, regardless of block interval length.
It's not a myth.
No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.
The global hash rate is important, it's just assumed to be static in the comparisons because there is no way to know what the proper hash rate should be or would be. But if one assumes that the pool of honest hashing power is the same regardless of the target interval, a 2 minute block does represent roughly one-fifth the brute force security of a 10 minute block. The statistical analysis of a confirmed block does matter somewhat, but isn't the most important factor in the security of the blockchain, the difficulty of reversing the honest block is. No matter how you look at it, the difficulty of reversing a confirmed 10 minute block is about 5 times harder than reversing a confirmed 2 minute block...
I understand that, but that is not a meaningful distinction in the context of this thread or in the practicalities of attacking bitcoin. If I have 30% of the global hash power and overnight bitcoin changes from 10min blocks to 2min blocks, my likelihood of executing a double-spend after X confirmations is negligibly different before and after.
Yes it is would be 5 times harder if the honest network magically increased to 5x it's original size, but that's not what will actually happen if the block interval is changed.
...Latency will matter if Bitcoin is ever successful enough to process significant numbers of transactions comparable to Visa or Paypal, particularly for the sole miners and end user nodes on the edges of the network. The core miners (and pools) will probably be very well connected to one another, but the edges is where the latency will be greatest.
If bitcoin ever reaches Visa-level of adoption, we will likely see many federated, industrial mining operations connected by direct fiber-optic connections. Latency will be no higher than it currently is with bitcoin or Visa (a few seconds, typically).
to ensure your safety, you would have to wait a hour anyway.
it does not matter if you wait 6*10min or 30*2min.
its the same security, the blockchain is only proof of time.
No, that's simply not true by any meaningful measure (see my previous post), although it's a commonly repeated myth on these forums.it does not matter if you wait 6*10min or 30*2min.
its the same security, the blockchain is only proof of time.
That statement is equating security/safety with number of hash operations needed to undo a transaction. But that would only be true if work stopped on the honest chain. In actuality, the only thing that matters (and the math shows this) is percentage ownership of the global hash rate, and the likelihood of pulling off that attack decreases geometrically with the number of confirmations, regardless of block interval length.
to ensure your safety, you would have to wait a hour anyway.
it does not matter if you wait 6*10min or 30*2min.
its the same security, the blockchain is only proof of time.
it does not matter if you wait 6*10min or 30*2min.
its the same security, the blockchain is only proof of time.
That assumes a network propagation time to all other nodes in <1 second. Currently that is fine but
It isn't fine even now. The latency over Tor's 6-hop hidden service connections is significantly higher. I was under impression that Bitcoin from the start was designed to be tolerant of higher-latency networks like Tor.Tolerant yet but faster hops is always better. That is why 10 minutes is a compromise. 30 minutes blocks would be even better for high latency links and a larger network. The shorter the block the higher the penalty for high propagation times.
2 min vs 10 min doesn't solve the issue that 0 to 10 seconds is the "critical window". A 2 min confirm vs 10 min confirm doesn't help most merchants but does make latency of the network a much larger issue.
That assumes a network propagation time to all other nodes in <1 second. Currently that is fine but
It isn't fine even now. The latency over Tor's 6-hop hidden service connections is significantly higher. I was under impression that Bitcoin from the start was designed to be tolerant of higher-latency networks like Tor. No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.
The global hash rate is important, it's just assumed to be static in the comparisons because there is no way to know what the proper hash rate should be or would be. But if one assumes that the pool of honest hashing power is the same regardless of the target interval, a 2 minute block does represent roughly one-fifth the brute force security of a 10 minute block. The statistical analysis of a confirmed block does matter somewhat, but isn't the most important factor in the security of the blockchain, the difficulty of reversing the honest block is. No matter how you look at it, the difficulty of reversing a confirmed 10 minute block is about 5 times harder than reversing a confirmed 2 minute block. The choice of a 10 minute target interval is certainly arbitrary, but a 2 minute target is no less arbitrary; and the rational for choosing 10 minutes is sound. Latency will matter if Bitcoin is ever successful enough to process significant numbers of transactions comparable to Visa or Paypal, particularly for the sole miners and end user nodes on the edges of the network. The core miners (and pools) will probably be very well connected to one another, but the edges is where the latency will be greatest.
That assumes a network propagation time to all other nodes in <1 second. Currently that is fine but someday (and we should be building bitcoin for the someday) with hundreds of thousands of nodes propagation time will be multiple seconds to reach 90% of nodes and there will always be inefficient edge cases so propagation time for last 10% of network might be double that.
Of course is all (or 90%) of the mining is done by a consortium of 10 major mining corporations which share ultra low latency links with each other that becomes a non-issue. However we shouldn't be trying to create problems where centralized control by massive mining pools is the "solution".
Of course is all (or 90%) of the mining is done by a consortium of 10 major mining corporations which share ultra low latency links with each other that becomes a non-issue. However we shouldn't be trying to create problems where centralized control by massive mining pools is the "solution".
Actually, after asking Meni Rosenfeld about it, he started to convince me that the honest hash power dilution with faster blocks is less severe than what I estimated.
For simplicity, let's assume network propagation time of 1 second, i.e. it takes 1 second for each node to broadcast the longest chain that it knows of to all other nodes.
With 2mins blocks, on average once every 120 seconds some node sends the block it found, so during the 1 second of propagating the new block, the other miners are wasting their hash power while working on a shorter chain, so 1 out of 120 seconds is being wasted on average. If there's a fork where e.g. two groups of miners work on different chains of same length then that's ok, i.e. they don't dilute any of their hash power because of this fork. So in total 1/120 of the honest hash power is being wasted, which is only 0.83%, and with Litecoin 2.5mins blocks it's only 0.66%, and with 1min blocks it's only 1.66%
Simple huh?
For simplicity, let's assume network propagation time of 1 second, i.e. it takes 1 second for each node to broadcast the longest chain that it knows of to all other nodes.
With 2mins blocks, on average once every 120 seconds some node sends the block it found, so during the 1 second of propagating the new block, the other miners are wasting their hash power while working on a shorter chain, so 1 out of 120 seconds is being wasted on average. If there's a fork where e.g. two groups of miners work on different chains of same length then that's ok, i.e. they don't dilute any of their hash power because of this fork. So in total 1/120 of the honest hash power is being wasted, which is only 0.83%, and with Litecoin 2.5mins blocks it's only 0.66%, and with 1min blocks it's only 1.66%
Simple huh?
there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication.
That's also a good point, although it is still a bit unclear how large this effect would be in reality. Maybe a good idea for setting up some simulations.The global hash rate is relevant in relation to how much hash power the attacker should have so that the proportion between honest hash power and malicious hash power is small enough to allow carrying out the double-spending attack. Assuming that this proportion is some constant number, it's false to say that only the number of confirmations matters, because of hash power dilution of the honest miners with faster blocks. In other words, if the attacker has e.g. 30% of the total hash power, waiting for 6 blocks with average 2mins blocks is less secure than waiting for 6 blocks with average 10mins blocks. Which wiki is wrong on this point? Please cite the paragraph that's wrong?
No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all.The honest hash power dilution isn't just a result of network latency, but also because there's higher probability for the event of miners finding a block at about same time, at the lower difficulty that's implied by faster block average. You appear to claim that honest hash power dilution in negligible because in effect there are no more than couple hundreds of actual miners because everyone mines in pools, but would you make the same claims if everyone were solo-mining? Note that the current situation of having only few centralized pools might improve in the future, either by using p2pool or by using protection from malicious pool operators where miners prepare the block locally and use the pool's reward address (and then the event of finding different blocks at about same time will have similar probability compared to solo-mining). So overall it's false to say that only the number of confirms matters, because if honest miners have 70% power then it's being diluted by the faster block average time, and we're just arguing about the measure of this dilution? Feel free to provide more detailed analysis...
Edit: what I wrote here is wrong, I was operating under the misconception that chain forks cause hash power dilution, which is false. Credit goes to MeniRosenfeld for correcting me, see the next post.
I'm happy to see a discussion for possible ways to make it less risky to accept payments within under 10 minutes. Changing the blockrate is one of them and I'm not saying it's the best.
In the long term, option 3 of having centralized hubs as a layer on top of bitcoin is probably the best idea, also because of scalability issues discussed here: https://en.bitcoin.it/wiki/Talk:Scalabilitythere's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication.
That's also a good point, although it is still a bit unclear how large this effect would be in reality. Maybe a good idea for setting up some simulations.The global hash rate is relevant in relation to how much hash power the attacker should have so that the proportion between honest hash power and malicious hash power is small enough to allow carrying out the double-spending attack. Assuming that this proportion is some constant number, it's false to say that only the number of confirmations matters, because of hash power dilution of the honest miners with faster blocks. In other words, if the attacker has e.g. 30% of the total hash power, waiting for 6 blocks with average 2mins blocks is less secure than waiting for 6 blocks with average 10mins blocks. Which wiki is wrong on this point? Please cite the paragraph that's wrong?
No, it's not. The proof-of-work is a Poisson generator, meaning that the expectation value for the attacker follows an decaying exponential, which is itself a function of the number of Poisson events--i.e, the number of confirmations. So the probability of overtaking the honest chain after 6 blocks on the 2min intervals is exactly the same as 6 blocks on 10min intervals--hashes/block doesn't figure into the equations anywhere at all. Faster time between blocks would also be burdensome on low trust light clients
That's a very good point I hadn't considered yet!Yeah, that's a good point that I didn't really appreciate until now, so I added it to the Litecoin wiki comparison.
Still waiting for gmaxwell to explain his other point about DOS attacks with faster average blocks
This is a perennially bad proposal. The security of an N block bury comes largely from the amount of hash power used to bury it but also from the unlikelyhood of non-trivial internet splits lasting a given amount of time. If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. Obviously there is a non-linearity at the one block boundary, but you're not talking about a one confirmation transaction.
What definition of security are you using? For any of the double-spends mentioned in this thread it is the number of confirmations that matters, irregardless of global hash rate (yes, the wiki is wrong on this point). If you think otherwise, I'd love to see the math to back it up.
The global hash rate is relevant in relation to how much hash power the attacker should have so that the proportion between honest hash power and malicious hash power is small enough to allow carrying out the double-spending attack. Assuming that this proportion is some constant number, it's false to say that only the number of confirmations matters, because of hash power dilution of the honest miners with faster blocks. In other words, if the attacker has e.g. 30% of the total hash power, waiting for 6 blocks with average 2mins blocks is less secure than waiting for 6 blocks with average 10mins blocks. Which wiki is wrong on this point? Please cite the paragraph that's wrong?
We've had this discussion, and several like it, many times on this forum over the past two years. I can assure you, the answer is no the target interval will not be changed.
I know and I understand that, however what might have changed since the last time I saw this discussion, is that we now have a few somewhat working proof of concepts with the alt-coins and the mining infrastructure has become more concentrated.Faster time between blocks would also be burdensome on low trust light clients
That's a very good point I hadn't considered yet!Finally, and perhaps most importantly: Any fundamental change in the distributed protocol will not be accepted by rational bitcoin users (unless its some bugfix essential for bitcoin's survival).
I'm not so sure about that. Consider for example the extension of the divisibility - a compatibility breaking change that is regarded as absolutely unproblematic because nobody is expected to object.If we have a consensus that a change is beneficial for Bitcoin then such a change might very well be accepted by a rational Bitcoin user.
As for the more frequent reorgs: everything relying on Bitcoin should be able to deal with reorgs - even at the current blockrate.
Now I can see all your objections, but I'm not yet convinced that this change would make Bitcoin overall significantly worse (apart from maybe the issue with the light clients - which is a very valid point!).
Lets face it: 10 minutes is a pretty arbitrary constant which is arguably on the conservative side when it comes to compensating for network delay. I'm pretty sure many would defend 6 minutes just the same right now if Satoshi had chosen 6 minutes instead (disregarding the fact that making it lower then would be less attractive).
there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication.
That's also a good point, although it is still a bit unclear how large this effect would be in reality. Maybe a good idea for setting up some simulations.I understand the reluctance to change the Bitcoin contract but I feel it should be possible to discuss such changes objectively based solely on their relative merits. The network effect is all great and gives us an advantage over the competitors right now, but it is not very far-sighted to argue from the standpoint that every fundamental change to Bitcoin is necessarily bad.
I'm happy to see a discussion for possible ways to make it less risky to accept payments within under 10 minutes. Changing the blockrate is one of them and I'm not saying it's the best. I would for example really like to see a listening period be agreed upon and implemented in the client.
This is a perennially bad proposal. The security of an N block bury comes largely from the amount of hash power used to bury it but also from the unlikelyhood of non-trivial internet splits lasting a given amount of time. If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security. Obviously there is a non-linearity at the one block boundary, but you're not talking about a one confirmation transaction.
What definition of security are you using? For any of the double-spends mentioned in this thread it is the number of confirmations that matters, irregardless of global hash rate (yes, the wiki is wrong on this point). If you think otherwise, I'd love to see the math to back it up.
Then you better not read the previous page where a few are saying that people should accept all but expensive txn's at 0 confirms ...
0 confirms for inexpensive txns, while scanning the network to detect double-spending attempts, is discussed here: https://en.bitcoin.it/wiki/Myths#Point_of_sale_with_bitcoins_isn.27t_possible_because_of_the_10_minute_wait_for_confirmation
The point about machine guns is how many confirms should the GUI client wait for, before indicating to the user that the txn is secure. Suppose everyone agreed with your 2mins blocks idea, are you suggesting that the official client wait for 6 confirms or 30 confirms? If you're suggesting 6 confirms that's where the machine guns analogy could be valid.
Then you better not read the previous page where a few are saying that people should accept all but expensive txn's at 0 confirms ...
Quote
If you half the hash power required to get N blocks, then you double the number of blocks you need for the same security.
I have already answered that by saying that if people want the same txn security they already have, then they simply wait for 5x the confirms - problem solved!That's inaccurate, there's a tradeoff between gambler's ruin initial deficit and honest hash power dilution due to detrimental effects on the orphan rate and network communication. See more details in "faster transaction time" section of https://github.com/coblee/litecoin/wiki/Comparison-between-Bitcoin-and-Litecoin
kano: it's quite obvious that what's gonna happen in reality is that with 2mins blocks almost everyone will still wait for 6 confirms instead of 5x6 confirms, i.e. you propose something like giving away free machine guns to the entire population and saying don't worry about shooting incidents because people can choose not to use them.
Quote
Faster time between blocks would also be burdensome on low trust light clients— which don't need to know much but they do need to know the block headers. Requiring 4x the storage on mobile phones is not nice.
Um ... do any of these exist?Yes.
Jump to: