Why not 10 coins per block and a block every 2 minutes?

[MoonShadow]

Keep in mind, that if the average interval were reduced, then the incidence of a blockchain split increases dramaticly.  In a future with many times the number of nodes in the p2p network, the odds that such a blockchain split could persist beyong one block, and even split again, also increases.  There is some, largely unknown, point of network size (and thus average network latency) with a low enough interval that such network splits become the norm, rather than the exception.  Although this is a self-healing issue, as network splits also split the hashing pool while maintaining the difficulty for both sides; frequent and persistant blockchain splits not only increase the average time between confirmations (from the perspective of any single transaction, not the network as a whole) it also could introduce a double spending 'window of opprotunity' on an often enough basis to make it a viable attack.  Mostly, the 10 minute interval was an arbitarty design decision, with a best guess as to the future size of the network.

[1714131618]

1714131618

[1714131618]

1714131618

[1714131618]

1714131618

[netrin]

MoonShadow are you claiming that latency increases dramatically with more nodes in the network? Rather than requiring more hops, shouldn't all nodes of the network attempt to increase its share of connections? While worst case latency should increase, I would expect best and average case latency to be reduced (or at least scale O(log)) with a larger network size.

[ctoon6]

block chain splitting is irreverent AFAIK. this is because only the longest chain will survive. and if you are connected to a decent amount of nodes, then your transaction may very well make it into both chains so it would not matter. and as far as wasting hashing power goes, it does not matter, so what you wasted 30 seconds. that's only 10% of the total time, and nearly everyone else would be in the same boat. and 30 seconds is a large exaggeration. and as said before, we could make little miniature networks, where miners specifically make a point to connect to other miners, in addition to normal not mining nodes. in response to what was said earlier about this, i say that there be multiple lists where miners can submit their ip address.

Another solution to make the network more redundant would to create a new protocol. this would include a new type of node called an exchange node. it tells who to connect to who, to be the most efficient. you obviously would want to make it open source, and only connect to trusted exchange nodes.

here is an image i made of a network with exchange nodes, it does not show much, i mostly made it for fun

[bji]

Really transactions themselves are instant, broadcast through the network, confirmations are only required if your worried about double spending, if you see the transaction in your client, even if you have no confirmations you know that the transaction is valid unless someone has 51%, if you really think someone is going to pull a 51% attack for a sandwich you can wait a few minutes.  

I disagree.  Just because you saw a transaction doesn't mean that it will end up in the block chain.  Miners may never see it; especially in the hypothetical future in which bitcoin is used for point of sale transactions (I am very, very confident that this will never happen), then the number of transactions will be huge and I would not expect them to be very reliable.  Believing that just because you saw a transaction go by means that it will end up in the block chain is just like believing that just because a router saw a UDP packet go by, it will make it to its destination.  I can't imagine any significant retailer being willing to part with real goods based on the promise of a transaction that may or may not end up in the block chain.

Also this whole idea of trying to watch the transaction stream to detect double spend attempts is based on the opposite side of this flawed concept; in this case, that every transaction that will make it into the block chain will be seen by every peer.  If this were true, then in this hypothetical future, every peer would be spending a HUGE amount of bandwidth accepting and forwarding transactions (because there would be at least 100 transactions per second).

I can't imagine why the majority of people in this hypothetical future wouldn't just always send double-spend attempts with every transaction; since the transaction is pseudoanonymous you aren't risking anything.  It would be standard practice to wait until the vendor accepted your transaction (by seeing it on the network, not seeing it in the block chain) and then gave you the product, then you'd immediately send out a spend of the same bitcoin to yourself.  If you are lucky, you win and your second transaction ends up in the block chain first.  If you are unlucky, you lose, and really lose nothing since you just completed the transaction normally.  Even if you only won 1 out of 1000 times, why wouldn't people do this every time just so that every once in a while they got something for free?  And if people are doing this regularly, what vendor is going to accept a nonverified transaction for their goods when they know there is a 0.1% chance (actually higher than 0.1% chance because there is also the chance that the transaction will never make it into the block chain in addition to the chance that an attempted double-spend will succeed) that they will never see the money?

[ttk2]

Really transactions themselves are instant, broadcast through the network, confirmations are only required if your worried about double spending, if you see the transaction in your client, even if you have no confirmations you know that the transaction is valid unless someone has 51%, if you really think someone is going to pull a 51% attack for a sandwich you can wait a few minutes.  

