Bitcoin Forum

As the title suggests, it seems to me like fewer coins per block but more blocks would be a plus.
Transactions would be confirmed faster, blocks would be confirmed faster, everything would go faster.
Seems like that would help bitcoin move into common usage.

I believe blocks are spread in time to ensure that any messages will propagate across the entire network in the duration of a block, 10 minutes being a rather pessimistic view of how long it could take for a message to propagate.

The thing is, faster blocks would take less effort to generate, so to get the same level of security as you currently get by waiting 30 mins for three blocks, you'd have to wait 30 mins for 15 blocks. So, nothing would go faster, you'd just be consuming more traffic spamming the network with more blocks.

This question was answered in the FAQ (https://en.bitcoin.it/wiki/FAQ#Why_do_I_have_to_wait_10_minutes_before_I_can_spend_money_I_received.3F). However the answer could probably use a bit of expansion. Feel free to work on it.

I think the positives outweigh the problems, but 2 minutes is too fast, id go for like 5 minutes. and me as a very very small merchant, i would still accept 2 confirmations. but if you want to sell anything big you will wait for the full 120 confirmations anyway, or if this happened 240.

most of the size comes from the transaction data. there would be less transactions in each block if blocks happened more often. but there is still overhead from there just being a block that was created. so i would guess it would only be like 1.5-1.8x more, not a full 2x

It comes down to ... is it instantaneous (i.e., a few seconds) or is it longer.   When longer, it doesn't matter if it is 45 seconds, two minutes or ten minutes -- they all don't pass as being "instantaneous".

There has been the argument that for most real world point of sale transactions, the risk to accepting at 0/unconfirmed even would not be high enough to deter a retail merchant from using bitcoin.  The risk can be cut even further with additional software that monitors for double spends attempts so that race attacks taking advantage of network speed would not be successful:
 - http://forum.bitcoin.org/index.php?topic=27417.msg350531#msg350531

If even having a low-risk of loss isn't acceptable, then there can be extensions that will help bridge how bitcoin works with how existing commerce works.  For instance, the Mt. Gox redeemable code can be used to transfer with immediate settlement bitcoins from one Mt. Gox account to another.  A mobile app for accommodating both sides of that is described here: http://forum.bitcoin.org/index.php?topic=25307.0

Of course, those transactions don't benefit from the advantages bitcoin offers, including pseudonymity (as Mt. Gox knows both parties), but since those transactions use bitcoins at least there needn't be a conversion to USD or other currency for them to be used in a retail transaction. 

(incidentally, the Mt. Gox redeemable code / voucher can be for either BTC or USD currencies.)

I know that this will in all likelihood will never happen. but i like the idea better where you just keep a tab or account at each restaurant you go to. an opensource app could be developed that could be run on a simple webserver that would handle the basic needs of a fast food place like McDonalds. amounts like 20$ or 1BC as of now would be safe to use after only 1 or 2 confirmations. so you could order your food on a smartphone or just add money to your account before you go, then once you arrive you tell them some information about your account or use a card or something and they make your food or you order it.

Another situation, a mall
you go to the mall and at the entrance is a bitcoin terminal. you put coins in the terminal and it shoots out a cheap card that can be recycled. by the time you walk to the first store yo buy somthing 10 minutes would have passed and you could have your merchandise. when you leave you put your card in and it releases any unspent coins.

With these ideas, bitcoin would still be decentralized, or more so than if we just all dumped our money into 1 company, which i do not think the good solution is.

Some day, I expect to see VISA and MasterCard as the big players in these systems.  It will be easier for users to only have to track a few services like that, rather than one for each store/chain/mall.  But at least with Bitcoin, everyone has the choice, and since the software for it should be dead simple, choices will be abundant.

You cant have blocks generating that fast, it would split the block chain. 10 minutes is the worst case propagation time for data in a distributed network. Every miner needs the last block to mine the next one, so if the time was lets say 30 seconds a block then two miners would find different solutions to the same block and then everyone near those miners would accept the new block and make new blocks based on it, this would mean that the block chain would split very often, leaving the transactions in those blocks lost and reversed. Currently two miners can find a block at the same time, but 10 minutes is enough for the network to chose one instead of making two separate chains.


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. 

Don't forget that 10 minutes is the targeted average between blocks. Because the process is essentially random, you sometimes find less than 1 min between them, and sometimes closer to an hour. With a 10-minute average, the chances of getting two blocks too close together is low, but not impossible.

In addition, hashing power keeps increasing (albeit slowly these days), so even the average is less than 10 minutes.

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

Solution:
cooperate with other miners and connect directly to each other. then you know as soon as a block comes out. and you would be surprised how fast information propagates in the network. i normaly never wait longer than 5 seconds to see a transaction, but i also have over 60 connections at any given time.

That is an excellent idea.  Perhaps we could even come up with some sort of relay system for the miners to use to automatically convey this information around so that we don't have to directly manage the connections ourselves.

That's the sort of answer I was looking for, thanks.

I propose a theory

This theory will explain and confirm a few things

This theory has to do with the nature levels of security and the additional security granted at each level. for example, there is little or no security for a transaction just floating around in the network. however once the transaction makes it into a block, the amount of security granted is the greatest than any other jump. once block 2 as been generated, you don't have much additional security, so is it worth waiting for if you only have a small purchase.

I asked this same question (http://forum.bitcoin.org/index.php?topic=31587.msg398026#msg398026) today.

I haven't had my scribble calculations confirmed, but it seems to me that the weighted average latency between miners is 2.11 seconds. Miners waste 2 seconds hashing away the previous block every time a new block is awarded as well as waste at least an entire block if they happen to be on the loosing end of forked block chain (~0.5% chance every ten min block). The chance of forks is directly related to latency/generation-rate.

The latency is the same no matter the block generation rate. If you double the rate, waste should be halved (and then a little). I estimate that the system is entirely broken with a generation rate less than 5 seconds. If the rate were every minute the waste might be around 15%. Ten minutes puts us in the ballpark of 99% efficiency.

I did more research, and what i proposed before was actually being worked on by bitcoin labs. with that, the network as we see it now could completely propagate in around 3 hops. thats less than 20 seconds on average.

not quite true, because some merchants only wait for one confirmation to credit you with the money

While it is true that faster blocks would require a lower difficulty, the constant latency means that the wasted effort grows with block speed. If you can cut latency 50% across all nodes then you can cut block speed 50% with insignificant loss of efficiency (this excludes memory and bandwidth requirements which will obviously increase).


But a faster confirmation will be more than proportionally less robust. With a doubled block speed competing forked block chain rates will more than double. As an extreme example, if the block speed were a few seconds (about the same as latency), then the network would thrash with the majority of 'confirmation' blocks being invalid. Less than a minute and the miners will spend twice as much energy producing the same number of hashes (with maybe 15% of all 'confirmations' invalid).

Miners could (and probably should) make direct connections to each other. However such a protocol requirement would make the network less robust. Indeed malicious miners would simply isolate the honest nodes.

Instead of screwing around with bitcoin's framework...  it's easier to just do transfers from ewallet to ewallet and it's instant that way...   

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.

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.

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

http://img695.imageshack.us/img695/6461/networka.png

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.

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.


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.

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.

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.


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.

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.

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


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.


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.

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.

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!


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?

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.

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.

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.

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.

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

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


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

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.

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

Because the greater the waste ratio the greater the advantage to the previous awarded miner, which is an advantage to a malicious miner. The waste due to latency is expected to increase as the network grows and we really do not have a huge margin. Increases in waste proportionally increases the likelihood that any block/transaction is invalid. And waste is ... wasteful.

I know that with 51% hash power the attacker will always succeed eventually.  Anything over 50% gives statistical certitude that the attacker will eventually succeed.  It's really a question of how long it is likely to take and how much effort an attacker would be willing to expend with such a small advantage to eventually succeed.

For a brief time I was thinking about how to compute the chance of computing 2, or 3, or N blocks before the rest of the network can compute 1.  I am not entirely sure how to do the math, but I think it would be very interesting if someone does.

its possible to abuse the network with less than 50%. you can abuse the network with .0001% of the hashing power, the question is only how successful you will be at trying to abuse the network. with even as low as 30% you could still occasionally get blocks in succession and cause damage. but if you want to be able to cause damage more often you will need more power, closer to 70% is my gut feeling.

But just getting blocks in doesn't cause any damage, you have to be able to overwrite prior blocks, which isn't possible with less than 50% of the total network hashing power, and still isn't terriblely likey at 51%.  Thus, you are correct guessing that 70% is a more realistic number.  In order to assault the blockchain in real time, the attacker would have to be able to seriously dominate the entire honest network.  However, if the attacker were building a chain in secret, he could possibily build one in secret that overwrites a prior block to reverse a transaction wherein the attacker previously spent funds.  But this kind of attack is damage limited to the person who was dealing with the attacker, and he would still need enough of a majority to build and release his chain before any new checkpoints have been added.

Of course it's possible to do it with less than 50%, it's just less likely.

I still haven't seen a mathematically founded answer to a question I've been asking for ages:

What percent of 0/unconfirmed transactions become orphaned, are fraudulent or otherwise never make it to 6/confirmed?

If that percentage is lower than current merchant service company fees, we're still a point-of-sale winner when accepted at 0/unconfirmed and that much IS instant.

No, it's not.  Not if we are talking about the same thing.  It is not possible to reverse a confirmation of a transaction, and thus double spend, without 50% or more of the total network hashing ability.  That is shown in Satoshi's white paper.

0/unconfirmed are transactions the network potentially does not know about. I've created numerous that have never gone to 1/unconfirmed, and the network has NO RECORD of them. Would you settle for stats from 1/unconfirmed to 6/confirmed? In an earlier thread, Kjj said:

So with 25% hashing power and some luck I can't rewrite a new block chain starting at a block, say, 2 blocks old, and extending out 1 additional block, before someone else adds 1 block to the current head?  Although it is statistically unlikely I don't see how it's impossible.  If I tried hard enough and long enough it is inevitable that I would be able to do this at some point.  It is also inevitable that the 75% of the network, if it were coordinated to try to extend the "real" block chain instead of mine, would eventually win back the block chain.

It is inevitable that > 50% has ultimate control over the block chain, but < 50% could have control for short stretches, and that would be very disruptive.

that's how i see it, and if the over 51% hasher had some bad luck, they would not be in control during that period.

The 25 % attacker is so much less likely to overtake the honest block chain, that it's statistically to his advantage to double his resources rather than quadruple his attempts.

in the real world we do not have limitless resources, you would be capped by electricity and the amount of GPUs you would be able to acquire.

Neither disruptive nor damaging.  The system does this regularly, and is designed to cleanly handle it.  They are call "reorganizations".  From the perspective of the network, part of the network disagrees about the last block or two; but as you said yourself, the honest majority will overtake the network, and all attempts to force a blockchain split with less than a hashing majority result in futility.  The network doesn't even care.  And even though it's not impossible to overwrite one or two blocks in a row with 25% of the hashing power, the odds are still vanishingly small considering your trying to swim upstream at 2.5 feet per second against a flow of 7.5 feet per second.  There is more to it all than you seem to grok.

We grok it just fine, and you haven't said anything that wasn't said already.

Then what is the disconnect?  Have you read the white paper?  If so, are you sure that you understood it?  Bitcoin has a lot of moving parts, really.  The possibility of a blockchain attack doing any lasting harm is directly addressed in Satoshi's white paper, and what I think that you guys are describing isn't possible with less than a majority hashing power.  Not just unlikely, but astronomicly unlikely.  In the same threat range of the sudden reversal of the law of gravity, or the rapid dimming of the Sun.  You do realize that neither is impossible, but they are so far removed from possible that any rational person simply rounds off to zero.  Same with the odds that a minority attacker can just stumble into an attack that lasts two or more consecutive blocks.  In order for an attacker to double spend in this manner, he first has to allow the first transaction into the blockchain in order to get the vendor to accept the deal complete (assuming that he doesn't expect more confirms, the default is 6) and once in a block; said minority attacker must create two blocks of the proper difficulty before the rest of the network can produce one.  That's why I said it's posssible at 50% but it's still unlikely.  Given 6+ confirms, even an attacker with 51% of the network hashing power would have an astronomical and vanishing likelyhood of reversing that far back; all of which has to occur before the honest network can produce another block.  Even if the attacker was producing his dishonest blocks in the dark to be released all at once, he still only has a 51% of creating the 7th block to seal them in before the rest of the network does.

The disconnect here is that you're talking about "lasting harm" in the context of the network.  If I get one confirm, give you the keys to my car, you drive off and the blockchain reorganizes so your payment goes someplace else (due to double spending on another branch)— lasting harm was done by any sane measure.

If you wait long enough then you can make the risk arbitrarily small, though the buyers risk starts increasing with too much delay and large delay aren't always tolerable.   

If the network is more concentrated (lower latency, longer block intervals) then it is less likely for someone to pull off an uncertain low depth attack because there will be fewer instances of multiple forks with a non-trivial survival chance.

 

Escrow.

51% is a magic number, or rather majority is "magical".  If one excludes the other safeguards, and just considers the raw security of the blockchain & total hashing power, a simple majority hasher could eventually double spend a prior transaction by slowly overtaking the blockchain in the dark and dumping his false chain upon the network.  The hasher with 49.9% can never do this.  Ever.  Or if you prefer, the odds against a minority hasher with 49.9% of the hashing power sustainablely taking over the blockchain starts at roughly 1:1 at the first block, but then trends towards infinity.


As I have already pointed out, the 'skirmishes' are harmless.  In fact, they are an expected part of the network's daily functions.  Reorgs occur often enough that it's probable that it happens daily, but there is no way to know for certain because, by definition, such reorgs occur because the reorging nodes found themselves on the minority side of a blockchain split.  There is some evidence that as much as 0.3% of all blocks found by the network are found by a node after another node had already found and published the same block.  Based upon this, it might be closer to every three days, on average.


How, then, would they be disruptive?


Transactions are dropped upon seeing a valid block containing them.  Transactions are resent by the original client after a certain number of blocks, if the transaction isn't seen in the blockchain.

51% is a magic number.  For an offline attack, 51% is the point where if you start right now, you can be sure that you will be some number of blocks ahead in the future, if you wait long enough.  Really 50% + 1 is the magic number, but we round to 51%.


Yes, miners delete pending transactions if they are seen in a new block coming in from the network.  But when there is a reorganization, all transactions that were in the invalid blocks and not also in the newly valid blocks are automatically put back into the queue, after validating them using the transactions from the new blocks.

  "Everyone is entitled to his own opinion. But, Senator, you are not entitled to your own facts"
     -- Daniel Patrick Moynihan, 2003 or James R. Schlesinger, 1973

Yes. There are those discussing probabilities to override a single block and there are those discussing double spending attacks in general. No one argues that a node with 1% hashing power has a 1% chance of taking a block if he begins at the same time as all other honest nodes. No one argues that a node with 40% hashing power has some slight chance of taking two blocks. But if we discuss a real attack, involving multiple blocks, the difference between 40% and 51% is enormous. While a 40% attacker might be immediately lucky, if he's not he should give up. On the other hand a 51% attacker is GUARANTEED to override the block chain eventually.

While you can complain about a PROOF involving unlimited time and resources, you can not dispute the fact that the 40% attacker has an unlikely chance which becomes exceedingly more unlikely with time, while a 50+% attacker has a likely chance which becomes more likely with time.



NO. This is only true on the first block attempt. These chances rapidly diverge with each subsequent honest block generation.



YES, but NO. Not unless you are discussing competing malice or network isolation. Honest nodes will acknowledge defeat, malicious nodes will not, much like this thread.



I didn't follow your train of thought completely, but... just because we feel certain that 6 confirmations is written in stone, that stone can always theoretically be broken, with transactions reversed Dwolla style.



Let me interrupt again. The attacker only needs to generate 7+ before the honest nodes generate 6, perhaps a few more for good measure.

Not to me or the rest of the network.  Such harm is limited to you, the seller who didn't take prudent steps.  Have you ever bought a car from a dealership wherein you were not in the dealership for at least 30 minutes?  This does not qualify as lasting harm in the context of bitcoin itself or the network.

tl;dr stop mining from deepbit

By making the block time faster the risk from shorter confirmation or the number of confirmation needed to reduce risk is increased. This is a cost to all bitcoin users, especially since its users can suffer from the loss of confidence in addition to the loss itself.

Something must be wrong with the forum.  That post is attributed to me but I didn't write it, although I think the points are all valid and good.

I will admit defeat if you will admit that these veiled insults you post are uncalled for,

This is the real bji, right?

I certainly did intend to directly and personally tease you with Moynihan's quote because I hope we've all been arguing not between differences of opinion but assertions of fact.


I then continued to quote your post, commenting throughout. I agreed with you that this thread has had multiple sub-threads and I tried to address those diversions as I saw them. My veiled insult ("Honest nodes will acknowledge defeat, malicious nodes will not, much like this thread") was a side note directed at the general inconclusive sub-threads and the posters who propagated them, not to you specifically. I hope you will accept my apology. I sincerely did not mean to single you out, but I can see that by quoting you exclusively, that is what I've done. I am sorry.

More than any other post, I appreciated your attempt to put your argument in numbers. Despite Kjj pointing out the limited domain, I hoped to see revised attempts to quantifying the difficulty of a double-spend attack, both within a few blocks and over a sustained attack.

Yes, it's me, I have no idea what the forum software did because someone else's entire post is attributed to me!  You can tell that I didn't write it because it's pointing out flaws in some of my own logic and not written from my perspective on the matter.  Weird.


Well, I admit to being a little more affronted by your post than was really called for; so I apologize for my own haste to judgement about your intentions.  And anyway I appreciate your conciliatory words here.

I think that some good points were made in this discussion about the resilience of the bitcoin protocol to attacks by anyone with less than 50% hashing power.  I think I was wrong in claiming that the effects of a "lucky" lower-power hasher with bad intentions could be disruptive; the honest majority will always win and should win quickly enough that anyone waiting for a reasonable number of confirmations can have high confidence in confirmed transactions.

I do believe that we've fairly well shown why reducing the block generation time to every 2 minutes would be a bad idea (because it would make all of the points about why bitcoin is resilient against these kinds of attacks less strong and make such attacks much more likely to succeed, in addition to generally creating lots more block chain forking and general uncertainty).

Sorry, I think someone hit edit instead of quote. We're working to figure out who.