Suggested MAJOR change to Bitcoin

[MoonShadow]

Well, that depends on what the paywall is for, but as a smallish solo miner I'd sure like to get a few songs/ebooks/games for free every month from every website that accepts 0 confirmation transactions. The combined incentive for an attacker might make this quite attractive! But then again, this would promote solo-mining which is probably a good thing for Bitcoin after all

The thing with websites and digital goods is that such an attack could be completely automated - the miner doesn't have to do anything, just make a small script that quickly buys all kinds of stuff before he issues a block that reverses the transaction.

This would only work once, because it would be evident that such an event has occurred after the fact.  It would be fraud, and easily provable, and thus carries the same legal risks; and would immediately crash your "credit" with those affected vendors.  If this happens enough, those vendors will not accept bitcoin so easily without identifying information; but anonimity was never a certainty.  I have no anonimity with any of the vendors that I have traded with, it's just that no one else outside of the transaction has that data like is necessary with Paypal or Visa transactions.  Said another way, the transaction isn't tied to my identity in records except those that the vendor may keep.  Don't count on being anonymous to your vendors.

[finway]

You are a "Hero" man,
I'll just give you that:
Confirmations are not relative to security,
it's only relative to respending.


For a respending , 10minutes waiting is affordable.

[MoonShadow]

Very few transactions are vulnerable to this type of attack thus the value of making a breaking change seems inconclusive.

Once again: if the change was deemed beneficial, it wouldn't need to justify the breaking change all by itself but if we have this discussion now, we can potentially implement this once a breaking change is necessary for other reasons.

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.  For all the reasons already presented to you and others as well.

[kano]

I think DeathAndTaxes has brought up some very good arguments as to why 0 confirmations is just fine to just about every transaction type.  I've always had a hunch that direction, but never bothered to do the research and figure out why.

But, the fact of the matter is, I've never heard of anyone successfully executing a double-spend attack.  Until we do hear of that happening, why are we so worried about it?

I agree that merchants should seriously look in to using 0-confirmation transactions.  It would help Bitcoin become more viable, and encourage people to use Bitcoins for purchases.

Well the double spend has happened on one of the exchanges with a scamcoin (not sure which one)

I think you might be thinking of the supernode being spoofed in Solidcoin, which was a different event.  Bitcoin doesn't use supernodes for this exact reason.

Actually I think it was doublec's exchange, so nothing to do with the %!$#%@$% SolidCoin 2.0

... wanders off to search for the post on the subject ... hmm it was i0coin and doublec's exchange ... still searching ...

Here: https://bitcointalk.org/index.php?topic=36425.msg554140#msg554140

[gmaxwell]

OK, anyone who has dealt with any of the recent scamcoins (especially LTC) will have noticed one big scamcoin advantage that shows why Bitcoin will never be adopted in a big way:
transaction confirm times.
Simply put, a 5 transaction confirm is regularly over an hour (especially during the recent excessively slow difficulty readjustments - slow due to the code design ignoring the reality of the recent down turn)
Yet there is a reasonably straight forward solution that has a collection of advantages and only one disadvantage:
My solution: decrease the block time to 2 minutes and decrease the block payout to 10 bitcoins.

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.

Reducing the inter-block time further reduces security by creating additional hash power dilution:  When many blocks are found faster than the global communication time of the network (which, if you observe LP skews between pools, can already be up to a minute) then the network there will be may more short term forks and attackers can gain additional advantage by allowing their target to land in one fork, while applying their own power to another fork. The dilution also generally gives single large (good or bad) miners an additional advantage because of their improved power concentration.

A faster block time still is far too slow for "instant transactions" of the POS kind. So we have no less need for solutions for that, and when we have mature solutions for that then your whole concern is mostly moot.

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.

The increase block rate also increases exposure to DOS attacks marginally.

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).   If we were willing to change this— whats next? The subsidy? The geometric decline?  Start skimming 5% off to send to a Glorious Leader?    Changes to the immutable bitcoin distributed algorithm would _seriously_ undermine trust and rightfully so.  We may be stupid, we're not that stupid.

[kano]

Firstly, finally a response against the idea that isn't one of:
 1) Change is bad - don't change anything
and/or
 2) Everyone on the planet who deals with Bitcoin transactions does it wrong and no one is going to fix that

Meanwhile:

...
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).   If we were willing to change this— whats next? The subsidy? The geometric decline?  Start skimming 5% off to send to a Glorious Leader?    Changes to the immutable bitcoin distributed algorithm would _seriously_ undermine trust and rightfully so.  We may be stupid, we're not that stupid.

I don't really think a stupid response it relevant ...

... and ... my suggested change has no effect at all on the production rate of bitcoins or who should get them other than the people and pools that mine them.

Meanwhile I doubt the validity of some of what you have said based on LTC and how it already functions well in the real world.

Also:

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!

But again, change isn't bad by definition.

You are simply saying that the current value is correct and less security is incorrect.
Not what the difference actually is or why we must use the current value.

Reducing the inter-block time further reduces security by creating additional hash power dilution:  When many blocks are found faster than the global communication time of the network (which, if you observe LP skews between pools, can already be up to a minute) then the network there will be may more short term forks and attackers can gain additional advantage by allowing their target to land in one fork, while applying their own power to another fork. The dilution also generally gives single large (good or bad) miners an additional advantage because of their improved power concentration.

I usually mine multiple pools and have never seen two pools LP a minute apart (even when I was mining 5 pools at the same time back when there were major network problems and the big pools kept getting ddos'd)
2 minutes was chosen since it is above such problems and has shown in the real world to work well.

That additional advantage for large miners has not shown to exist in any scamcoin except at their start when the difficulty was well below what it should be.
(though I managed to make over 30BTC in the first 2 days of LTC with my low power CPU mining ...)

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?

The increase block rate also increases exposure to DOS attacks marginally.

I'd say the opposite.
Can you give an example of why?
My example would be that the network has to deal with a small amount of extra data and thus a ddos attack is relatively somewhat less effective since the difference between normal and ddos is slightly less.

[2112]

(which, if you observe LP skews between pools, can already be up to a minute)

It makes me wonder: have any of the pool operators tried to implement long poll with Twitter?

I kinda understand their pain: how to implement a reliable multicast when seemingly the only tool available is a massive abuse of unicast?

[MoonShadow]

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.

[iddo]

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.

[kano]

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 ...

[iddo]

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.

[maaku]

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.

[wareen]

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.

[iddo]

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?

[iddo]

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

[maaku]

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 power dilution is approximately the network latency of the dishonest network minus the network latency of the global (honest) network, divided by the expected block interval. As a consequence, it has little difference if we're talking about dishonest pools. Given that the current network latency is about 2 seconds, it has very little effect at all. We can get well under a minute before it even starts being measurable.

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.

[iddo]

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:Scalability

[iddo]

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 power dilution is approximately the network latency of the dishonest network minus the network latency of the global (honest) network, divided by the expected block interval. As a consequence, it has little difference if we're talking about dishonest pools. Given that the current network latency is about 2 seconds, it has very little effect at all. We can get well under a minute before it even starts being measurable.

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.

[iddo]

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?

[DeathAndTaxes]

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".