I disagree.  Just because you saw a transaction doesn't mean that it will end up in the block chain.  Miners may never see it; especially in the hypothetical future in which bitcoin is used for point of sale transactions (I am very, very confident that this will never happen), then the number of transactions will be huge and I would not expect them to be very reliable.  Believing that just because you saw a transaction go by means that it will end up in the block chain is just like believing that just because a router saw a UDP packet go by, it will make it to its destination.  I can't imagine any significant retailer being willing to part with real goods based on the promise of a transaction that may or may not end up in the block chain.

Also this whole idea of trying to watch the transaction stream to detect double spend attempts is based on the opposite side of this flawed concept; in this case, that every transaction that will make it into the block chain will be seen by every peer.  If this were true, then in this hypothetical future, every peer would be spending a HUGE amount of bandwidth accepting and forwarding transactions (because there would be at least 100 transactions per second).

I can't imagine why the majority of people in this hypothetical future wouldn't just always send double-spend attempts with every transaction; since the transaction is pseudoanonymous you aren't risking anything.  It would be standard practice to wait until the vendor accepted your transaction (by seeing it on the network, not seeing it in the block chain) and then gave you the product, then you'd immediately send out a spend of the same bitcoin to yourself.  If you are lucky, you win and your second transaction ends up in the block chain first.  If you are unlucky, you lose, and really lose nothing since you just completed the transaction normally.  Even if you only won 1 out of 1000 times, why wouldn't people do this every time just so that every once in a while they got something for free?  And if people are doing this regularly, what vendor is going to accept a nonverified transaction for their goods when they know there is a 0.1% chance (actually higher than 0.1% chance because there is also the chance that the transaction will never make it into the block chain in addition to the chance that an attempted double-spend will succeed) that they will never see the money?

Double spending requires 51% of the total computer power, i really don't think someone is going to spend the millions needed to gain 51% to get out of paying for a sandwich.



100tps is less than 500k a second, that's a pitiful amount of bandwidth. Even at 2000tps the average home internet connect (at least where i live) could keep up (bandwidth limits would be an issue, but no one will be running a super-node on a home connection). So, lets assume that you modify your client to allow you to double spend (no mean feat in the first place) then you attempt to double spend, when you broadcast a transaction peers check if that transaction is possible before forwarding it, hence any peer that received your first transaction would detect the conflict and not rebroadcast your second one. So unless you get all new peers your second transaction will stop before it even makes one hop, lets assume you do get new peers, your first transaction has already spread through most of the network, and the majority of peers reject it, meaning that they will reject a block that contains it as well, when this happens it comes down to majority vote, since your first transaction was broadcast first and spread throughout the network and no nodes that received the first transaction propagate the second the first transaction will always have a majority. Even better, stores could set up their clients to alert them when such a vote was in progress, meaning they would be notified if you spend the coins in line and then tried to re-spend them at the counter (the only real way to do this is to spend the coins before you use them to buy goods otherwise the first transaction will always win) they would know instantly that you attempted a double spend. This problem has been fixed.

[bji]

Double spending requires 51% of the total computer power, i really don't think someone is going to spend the millions needed to gain 51% to get out of paying for a sandwich.

