Author

Topic: How safe 1-confirmation transactions if there is no 51% attack? (Read 1458 times)

hero member
Activity: 826
Merit: 508
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. Sad
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.
donator
Activity: 2058
Merit: 1054
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.
legendary
Activity: 2142
Merit: 1010
Newbie
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...
hero member
Activity: 552
Merit: 501
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.  
donator
Activity: 2058
Merit: 1054
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.
legendary
Activity: 2142
Merit: 1010
Newbie
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.
donator
Activity: 2058
Merit: 1054
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.
legendary
Activity: 2142
Merit: 1010
Newbie
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.
legendary
Activity: 2142
Merit: 1010
Newbie
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.
hero member
Activity: 728
Merit: 500
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.
donator
Activity: 2058
Merit: 1054
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%").
legendary
Activity: 2142
Merit: 1010
Newbie
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. Sad
legendary
Activity: 1974
Merit: 1029
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.
legendary
Activity: 2142
Merit: 1010
Newbie

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...
legendary
Activity: 2142
Merit: 1010
Newbie
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
sr. member
Activity: 350
Merit: 250

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.
legendary
Activity: 1168
Merit: 1000
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?
legendary
Activity: 2142
Merit: 1010
Newbie
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...
sr. member
Activity: 350
Merit: 250
Some people even accepts unconfirmed transaction.
It depends how confident you are, and the amount.
legendary
Activity: 2142
Merit: 1010
Newbie
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.
Jump to: