What safeguards can I use when attempting 0 confirmation transactions?

[Voodah]

I'm needing to integrate BTC payments into a working system where speed is essential, and 0 confirmations seems to be the only way to achieve needed speed.

Are there any best practices for doing this?

Can I somehow analyze a TX and do my (internal) manual confirmation?

I know I should start by checking if a correct fee was paid. Will that suffice? What else is there?

Thanks !

[justusranvier]

Make sure you have a well-connected node.

After you first see a transaction, wait X seconds and look for double spend attacks.

If no double spend attacks have occurred yet, then you can assume the odds the transaction you want will be included in a block instead of a conflicting transaction is at least Y%.

Don't ask me how to calculate X and Y, but if you can accurately estimate Y then you can just increase your price by n*(1-Y) to cover expected losses from double spends. Where n is the fraction of customers who try to scam you.

[Kao]

Make sure you have a well-connected node.

After you first see a transaction, wait X seconds and look for double spend attacks.

If no double spend attacks have occurred yet, then you can assume the odds the transaction you want will be included in a block instead of a conflicting transaction is at least Y%.

Don't ask me how to calculate X and Y, but if you can accurately estimate Y then you can just increase your price by n*(1-Y) to cover expected losses from double spends. Where n is the fraction of customers who try to scam you.

There's a Z variable as well which is the time between the end of your wait time and when a confirmation has come through, thus closing the window of opportunity for a double spend. You don't know what Z is but by attempting to estimate it, which can be done by figuring out how often a block is generated and the time since the last block was generated, you can assess the relative risk of a double spend happening between your wait time ending and the the transaction being definitively confirmed.

[Rannasha]

Make sure you have a well-connected node.

After you first see a transaction, wait X seconds and look for double spend attacks.

If no double spend attacks have occurred yet, then you can assume the odds the transaction you want will be included in a block instead of a conflicting transaction is at least Y%.

Don't ask me how to calculate X and Y, but if you can accurately estimate Y then you can just increase your price by n*(1-Y) to cover expected losses from double spends. Where n is the fraction of customers who try to scam you.

There's a Z variable as well which is the time between the end of your wait time and when a confirmation has come through, thus closing the window of opportunity for a double spend. You don't know what Z is but by attempting to estimate it, which can be done by figuring out how often a block is generated and the time since the last block was generated, you can assess the relative risk of a double spend happening between your wait time ending and the the transaction being definitively confirmed.

In the case of the network hashrate perfectly matching the difficulty, Z is always 10 minutes.

Right now, with difficulty increasing, Z is between 7 and 8 minutes typically.

Note that Z does not depend on when the last block was generated.

[solex]

Make sure you have a well-connected node.

After you first see a transaction, wait X seconds and look for double spend attacks.

If no double spend attacks have occurred yet, then you can assume the odds the transaction you want will be included in a block instead of a conflicting transaction is at least Y%.

Don't ask me how to calculate X and Y, but if you can accurately estimate Y then you can just increase your price by n*(1-Y) to cover expected losses from double spends. Where n is the fraction of customers who try to scam you.

There's a Z variable as well which is the time between the end of your wait time and when a confirmation has come through, thus closing the window of opportunity for a double spend. You don't know what Z is but by attempting to estimate it, which can be done by figuring out how often a block is generated and the time since the last block was generated, you can assess the relative risk of a double spend happening between your wait time ending and the the transaction being definitively confirmed.

In the case of the network hashrate perfectly matching the difficulty, Z is always 10 minutes.

Right now, with difficulty increasing, Z is between 7 and 8 minutes typically.

Note that Z does not depend on when the last block was generated.

Isn't Z the average block interval / 2 because a random transaction has 50% probability of occurring each side of the mean block interval?
Z increases however depending upon how less often getblocktemplate or getwork is invoked during mining by the "average" miner. If that is in the order of minutes then Z approaches 10 instead of the ideal 5 minutes.

[t3a]

There is no absolute safety for 0 confirmation transactions. Greedy miners can easily accept higher fee transactions and ignore lower fee transactions.

If I wanted to defraud you in a 0 confirmation transaction, I would give you $10 with a $0.01 fee, then immediately after send a transaction of $9.50 with a fee of $0.51 to another address I own. Any miner can ignore the old transaction in favor of the more profitable transaction.

[maaku]

Isn't Z the average block interval / 2 because a random transaction has 50% probability of occurring each side of the mean block interval?
Z increases however depending upon how less often getblocktemplate or getwork is invoked during mining by the "average" miner. If that is in the order of minutes then Z approaches 10 instead of the ideal 5 minutes.

No. Block finding is a Poisson process. You are always 10 minutes (or whatever the current nethash & difficulty commands) away from the expected arrival of the next block.

[Voodah]

Thanks a lot for everyone's input.

Unfortunately for me, increasing the price to offset provable loss is not an option (if anything, given my specific scenario I would be inclined to offer a discount to those paying in BTC).

Still, I've been processing, reading up and thinking on the suggestions made by you all and have come to the conclusions:

+ Incentive to scam will be low given the transactions are of < 5usd.
+ Opportunity for scammer low, since it's a physical device and the attacker is on a queue, and probably on camera.
+ Finney attack risk close to 0, since I will always have better connectivity than the attacker (is this conclusion correct?)
+ That leaves me with the risk of a race attack. More specifically, an android wallet modified to this purpose.

Based on the research I did after justusranvier's comment, a decent X time would be 30-60 seconds. I don't have that much time. 5 seconds is already pushing it for my purpose. Also, I haven't found evidence of such a modified wallet or successful double spends.

So yeah, I still need more time to think about it, but it looks like I will eventually try that very low X value (5 secs) and just see how it goes. Losses will be considered evasion, which already exists in the system. Maybe get some statistics, compare btc evasion vs fiat, and adjust from there.

[t3a]

+ Finney attack risk close to 0, since I will always have better connectivity than the attacker (is this conclusion correct?)

Something similar to a Finney attack can occur. A miners program can give priority to higher fee transaction instead of earlier transactions. If I transacted to you, then paid a higher fee transaction to an address I owned, then the miner might chose to put the one that will make them more money in the blockchain.

[Realpra]

Make sure you have a well-connected node.

After you first see a transaction, wait X seconds and look for double spend attacks.

If no double spend attacks have occurred yet, then you can assume the odds the transaction you want will be included in a block instead of a conflicting transaction is at least Y%.

Don't ask me how to calculate X and Y, but if you can accurately estimate Y then you can just increase your price by n*(1-Y) to cover expected losses from double spends. Where n is the fraction of customers who try to scam you.

To add one important thing to this: Require a reasonable fee from your customers, a zero fee payment versus a high fee double spend is not the best scenario.

[justusranvier]

Another thing you can do is start mining on all the pools that support GBT so that you know what transactions are going to appear in the next block.

If you see the transaction you're interested in get picked up by a majority of the hashing power and no conflicting transactions make it, then you're probably good.

[Herbert]

To make life harder for potential double-spenders make sure to

• have a well connected node
• immediately rebroadcast received transactions relevant for you to as much nodes as possible
• run bitcoind in "nolisten" mode so it is not possible for an attacker to directly "inject" malicious transactions into your bitcoind instance

Note that this just increases the difficulty of certain double-spend attacks. By no way it makes them impossible.