How safe 1-confirmation transactions if there is no 51% attack?

[Come-from-Beyond]

Let's assume that noone is doing 51% attack. Is it safe to accept transactions with 1 confirmation? I worry that the block this transaction included in could become orphaned 2 blocks later. And one of these 2 blocks can contain a double-spent transaction, so the old one will never be included into later blocks.

[marcovaldo]

Some people even accepts unconfirmed transaction.
It depends how confident you are, and the amount.

[Come-from-Beyond]

Some people even accepts unconfirmed transaction.
It depends how confident you are, and the amount.

So 1 confirmation doesn't mean a transaction won't be cancelled? I expected that Satoshi's client uses some kind of magic to resolve orhpaned blocks issue before showing 1 confirmation...

[SheHadMANHands]

I'll admit I don't understand this and would like to hear feedback.  I've never had anything "reversed", etc., after seeing 1 confirmation, and I, like others, have made many transfers.  Has anyone ever had something happen after 1 confirmation?

[marcovaldo]

So 1 confirmation doesn't mean a transaction won't be cancelled? I expected that Satoshi's client uses some kind of magic to resolve orhpaned blocks issue before showing 1 confirmation...

Even a 100 confirmations transaction can be cancelled.
Eventually bitcoin will be abandonned tomorrow.
Or you will just die somehow.

[Come-from-Beyond]

I'll admit I don't understand this and would like to hear feedback.  I've never had anything "reversed", etc., after seeing 1 confirmation, and I, like others, have made many transfers.  Has anyone ever had something happen after 1 confirmation?

http://blockchain.info/orphaned-blocks

[Come-from-Beyond]

So 1 confirmation doesn't mean a transaction won't be cancelled? I expected that Satoshi's client uses some kind of magic to resolve orhpaned blocks issue before showing 1 confirmation...

Even a 100 confirmations transaction can be cancelled.
Eventually bitcoin will be abandonned tomorrow.
Or you will just die somehow.

Well, that was not a philosophical question...

[dserrano5]

Let's assume that noone is doing 51% attack. Is it safe to accept transactions with 1 confirmation? I worry that the block this transaction included in could become orphaned 2 blocks later. And one of these 2 blocks can contain a double-spent transaction, so the old one will never be included into later blocks.

If that happens is because you suddendly were in the other side of the fork and spent the same coins again. But if you were in the other side, then you'd see the original transaction unconfirmed again and would become aware that something is happening. ie if no one is 51% attacking the network, then only you could double spend your own coins.

[Come-from-Beyond]

If that happens is because you suddendly were in the other side of the fork and spent the same coins again. But if you were in the other side, then you'd see the original transaction unconfirmed again and would become aware that something is happening. ie if no one is 51% attacking the network, then only you could double spend your own coins.

If a transaction is rolled back to unconfirmed state in a few minutes, it's too late, coz the customer already received service they paid for.

[Meni Rosenfeld]

Analysis of Hashrate-Based Double Spending might be relevant to your interests.

Double-spending transactions can't really happen "accidentally". You're only at risk if the sender is purposefully trying to execute an attack.

If the double-spending transaction was broadcast to the network, you'll hear about it and refuse the transaction. So the risk is that the attacker will use its own hashrate to find 2 blocks, and he will need significant hashrate to do so reliably (but "significant hashrate" does not mean ">50%").

[Rannasha]

I'll admit I don't understand this and would like to hear feedback.  I've never had anything "reversed", etc., after seeing 1 confirmation, and I, like others, have made many transfers.  Has anyone ever had something happen after 1 confirmation?

http://blockchain.info/orphaned-blocks

According to this website, there were 1-2 incidents of orphaned blocks per month during the last few months. That's a chance between 1:4320 and 1:2160 to have a transaction included in a block that is later on orphaned if there's no attack going on.

Of course, assuming that there are no bad intentions from the customer or anyone else, there's a good chance that the transaction was also picked up by miners working on blocks that ended up on the winning chain.

[Come-from-Beyond]

Analysis of Hashrate-Based Double Spending might be relevant to your interests.

If the double-spending transaction was broadcast to the network, you'll hear about it and refuse the transaction. So the risk is that the attacker will use its own hashrate to find 2 blocks, and he will need significant hashrate to do so reliably.

Thx for the advice. But what is the chance to see a double-spending transaction? I believe honest nodes won't broadcast it if they know it's double-spending.

[Come-from-Beyond]

I'll admit I don't understand this and would like to hear feedback.  I've never had anything "reversed", etc., after seeing 1 confirmation, and I, like others, have made many transfers.  Has anyone ever had something happen after 1 confirmation?

http://blockchain.info/orphaned-blocks

According to this website, there were 1-2 incidents of orphaned blocks per month during the last few months. That's a chance between 1:4320 and 1:2160 to have a transaction included in a block that is later on orphaned if there's no attack going on.

Of course, assuming that there are no bad intentions from the customer or anyone else, there's a good chance that the transaction was also picked up by miners working on blocks that ended up on the winning chain.

I must assume that a customer tries to cheat my service.

[Meni Rosenfeld]

Analysis of Hashrate-Based Double Spending might be relevant to your interests.

If the double-spending transaction was broadcast to the network, you'll hear about it and refuse the transaction. So the risk is that the attacker will use its own hashrate to find 2 blocks, and he will need significant hashrate to do so reliably.

Thx for the advice. But what is the chance to see a double-spending transaction? I believe honest nodes won't broadcast it if they know it's double-spending.

True, nodes won't broadcast floating transactions which conflict with those they already know. Which again means that the attacker must rely on his own hashrate, according to the analysis in the linked paper.

[Come-from-Beyond]

Analysis of Hashrate-Based Double Spending might be relevant to your interests.

If the double-spending transaction was broadcast to the network, you'll hear about it and refuse the transaction. So the risk is that the attacker will use its own hashrate to find 2 blocks, and he will need significant hashrate to do so reliably.

Thx for the advice. But what is the chance to see a double-spending transaction? I believe honest nodes won't broadcast it if they know it's double-spending.

True, nodes won't broadcast floating transactions which conflict with those they already know. Which again means that the attacker must rely on his own hashrate.

The attacker could be connected to 1000 nodes and send a legit tx to 500 of them and non-legit one to the rest. I believe this gives 50% to succeed.

[Meni Rosenfeld]

Analysis of Hashrate-Based Double Spending might be relevant to your interests.

If the double-spending transaction was broadcast to the network, you'll hear about it and refuse the transaction. So the risk is that the attacker will use its own hashrate to find 2 blocks, and he will need significant hashrate to do so reliably.

Thx for the advice. But what is the chance to see a double-spending transaction? I believe honest nodes won't broadcast it if they know it's double-spending.

True, nodes won't broadcast floating transactions which conflict with those they already know. Which again means that the attacker must rely on his own hashrate.

The attacker could be connected to 1000 nodes and send a legit tx to 500 of them and non-legit one to the rest. I believe this gives 50% to succeed.

The receiving node should verify with all its peers that they do not know of a conflicting tx. If the attacker does what you say he will fail this test. (You do this with 0-confirm but you can also do it with 1-confirm).

Also, you say you're waiting for a confirmation. This means that the block you saw (with the legit tx) needs to have a tied block - that happens with probability of say 2%. You'll need the other block to have the bad tx, that's about 50%. And you need the next block to build on the other block, that's less than 50% (you're more likely to hear first about the block most of the network heard first). So all in all you have a sub-percent chance of success, if you don't do the listening test, and if the sender is an attacker in the first place - most people who pay you are not attackers. All in all, I think there is very little to worry about.

[davidgdg]

It's all in Meni's paper:

* The table on page 10 shows the chance of a double spend attack succeeding for various hash powers (expressed as a percentage of total hashing power) and various numbers of confirmations.

* The table on page 13 shows the approximate economics of a double spend attack.

Basically in all plausible and credible scenarios, unless you are dealing with some vast transaction involving tens of thousands of BTC,  one confirmation is perfectly sufficient.  The idea that it is necessary to wait for six confirmations to be safe before completing on some little sale is ridiculous overkill. It's like wearing a hazmat suit when you do a pooh.

Also, it is my understanding that version 9 of the client will, in effect, allow for zero confirmations.  

[Come-from-Beyond]

The receiving node should verify with all its peers that they do not know of a conflicting tx. If the attacker does what you say he will fail this test. (You do this with 0-confirm but you can also do it with 1-confirm).

It seems to be a solution. I'll connect my node to 1000 different nodes and monitor incoming transactions. I wish Satoshi's client marked transactions as double-spent by itself, this would make life easier...

[Meni Rosenfeld]

The receiving node should verify with all its peers that they do not know of a conflicting tx. If the attacker does what you say he will fail this test. (You do this with 0-confirm but you can also do it with 1-confirm).

It seems to be a solution. I'll connect my node to 1000 different nodes and monitor incoming transactions. I wish Satoshi's client marked transactions as double-spent by itself, this would make life easier...

You don't need 1000 nodes, 10 random nodes are a sufficient sample (e.g., if the attacker broadcast the good and bad tx 50/50, then there is a 0.1% chance that all nodes you connect to have heard only about the good tx and pass the test).

As alluded to by davidgdg, version 0.9 of Bitcoin-qt is expected to have a feature to poll peers for potential double-spending, making 0-confirm easier.

[MAbtc]

If that happens is because you suddendly were in the other side of the fork and spent the same coins again. But if you were in the other side, then you'd see the original transaction unconfirmed again and would become aware that something is happening. ie if no one is 51% attacking the network, then only you could double spend your own coins.

If a transaction is rolled back to unconfirmed state in a few minutes, it's too late, coz the customer already received service they paid for.

Yep! I imagine a merchant, recipient, etc. should weigh the value against various factors to determine risk/reward. I do find it surprising to see zero confirmations allowed in some places.