@MtGox Staff... when will mtgox change the number of confirmations?

[DeathAndTaxes]

Bitstamp = 3
FastCash4Bitcoins = 3
BTC-e = 3
CampBX = 4
Bitfloor = 6
Intersango = 6
MtGox = 6
Virwox = 6

bitcoin.de = ?
BTC24 = ?
Virtex = ?
BtcChina = ?
Bitcurex = ?

[1715107262]

1715107262

[Yuhfhrh]

bitstamp = 3
fastcash4bitcoins = 3
bitfloor = 6
campbbx = ?
I want to say BTC-e is <6 but it has been a while since I used that site.

Related, Campbx only requires 4 confirmations, and btc-e only requires 3.

[DeathAndTaxes]

Thanks.  Updated my post.

[Mike Hearn]

The correct way to think about this is not in terms of blocks but gigahashes of work done. Otherwise what happens is that as difficulty changes, the security level of N blocks goes up and down - not really what you want.

bitcoinj exposes confidence using a TransactionConfidence object, which provides depth in the chain as both "number of blocks/confirmations" and also total work done. Eventually I'd like to extend this mechanism to incorporate pluggable risk models, so you can say "for a transaction of value X and cost of mining hardware Y and risk adjustment level Z the work done required should be W", but for now you could come up with a model and run it by hand.

Mark is a smart guy, I'm sure at some point he'll implement something like this. It may simply not be a high priority. For everyone else, I encourage you to think of security in terms of gigahashes and not blocks.

[Meni Rosenfeld]

The correct way to think about this is not in terms of blocks but gigahashes of work done. Otherwise what happens is that as difficulty changes, the security level of N blocks goes up and down - not really what you want.

That is an overly simplistic description that doesn't take into account how double-spending actually works.

The two things that matter for the probability of succeeding in a double-spend attempt are the number of confirmations and the attacker's proportional hashrate. If the attacker's hashrate is assumed constant, increasing the difficulty means lower attacker proportion and hence more security. But the relationship is not linear, and cannot be compressed into a single "total gigahashes" figure.

I recommend having a look at my linked paper which provides some discussion of this. And that for securing a system the proper dynamics will be considered, rather than trying to dumb it down to a single number.

[Mike Hearn]

Which paper are you referring to?

Double spending can be seen like this. How much money is your attacker willing to spend on hashing? How much hashing can they buy for that money?

At some point hardware will bottom out in terms of how efficient it is. Then the cost of a gigahash will become more or less predictable. If what you're selling is worth 100 BTC, then after the point where an attacker would have to have spent 100 BTC on hashing you don't have to worry about double spending anymore, it can't ever make sense for an attacker to try. In a network with very high speeds, 100 BTCs worth of hashing will happen quite fast. If speeds drop, it'll take much longer, but assuming the amortized hardware/electricity cost remains constant, you can ensure it always requires 100 BTC of hashing by varying the time you wait.

[Meni Rosenfeld]

Which paper are you referring to?

The paper I linked to earlier in this thread, paper and discussion thread.

Double spending can be seen like this. How much money is your attacker willing to spend on hashing? How much hashing can they buy for that money?

If we come to the point that we're thinking in terms of the cost per gigahash then we already lost because the amount that can be at stake would be only linear in the number of confirmations, and double spending will be trivial.

Our only hope is if the attacker cannot obtain more than a certain total hashrate, and if that is low enough (as a portion of the network total), his probability of success will be low (exponentially decreasing in the number of confirmations). That will place a real cost on double spending.

Also, if the attacker successfully double-spends, he also gets the normal block reward (coinbase + tx fees) for the blocks he found in the process. Assuming the cost per gigahash is predictable, it should also be about equal to what you would get on average in rewards. In this case there is no cost to double spending (if success is guaranteed). So again there is real hope only if the probability of success is low, and some small hope if the attacker can only secure the needed hardware at above the "normal" cost.

[MPOE-PR]

If anything, I would propose the idea that highly verified customers should be allowed to use their MtGox balances to guarantee against double spending.

MtGox's exposure to a double spend is only what one could withdraw from their account, and the losses one could incur in trading.  If withdrawal is blocked pending confirmation, the exposure to trading could hardly be anywhere near the full balance.  What if every confirmed 1BTC in your Gox account gave you access to 2BTC in zero-confirmation-tradeable deposit?

If I have $1000 in my MtGox account and want to send $1000 more, let's say Gox lets me trade $2000 immediately, I just can't withdraw it.  If I were to double spend, Gox would rightfully lock my account.

This is roughly how MPEx works.

[Mike Hearn]

In this case there is no cost to double spending (if success is guaranteed). So again there is real hope only if the probability of success is low, and some small hope if the attacker can only secure the needed hardware at above the "normal" cost.

Legitimate miners are amortizing the cost of hardware over the long run on the assumption Bitcoin will be long term successful. If a double-spender spent as much on hardware as everyone else has combined, they could double spend a bunch of times, but once it became known that the system was open to arbitrary fraud no matter how long you waited people would simply abandon Bitcoin and go back to other systems. That would lead to a sharp drop in usage and fees as everyone heads for the exit, putting the attacker permanently in the red.

[Meni Rosenfeld]

In this case there is no cost to double spending (if success is guaranteed). So again there is real hope only if the probability of success is low, and some small hope if the attacker can only secure the needed hardware at above the "normal" cost.

Legitimate miners are amortizing the cost of hardware over the long run on the assumption Bitcoin will be long term successful. If a double-spender spent as much on hardware as everyone else has combined, they could double spend a bunch of times, but once it became known that the system was open to arbitrary fraud no matter how long you waited people would simply abandon Bitcoin and go back to other systems. That would lead to a sharp drop in usage and fees as everyone heads for the exit, putting the attacker permanently in the red.

And then we have bigger things to worry about. Anyway, this is a tangent, as I said even if it costs more for the attacker to mine than he gets normally, there still isn't much security to speak of if he's in majority (and if not, the probabilities are what matters).


And I should point out that even if we assume that:

1. The attacker gets no reward from the blocks he mines
2. The attacker has majority hashrate and is guaranteed success

It is still not the case that the cost to double-spend is simply proportional to the number of hashes embodied in the confirmations; the attacker needs to redo these and all the blocks that will be found during the race. The less hashrate the attacker has the longer the race will draw out, so you need to know the hashrate to estimate the cost.

[jago25_98]

How does smpake.com do it? Green address?

I could understand if it was from bitcoin address to mt.gox code but it's bitcoin to bitcoin

Great reference DeathandTaxes

[SebastianJu]

How does smpake.com do it? Green address?

I could understand if it was from bitcoin address to mt.gox code but it's bitcoin to bitcoin

Great reference DeathandTaxes

They have btc at mtgox and when you sent them btc and they have a confirmation they move the amount of btc from their mtgox account to yours. I think its this way.