Either you or I don't understand what 'double-spend' means in Bitcoin.  I think that double-spend means issuing two conflicting transactions which would both spend the same bitcoin.  It doesn't mean both transactions being accepted into the block chain.  Having them both accepted into the block chain would require "51%" (which itself is not even likely to guarantee success; you'd need something more, like maybe 75%, to have a chance of consistently beating everyone else), but you don't need for them both to be accepted into the block chain to successfully execute double-spend fraud.  All you need to execute double-spend fraud is to get someone to believe that a transaction that spends a bitcoin is legitimate while getting someone else to believe that a different transaction that spends the same bitcoin is legitimate.  Now you've 'spent' the same coin twice, although one of those two (or maybe even both, who knows) will in the end never make it into the block chain and the person who accepted that transaction has been duped.

You don't need any hashing power at all to issue such a double-spend fraud; all you need is for the recipient to accept your transaction at face value without waiting for it to be confirmed multiple times in the bitcoin block chain.  And I'm saying that vendors will not accept this risk, so proposals that expect vendors to just accept that transactions will make it into the block chain "eventually" are dead before they even get started.

100tps is less than 500k a second, that's a pitiful amount of bandwidth. Even at 2000tps the average home internet connect (at least where i live) could keep up (bandwidth limits would be an issue, but no one will be running a super-node on a home connection). So, lets assume that you modify your client to allow you to double spend (no mean feat in the first place) then you attempt to double spend, when you broadcast a transaction peers check if that transaction is possible before forwarding it, hence any peer that received your first transaction would detect the conflict and not rebroadcast your second one. So unless you get all new peers your second transaction will stop before it even makes one hop, lets assume you do get new peers, your first transaction has already spread through most of the network, and the majority of peers reject it, meaning that they will reject a block that contains it as well, when this happens it comes down to majority vote, since your first transaction was broadcast first and spread throughout the network and no nodes that received the first transaction propagate the second the first transaction will always have a majority. Even better, stores could set up their clients to alert them when such a vote was in progress, meaning they would be notified if you spend the coins in line and then tried to re-spend them at the counter (the only real way to do this is to spend the coins before you use them to buy goods otherwise the first transaction will always win) they would know instantly that you attempted a double spend. This problem has been fixed.

You expect every merchant to maintain a 500 kbps feed just so that they can accept transactions immediately while at the same time exposing themselves to the risk of double-spend?  Not going to happen, ever.  This problem has NOT been fixed.

Consider also that even if a merchant did bother to maintain a 500 kbps feed and assumed that just because they did, everyone else was doing the same and that transactions in Bitcoin were just about guaranteed to cross their feed nearly immediately.  Now this means that they have to *store* all of those transactions continuously as well, because they never know when someone is going to walk into their store and make a point-of-sale bitcoin purchase for which they'll have to evaluate the transaction to ensure that it's not a double-spend.  And in order to do that, they'll have to have a record of all of the outstanding transactions that aren't in blocks yet to know whether or not there was already a transaction that spent the bitcoin in question.  In other words, they'll have to remember all transactions not in blocks just to be sure that a user can't just send a bitcoin to himself 5 minutes before sending it to the merchant.

The only sane thing that merchants can do is to trust the block chain.  It is a much smaller set of data (one per 10 minutes), much more readily verified, and it already contains all of the work of tracking and filtering out double-spends.  THAT IS WHY IT EXISTS.  If merchants don't use the block chain then they might as well not require any validation at all.

[MoonShadow]

MoonShadow are you claiming that latency increases dramatically with more nodes in the network? Rather than requiring more hops, shouldn't all nodes of the network attempt to increase its share of connections? While worst case latency should increase, I would expect best and average case latency to be reduced (or at least scale O(log)) with a larger network size.

Latency can increase due to both an increase in the nodes of the network as well as a concurrent increase in per node bandwidth.  As more transactions are flying around, the load upon the nodes' cpu's also increase as this cannot be performed by GPUs at this point, and must be performed by the CPU.  High loads will result in a buildup of unconfirmed transaction queues, at least occasionally, even on dedicated hardware.  The transactions cannot propogate to the next set of nodes until they are verified, so this compounds the latency.  The same is true with a released block solution, as they cannot propogate until they are verified.  Increasing the number of peer connections would compensate for this effects somewhat by reducing the average number of hops necessary to flood the network, but at the cost of permanently increased bandwidth consumption.  At some point of increase, the cost of adding new peers outweighs the value of lower latency, and then new peer connections will cease.  Some nodes won't even have as many peer connections as the current client expects, as I already intentionally limit the number of peers my own node communicates with.  It's not in my own interest to have more than enough peers to be fairly certain that I'm not being screwed with, since I don't mine.  I'd say that it's a reasonable expectation to expect that average network latency will increase at a rate greater than linear against the growth rate of network nodes.

[netrin]

block chain splitting is irreverent AFAIK. this is because only the longest chain will survive.

Given constant latency, waste increases EXPONENTIALLY as block generation time decreases until waste is greater than effect. Splitting DOES matter. Forget about the general users. Focus on the MINERS and the problems of latency and splitting will become clear.

Suppose splits represent 0.5% of blocks today and wasted cycles during latency 1%. If you divide the block generation time in half to 5 minutes, waste become 3%. 2:30 minutes 6%, 1:15 minutes 12%, 37.5 seconds 24%, 20 second blocks 50% waste, 10 second blocks 100% wasted cycles. The numbers might be off, but that's the general gist of the problem.

Now does a user care about waste? No not directly. Does he need confirmations? Not in most cases. Does the network care about waste? Absolutely. Does waste make the network less robust and insecure? YES.

Latency can increase due to both an increase in the nodes of the network as well as a concurrent increase in per node bandwidth.......At some point of increase, the cost of adding new peers outweighs the value of lower latency, and then new peer connections will cease......It's not in my own interest to have more than enough peers to be fairly certain that I'm not being screwed with, since I don't mine.  I'd say that it's a reasonable expectation to expect that average network latency will increase at a rate greater than linear against the growth rate of network nodes.

Interesting. Thanks for the response. Would you expect miners will at least try to connect to the majority of big miners/pools? I do, because it will cut down on their wasted cycles the faster they hear about new blocks generated and each miner will want the network to begin hashing away at his newly awarded coins/fees. It should be in all miners best interest to connect to each other very tightly.

I'm not concerned about non-miners (in regard to block generation). They will get their confirmations soon enough. As long as users have the ability to inject their transactions in reasonable time, their latency is nearly irrelevant. I would love to receive confirmations within a second, but I value a robust network far more.

[MoonShadow]

I should have been more explict in my double-spend attack comment.  The reason that I said that decreasing the average block interval could increase the risks of a double spend attack is because at some latency level blockchain splits become the norm.  Under these conditions, it's possible for an unscrupulous person to have his client hacked in such a manner that, for every honest spending transaction he engages in, another dishonest transaction is produced that spends those same coins back to another of his own addresses is produced 20 seconds later and sent to a random but topographicly distant node.  As long as latency is significantly below the average block interval, this would never matter.  And if many people started to do this as a matter of course, the present node permits the savvy user to monitor transactions, and if a double spend attempt is seen within the average latency time, both transactions are rejected by such nodes.

Yet, if the latency crosses that afore mentioned point, and blockchain splits become the norm, it then becomes possible for that unscrupulous user to time the release of his second transaction so that, even though it's practically impossible for the second one to gain the majority of nodes before the first one does, the possibilty exists that a multi-block chain split could permit the honest transaction to be confirmed for one or more blocks without destroying the dishonest transaction.  There then remains a (still fairly remote) possiblity that the honest transaction, even confirmed, isn't in the majority blockchain and is reversed once the block split is repaired by normal operations.  If that is the case, then the dishonest transaction has a better than even chance of becoming the transaction accepted into the permanent chain.  This would mean that opprotunisticly dishonest clients would exist that run in an honest manner so long as there was no blockchain split, but anytime that they detected a blockchain split (yes, they are detectable, most of the time) this kind of opprotunistic attack would be seen.

[netrin]

This topic has forked into at least three... all fairly divergent from the OP. I'll inject my double-comment here.

Having them both accepted into the block chain would require "51%" (which itself is not even likely to guarantee success; you'd need something more, like maybe 75%, to have a chance of consistently beating everyone else)

And 99% would be better still. But 51% is fine enough. Maybe it fails sometimes, but you'll likely win most of the time. Wait for a new block, inject transaction, immediately crank out a block, maybe TWO before broadcasting your longer chain to the network. With 51% hashing power you're statistically guaranteed to beat the network most attempts. You'll know soon enough if you've lost.

all you need is for the recipient to accept your transaction at face value without waiting for it to be confirmed multiple times in the bitcoin block chain.  And I'm saying that vendors will not accept this risk, so proposals that expect vendors to just accept that transactions will make it into the block chain "eventually" are dead before they even get started.

Topic #2: That depends on the sale. It's similar to concerns over counterfeit fiat. If a child comes into the shop and text/SMS's 0.001 BTC for a gum drop, I'll accept without a blink. If someone is buying my car, I might invite him in for a coffee and wait for ten confirmations.

Topic #4: I've done a few trades on OTC and always look to the blockexplorer and send the transaction/address link to the counterparty. If a 0/confirmation floating transaction ticker service was provided (juiced directly into the mining circle), I'd accept small transactions as soon as it was seen by the network. That is of course, until splits and double-spending attacks were the norm. By then, I expect we'll have dozens of auxiliary services nullifying all of these concerns.

[ctoon6]

Given constant latency, waste increases EXPONENTIALLY as block generation time decreases until waste is greater than effect. Splitting DOES matter. Forget about the general users. Focus on the MINERS and the problems of latency and splitting will become clear.

Suppose splits represent 0.5% of blocks today and wasted cycles during latency 1%. If you divide the block generation time in half to 5 minutes, waste become 3%. 2:30 minutes 6%, 1:15 minutes 12%, 37.5 seconds 24%, 20 second blocks 50% waste, 10 second blocks 100% wasted cycles. The numbers might be off, but that's the general gist of the problem.

Now does a user care about waste? No not directly. Does he need confirmations? Not in most cases. Does the network care about waste? Absolutely. Does waste make the network less robust and insecure? YES.

your throwing in a bunch of irrelevant information, nobody said anything about blocks more often than every 2 minutes. i doubt it would ever go below 5. i even doubt it ever gets changed to begin with.

you also don't take into account for newer network equipment that would increase data throughput and lower overall latency.

[netrin]

Given constant latency, waste increases EXPONENTIALLY as block generation time decreases until waste is greater than effect. Splitting DOES matter. Forget about the general users. Focus on the MINERS and the problems of latency and splitting will become clear.

Suppose splits represent 0.5% of blocks today and wasted cycles during latency 1%. If you divide the block generation time in half to 5 minutes, waste become 3%. 2:30 minutes 6%, 1:15 minutes 12%, 37.5 seconds 24%, 20 second blocks 50% waste, 10 second blocks 100% wasted cycles. The numbers might be off, but that's the general gist of the problem.

Now does a user care about waste? No not directly. Does he need confirmations? Not in most cases. Does the network care about waste? Absolutely. Does waste make the network less robust and insecure? YES.

your throwing in a bunch of irrelevant information, nobody said anything about blocks more often than every 2 minutes. i doubt it would ever go below 5. i even doubt it ever gets changed to begin with.

Dude. What is the TITLE of this thread?

2 minutes means that at CURRENT network size about 10% of hashing power is wasted. It means that your 1/unconfirmed block is 10% likely to be invalid. As MoonShadow convincingly argues latency is likely to INCREASE not decrease. And no, I don't suggest we change the algorithm either. I'm just trying to point out why lowering it should not be considered at all. If you speed up confirmations but those confirmations are more likely invalid, they are no confirmation at all. 1% error is still pretty high!

you also don't take into account for newer network equipment that would increase data throughput and lower overall latency.

worst case physical limit latency = 0.07 s = 20000 km Earth semi-circumference / 300000 km/s speed of light
typical point to point latency today 0.1 s
average bitcoin node latency 2.11 s

How much do you hope the bitcoin network will grow?

[ctoon6]

What difference would it make, EVERYONE would be wasting 10%, just like everyone is wasting 1% now. so why would it matter. if it bothers you that the network would be less secure, then wait 10 minutes or 2 blocks or however long you like.

[MoonShadow]

Would you expect miners will at least try to connect to the majority of big miners/pools? I do, because it will cut down on their wasted cycles the faster they hear about new blocks generated and each miner will want the network to begin hashing away at his newly awarded coins/fees. It should be in all miners best interest to connect to each other very tightly.

They already do.  I'd bet dollars to doughnuts that at least half of the top ten pools have direct links to each other.  However, in a future that Bitcoin is wildly successful, single hop peer connections to those major miners (whether they continue to be user pools, or Wal-Mart's own datacenter) will be valuable enough to companies that serve mom & pop stores, smaller retail chains, and business associations that the major miners could stand to charge connection fees to those groups.  When that happens, the clients of those 2nd tier mining/POS companies will have lower average latency than the end user, and thus would be better protected from casual theft/fraud attempts, but the average network latency for the average end user/Android client could be terrible.  It's not unreasonable to expect there to be five hops or more from the largest miner to the average droid wallet in another two years.  Since blocks can be expected to be much larger on average as well, the CPU times and transmission times for each hop are going to start to tally up.  The average is over 2 seconds now, and the network is relatively small and low volume.  Imagine 500 times the nodes, 100+ times the transaction volume and an average block size of 700 Kilobytes.  The end to end network latency could easily push 2 minutes.

[bji]

And 99% would be better still. But 51% is fine enough. Maybe it fails sometimes, but you'll likely win most of the time. Wait for a new block, inject transaction, immediately crank out a block, maybe TWO before broadcasting your longer chain to the network. With 51% hashing power you're statistically guaranteed to beat the network most attempts. You'll know soon enough if you've lost.

With 51% hashing power it would take quite a while to get 6 blocks ahead of the competition.  Plenty of time for your fraud to be discovered and for the network to take action against you.  You need considerably more hashing power to have a reasonable chance of forcing blocks through at a rate fast enough that the network cannot react.

[netrin]

I imagine a malicious node (or clustered nodes) with majority power has better than not chance of beating the network by definition. If he does not broadcast the first winning block, but waits for two winning blocks, then the network will rightly accept his block chain. If he does not win after two blocks, then he does not broadcast at all. Because of statistical deviation, the network will be rightly concerned, but I don't think there's much the network can do about it in the short term.

Satoshi posits that any would be malicious but typically greedy node has a greater incentive to mine legitimately than to try to double spend. However, this incentive does not apply to a truly malicious node who wishes to see the entire bitcoin economy collapse at any cost. With the economy well under 1 B USD, I think this attack is still quite plausible.

And 99% would be better still. But 51% is fine enough. Maybe it fails sometimes, but you'll likely win most of the time. Wait for a new block, inject transaction, immediately crank out a block, maybe TWO before broadcasting your longer chain to the network. With 51% hashing power you're statistically guaranteed to beat the network most attempts. You'll know soon enough if you've lost.

With 51% hashing power it would take quite a while to get 6 blocks ahead of the competition.  Plenty of time for your fraud to be discovered and for the network to take action against you.  You need considerably more hashing power to have a reasonable chance of forcing blocks through at a rate fast enough that the network cannot react.

[bji]

I imagine a malicious node (or clustered nodes) with majority power has better than not chance of beating the network by definition. If he does not broadcast the first winning block, but waits for two winning blocks, then the network will rightly accept his block chain. If he does not win after two blocks, then he does not broadcast at all. Because of statistical deviation, the network will be rightly concerned, but I don't think there's much the network can do about it in the short term.

But if his "lead" is so tenuous that it's only 51% then he's taking a big gamble by devoting so much hashing power to trying to produce two valid blocks before anyone else produces one.

Anyway 51% isn't a magic number if this is what a cheater is trying to do.  You can with 40% hashing power try to do the same thing.  You'll have less chance of getting your two block lead than the 51% guy but not a huge amount less.

EDIT:

Allow me to elaborate, and see if my math is correct.

With 51% hash power, a peer has 51% chance of producing a block before anyone else does.
The chance of producing two blocks before anyone else does is .51^2, or 26%.

With 40% hash power, the same calculation (0.4^2) is 16%.

Thus with 51% hash power your odds of being able to produce two blocks before anyone else produces one is only 10% better than with only 40% hash power.  Of course you are continually attempting to produce two blocks so your chances of producing two blocks before any one else can be expressed as a function of the number of blocks that you've been trying to do this for.

	1	2	3	4	5	6
51%	26%	45.3%	59.5%	70%	77.9%	83.6%
40%	16%	29.5%	40.8%	50.3%	58.2%	64.9%

I calculated the above table for each hash power H as:

f(n) = 1 - ((1 - H^2)^n)

The table shows that after 6 rounds, or approximately 1 hour at 10 minute average block generation intervals, someone with 51% hashing power has an 83.6% chance of having successfully produced two deviant blocks in a row to immediately add to the top of the block chain.  Someone with 40% hashing power will have a 64.9% chance after 6 rounds of succeeding similarly.  The difference of success after 6 rounds is only 18.7%, so I don't see why just having 40% hashing power would prohibit someone who wanted to cheat in this way from making the attempt (they'll just have to try a little longer, that's all; they'll need e.g. 14 rounds for 90% chance of having succeded whereas the 51% cheater only needs 8 rounds for 90% chance of having succeeded).

