Bitcoin Forum

Hello,

mtgox needs 6 confirmations until your btc are there. That means waiting a hour in average. Why doesnt mtgox change this to a lower value since more than 2 confirmations seems to bring nearly no more security.

I think its a hindrance for trading. Bitcoin is, even though its a internet currency, slow with one or 2 confirmations. But waiting 6 is even worse.

I hope that it will be considered.

Thanks!
Sebastian

Iirc you can use smpake.com for 0confirm service.

Looks really interesting. Thanks for the tip... if it works it would be a nice thing.

This is why https://en.bitcoin.it/wiki/Confirmation, indeed it is "slow" but it is also 100% secure.

The classic bitcoin client will show a transaction as "n/unconfirmed" until 6 blocks confirm the transaction. Merchants and exchanges who accept bitcoins as payment can set their own threshold as to how many confirmations are required until funds can be considered valid. When potential loss due to double spending as nominal, as with very inexpensive or non-fungible items, payments can be considered confirmed as soon as it is seen on the network. Most exchanges and other merchants who bear the risk from double spending require 6 or more blocks.

If you are sending coins to another Mt.Gox Bitcoin account you can remove the needed 6 confirmations, but once again, from an Mt.Gox account to another one.

But as far as i read these 6 confirmations are giving nearly no more security. I mean waiting one hour for a digital payment is a big timeframe. Ok, its part of the network but if the waiting time is unneded long it isnt an argument for using bitcoins.

Anyway... i found a workaround but i still dont understand that the outcome of security <> time needed comes out to this result. But its your decision. Maybe im only wrong and the security gain is really worth to note.

From what I understand double spending after even a single confirmation would be nearly impossible, but MtGox is willing to do big transactions. Transactions involving five digit numbers of bitcoins and six or more digit numbers of dollars. When transactions get that big, sometimes you have to take the safest route. Waiting for six confirmations may make things absurdly safe on their end, but they have to do it because any security failings can hit their reputation hard.

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.  Let's say they could liquidate my whole account for $1500 (assume bitcoins just took a dive).  They're still made whole, because the double spend was only $1000 to begin with.  I can't withdraw, so the coins aren't going anywhere.

This would double the value of leaving funds in Gox.  I could have the "benefit" of leaving $2x in my account, while only leaving $x there.

I understand the need of 6 confirmations for bigger (XX XXX) transactions but it wouldn't hurt to change the number of confirmations to 1 or 2 for smaller transactions (<$1k).

If its about the high amounts of transactions then why not make something like this:
up to 100btc per day 1 confirmation
up to 500btc per day 2 confs
...

When i think about... this hasnt to be per day... per hour is enough. Because after a hour you know if the previous transaction was fishy or not and you could allow more fast transactions.

Im not sure if highly verified users could help. I mean i can imagine that some people use voip-numbers, faked id and so on and then could misuse this.

But i think when its only about the height of transactions then small transactions doesnt need ultra high security.

I vote for 3 confirms on smaller btc deposits  ;D

However 6 confirms isn't magically safe.  It isn't like 5 confirms = massive risk and then 6 confirms = impossible.

Lets assume the attacker has hashpower that equals 20% of the network. 

To reverse an unconfirmed transaction will be 100% successful if using a finney attack or 20% of the time by brute force.  Obviously too much of a risk for high value transactions.
To reverse 1 confirmation will be successful (0.2^2 ) 4% of the time.  An attacker could reverse roughly 1 in 25 deposits.  That likely is insufficient.
To reverse 2 confirmations will happen (0.2^3 ) 0.8% of the time.  An attacker could reverse roughly 1 in 125 deposits.  Pretty small attack vector but still plausible.
To reverse 3 confirmations will happen (0.2^4 ) 0.16% of the time.  An attacker could reverse roughly 1 in 625 deposits.  The attack is non-viable and very obvious*
To reverse 4 confirmations will happen (0.2^5 ) 0.032% of the time.  An attacker could reverse roughly 1 in 3125 deposits.  The attack is completely non-viable.

* With a 0.16% success rate the attacker would only reverse on average one in 625 deposits.  Given there are only 144 blocks per day the attacker would need to deposit a MASSIVE amount of funds every hour (24+ times per day) for an average of 4-5 days before being successful.   The signature would be very obvious.   The attacker will on average lose 625 blocks to orphans for every successful attack.  The lost blocks would be worth roughly $203,000.  So to yield a 30% bonus on that would require a $300,000 double spend.  Think it might be obvious someone with a level 3 verified account depositing and withdrawing $300K in BTC every hour for days and days?

MtGox 6 confirm policy is simply an anachronism.  Why 6?  Why not 60 to be super duper sure.  Satoshi never intended the #6 to have divine like powers.

That just sets up a scale for people to figure out how much they can get away with and calculate how long and how much capital it will take.

The scale is already set up. There is some cost to unspending after 6 confirmations and you get an unlimited (Gox hot-wallet really) amount for the effort. It seems like allowing some little amount at 3 confirmations would let the vast majority through in half the time while not really exposing as much as the current 6 limit for huge amounts. In combination with all the KYC in place and per account limits based on current balance as was mentioned it could increase convenience without loss of security.

I don't think Gox will ever, but others will. I don't use exchanges, who knows what other sites have in place?

I agree that 6 confirmations are really unnecessary and even more for verified accounts. But the success of doubled spending on mtgox is not just a problem if you withdraw, as you could execute large sell orders, manipulating the market to your advantage.

Furthermore, all those bitcoins sold may be withdrawn by their buyers

This seems like an interesting idea for allowing margins trading.

With above^^ in mind,  I would like to re-affirm my vote for 3 confirms on small btc deposits  ;D

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

This is a myth, and a dangerous one at that.

It is fine if Mtgox wants to be safer than strictly necessary. But if they believe that 6 confirmations are somehow special and magically safe, and fail to incorporate it in a complete risk management solution, it can have disastrous consequences.

Optimally, the system will credit increasing amounts based on the number of confirmations. For example, someone deposits some amount X of bitcoins. After 1 confirmation 10 BTC will be credited. After 2 confirmations, 30. 3: 100. 4: 300. 5: 1000. 6: 3000. 7: 10000. And so on, until the entire deposit is credited. This system also needs to properly handle multiple simultaneous deposits.

While simple and efficient, it can be understood if Mtgox wishes to avoid confusing themselves and the customers, and properly handling the number of confirmations can be "outsourced" to smpake-style services.

Right, and the scale can be set up so that the expense is always greater than what they can get away with.

I agree with the spirit of this, but the numbers are way off. The success rate is not simply q^(n+1).
The correct numbers for 20% are: 1:40%, 2:20.8%, 3:11.6%, 4:6.67%.

As we speak I am finishing a paper analyzing double-spending success probabilities in more detail, including more accurate formulas and tables. I will link to it here when done.

Edit: Said paper is available here (https://bitcoil.co.il/Doublespend.pdf), and this (https://bitcointalk.org/index.php?topic=130222.0) is the thread for discussing it.

Im not so into the network techniques but isnt the idea of double spendings more of an academic kind and not of a real "earn money" thing? I mean of course you could do it but wouldnt one have more success with using such hashpower for normal mining and earning safe money with that instead taking the risk of double spendings with all consequences?

I only mean there didnt happen anything till now. And using one confirmation for small transactions would mean a relatively low risk for mtgox and a high risk that isnt worth the hashpower for an attacker. Right? So at the end the only persons suffering from the waiting time are the customers. Because of something probably never will happen because of the ressources needed.

Bitcoin-Central : 2 confirmations.
Instawallet : 2 confirmations.

Never a single Bitcoin lost.

Have fun waiting for your Bitcoins on MtGox, on Bitcoin-Central they'd already be on their way to your bank account.

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

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

Thanks.  Updated my post.

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.

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.

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.

The paper I linked to earlier in this thread, paper (https://bitcoil.co.il/Doublespend.pdf) and discussion thread (https://bitcointalk.org/index.php?topic=130222.0).

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.

This is roughly how MPEx works.

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.

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.