Someone with 75% hashing power would only need 3 rounds for 90% chance of success.

Of course, all of the above is predicated on announcing the deviant blocks as soon as they are discovered so that everyone else accepts them into the chain everyone starts over again with computing the next block.

The chance of computing 2 blocks in the same time that it takes someone else to compute 1 is more difficult to calculate.  I think it may require integration.  I'll have to think about it a bit ...

[netrin]

With 51% hash power, a peer has 51% chance of producing a block before anyone else does.
The chance of producing two blocks before anyone else does is .51^2, or 26%.

With 40% hash power, the same calculation (0.4^2) is 16%.

Thus with 51% hash power your odds of being able to produce two blocks before anyone else produces one is only 10% better than with only 40% hash power.  Of course you are continually attempting to produce two blocks so your chances of producing two blocks before any one else can be expressed as a function of the number of blocks that you've been trying to do this for.

I'm happy to see numbers thrown down and I think you make your point well. This is my third attempt at rebuttal rewrite.

As soon as the attacker wins a block he can broadcast his alternate chain. The honest nodes should accept the winning chain. If the attacker times his attack well (releases double-spend on the network immediately after the previous block) he has a 51% chance of winning the first block. If he looses, then he can continue without broadcasting.

I'm not sure how to calculate his chance of completing the first block and winning the second block before the honest nodes win the second block, but let's say he has 26% chance (I think it is sig. higher). If he fails to win that block, then he must continue without broadcasting until he catches up and wins the third block with (I don't know) 13% chance. Even if the attacker waits an entire block to launch his attack, he can just hash away (at 51% power) until he catches and surpasses the honest network. If he has unlimited time and resources, I believe he is guaranteed to win eventually.

I am tempted to agree with your calculations for the 51% hash power attack, but I can not agree with the 40% on pure intuition, unless you are calculating each block discreetly (the chance that he wins any one of six rather than an entire chain of six). If the 40% hash power attacker has a 65% chance of winning a six block chain then the honest network with 60% hash power could have only had a 35% chance of winning the same block chain. That can't be right.


Edit #4: We're talking past each other...

produced two deviant blocks in a row to immediately add to the top of the block chain

You are calculating the chance that any single attack of many attacks will succeed. I am discussing the chance that an attacker will win a single attack by chasing the block chain. I'm claiming that a 51% hash power attacker can always win (with unlimited time and resources) while a 49% hash power attacker, if he doesn't win immediately will have diminishing chances as time goes on (even with unlimited time and resources).

[kjj]

Allow me to elaborate, and see if my math is correct.

With 51% hash power, a peer has 51% chance of producing a block before anyone else does.
The chance of producing two blocks before anyone else does is .51^2, or 26%.

With 40% hash power, the same calculation (0.4^2) is 16%.

Thus with 51% hash power your odds of being able to produce two blocks before anyone else produces one is only 10% better than with only 40% hash power.  Of course you are continually attempting to produce two blocks so your chances of producing two blocks before any one else can be expressed as a function of the number of blocks that you've been trying to do this for.

	1	2	3	4	5	6
51%	26%	45.3%	59.5%	70%	77.9%	83.6%
40%	16%	29.5%	40.8%	50.3%	58.2%	64.9%

Your math only applies if the attacker is going about the attack in real time.  There is another type of attack where the attack chain is kept secret until it is long enough to overturn a deeply buried transaction.

[cunicula]

The short answer is that the percentage of wasted computational time increases exponentially as the average block finding time decreases.  This is particularly not good for miners.

The reason computational power is wasted is because a new block is not sent to the entire network instantaneously; it goes out to some nodes, who send it out to more nodes, etc., and eventually hopefully the entire network gets it.  Until the entire network does get it, there are still lots of miners wasting time wasting computations on blocks that will no longer be the longest chain and will thus be invalid.  Ten minutes seems to be a good trade-off between computational waste and speed of getting that first confirmation on a transaction.

Note that expressing the certainty of a transaction is based on computing time, however, not raw number of blocks.  When we currently wait for six blocks before saying a transaction is confirmed, what we really mean is that we're waiting for one hour (on average).  With two minute blocks we'd wait for 30 blocks before saying a transaction is confirmed, because 6 blocks times 2 minutes each is only 12 minutes, which simply isn't long enough to wait (it's not "enough" computing power and would be reversible a lot more easily than a whole hour's worth of computation would be).

As long as everyone faces the same risk of wasting computational time, I dont't see why tho
is matters to miners.