How to minimize risk when accepting zero confirmation payments?

[RocketNuts]

I'm trying to setup a way of accepting Bitcoin payments in real life situations, where waiting for confirmations is typically not an option. I understand this is never 100% risk free (especially with crap like bitundo.com around), I just want to minimize the risk.

I've got a Bitcoin Core wallet with a bunch of unused addresses. I show the customer an address, he sends the money, and now I can do a few things: (all automated, i.e. through some kind of application or script)

1. Check if the (unconfirmed) transaction appears on my own node / in my wallet
2. Check if the (unconfirmed) transaction appears on sites using online APIs like blockr.io and blockchain.info
3. Check if I don't see a similar transaction (from the same input address, but to another output address, i.e. a double spend attempt) on either my node or API sites.

If 1 or 2 are OK and 3 doesn't occur for e.g. five to ten seconds, how (un)certain is the transaction at this point?

I noticed that payment providers like bitpay and coinbase can sort of accept payments immediately, how do they tell legit transactions from double spend attempts?

[1715340530]

1715340530

[TierNolan]

I'm trying to setup a way of accepting Bitcoin payments in real life situations, where waiting for confirmations is typically not an option. I understand this is never 100% risk free (especially with crap like bitundo.com around), I just want to minimize the risk.

I've got a Bitcoin Core wallet with a bunch of unused addresses. I show the customer an address, he sends the money, and now I can do a few things: (all automated, i.e. through some kind of application or script)

1. Check if the (unconfirmed) transaction appears on my own node / in my wallet
2. Check if the (unconfirmed) transaction appears on sites using online APIs like blockr.io and blockchain.info
3. Check if I don't see a similar transaction (from the same input address, but to another output address, i.e. a double spend attempt) on either my node or API sites.

If 1 or 2 are OK and 3 doesn't occur for e.g. five to ten seconds, how (un)certain is the transaction at this point?

I noticed that payment providers like bitpay and coinbase can sort of accept payments immediately, how do they tell legit transactions from double spend attempts?

There was a paper about a system for vending machines.  They connected to something like 100 other nodes, sent the transaction out to 50 of them and listened for potential double spends on the other 50.  This was required because once you send a node the original transaction it will never forward the double spend.

An easy way to implement this would be to have two nodes, one for sending and one for listening.

You could ask the customer to sign the transaction (but not broadcast it) and then wait a few seconds and then broadcast.  If you see no double spend attempts on your listening nodes, then it is probably safe.

The problem is that you also need to consider hidden transactions.

Replace by fee is a reasonable policy for a mining pool to have.   BitUndo allows sending of a transaction to them that they kept secret.  Double spends are a big application of that.

If 5% of the hashing power is hidden pools, then double spends will always have a 5% chance of working.

[RocketNuts]

Replace by fee is a reasonable policy for a mining pool to have.

I haven't put much thought in replace by fee yet, but I tend to doubt it. It seems an incentive to attempt double spending (although I do understand Peter Todd's explanation on how to take measures against this, as a merchant getting ripped off from double spending).

BitUndo allows sending of a transaction to them that they kept secret.  Double spends are a big application of that.

Yeah, BitUndo pretends do be a nice service to the Bitcoin community of some sorts, but imho it's actually very bad that this exists.

But if I'm no mistaken, BitUnfo still does distributed mining, since essentially it's "just another mining pool" (except with specific purposes and rules) right? How do they keep the transactions secret? Do they deliberately not relay any transactions until mined, or...?

[TierNolan]

But if I'm no mistaken, BitUnfo still does distributed mining, since essentially it's "just another mining pool" (except with specific purposes and rules) right? How do they keep the transactions secret? Do they deliberately not relay any transactions until mined, or...?

Mining pools don't have to give any information about the block that they are mining to the hash providers. 

They would have to tweak bitcoind not to relay the secret transactions.

[Peter Todd]

Regardless of what risk minimization techniques you attempt, I highly suggest you try playing with my replace-by-fee-tools first to get a sense of how easy it is to double-spend, and for that matter, whether your techniques actually work at all.

Remember that it's always possible to double-spend with ~%10 probability by giving a non-standard transaction double-spending the input to Eligius first, followed by broadcasting the standard transaction to the rest of the Bitcoin network.

[bitcoinbeliever]

If [observing double-spend] doesn't occur for e.g. five to ten seconds, how (un)certain is the transaction at this point?

Very uncertain.  The current network actually suppresses transmission of the double-spend.

.. my replace-by-fee-tools

So the intention is to allow a higher-fee version of a transaction to be relayed?  But I could not see any attempt to check that the original recipient still gets as much as before.  If he gets less, he's being double-spent right?  And how could you do more than guess about that?

Also, there could be side-effects because the replaced transactions, which are wiped out, could easily have had additional outputs.

[TierNolan]

Very uncertain.  The current network actually suppresses transmission of the double-spend.

That is why the vending machine paper had 2 sets of connections.  Once you send a transaction to a node, you will never hear about a double spend from that node. 

The send on the outgoing connections and then listen on the receiving ones.

So the intention is to allow a higher-fee version of a transaction to be relayed?

Right, the assumption is that the miner is greedy.

A second level is the child pays for parent patch.  This means that high fee transactions can "share" their fees with parents.

TX-0: pay merchant 0.99BTC, fee 0.01BTC
TX-1: pay customer 0.98BTC, fee 0.02BTC (replace by fee double spend)

TX-2: from TX-0 pay 0, fee 0.99 ("scorched earth" transaction)

A miner who includes TX-2 gets 0.99 BTC  as a fee.  However, it can only be included if TX-0 is included.  Transactions are around 250 bytes.

TX-0, TX-2 = 1BTC total fee for 500 bytes
TX-1 = 0.02BTC for 250 bytes

The TX-0/TX-2 pair has a much higher fee per byte, so replace by fee + child pays for parent miners will mine that pair.

This means that the customer is prevented from getting the refund, but the merchant also loses.

If a merchant has a reputation for reacting that way, then few customers will try to double spend against him.

Peter Todd's observations means that merchants need to verify that transactions they receive are acceptable to as many nodes as possible.

For "instant" transactions, they should require the transaction is one of the standard transactions at minimum. 

Even then, Eligius apparently has a black list of addresses, so merchants would need to know them too.

In theory, a merchant could be define the change address.

Client has private key kpriv and computes public key (Kpub = kpriv * G).

Client sends Kpub to the merchant

Merchant responds with a random number r.

The transaction is defined to be of the form

- All inputs must be the simple standard script

- Only 2 outputs and also standard payment script
- Pays the merchant's key
- Pays [r * Kpub] (change address)

The private key for the change address is kpriv * r (due to EC maths).

This produces a change address that only the client knows the private key for, while guaranteeing that it is random (so unlikely to be blacklisted).

That should consistently produce transactions that are acceptable to almost all "honest" pools.

Hidden pools are still the problem.  If 10% of the pools don't forward transactions they receive, then you have a 10% chance of successfully double spending.

[Dana Hobson]

Has anyone done empirical analysis to determine the probability of a failed transaction after a given number of confirmations?

More specifically:
    If my transaction has 0 confirms (i.e. not in a block yet), what is the chance if will eventually fail to fully confirm?
    If my transaction has 1 confirm (i.e. in exactly 1 block so far), what is the chance if will eventually fail to fully confirm?
    And so on ...

I believe this cannot be done directly from the blockchain, as a failed transaction is not in the blockchain (?). I thnk you need to look at all transactions, failed or fully confirmed.

Does it boil down to noting which transactions belonged to forks which did not prevail and are not in the prevailing fork?

My interest here is really an empirical or numerical analysis. I am not looking for the model approach, nor is opinion, erudite or otherwise, gonna do the trick. Just how often it has happened.

Thanks!

[cr1776]

Has anyone done empirical analysis to determine the probability of a failed transaction after a given number of confirmations?

More specifically:
    If my transaction has 0 confirms (i.e. not in a block yet), what is the chance if will eventually fail to fully confirm?
    If my transaction has 1 confirm (i.e. in exactly 1 block so far), what is the chance if will eventually fail to fully confirm?
    And so on ...

I believe this cannot be done directly from the blockchain, as a failed transaction is not in the blockchain (?). I thnk you need to look at all transactions, failed or fully confirmed.

Does it boil down to noting which transactions belonged to forks which did not prevail and are not in the prevailing fork?

My interest here is really an empirical or numerical analysis. I am not looking for the model approach, nor is opinion, erudite or otherwise, gonna do the trick. Just how often it has happened.

Thanks!

There are a number of other factors at work as to whether a transaction would confirm or not and so would be useful to track for an analysis:  
1. The percentage that paid fees, whether those fees were the suggested fees or less or more.
2. Whether they were non-standard transactions (e.g. like what gox was doing which resulted in fewer nodes relaying them - so much of the network did not see the transactions until they were 'fixed').
3. It would be useful to track it over time too. e.g. 2011 vs 2012 vs 2013 vs 2014.
4. March 11/12, 2013 would be an interesting case

One issue for past analysis would be getting data for zero-confirmed transactions.  Going forward, you'd have to record all transactions your node sees (which if you have a well connected node, could be a very high percentage) since zero-confirmation transactions are, by definition, not in the block chain.

My experience is that if you pay a fee (or have a high priority transaction) and the transaction is standard, it will confirm.   Of course you could run a test yourself and set up 100s of transactions of each type over a period of time and measure the results.

[Brangdon]

There was a paper about a system for vending machines.  They connected to something like 100 other nodes, sent the transaction out to 50 of them and listened for potential double spends on the other 50.  This was required because once you send a node the original transaction it will never forward the double spend.

Is there any interest in having a way for nodes to broadcast alerts about the double-spends they detect? Is there a concern doing so could be exploited for denial of service?

[Dana Hobson]

Yes, I'm interested in a "good guys" service that deploys a network of neutral nodes that would, among regular activities of an upstanding node, sniff for double spends (I mean unconfirmed txns that spend the same inputs). If that network distributes nodes effectively across the graph, it would make it very difficult for an attacker to hide a double spend txn from the merchant node to which he sent the deceptive original txn. The merchant could check with that network before committing to the original txn. This form of validation could transpire in seconds and afford something like the same level of protection as waiting ~10min for the 1st block confirm.

And why not call it Palantir to make sure everyone knows a nerd thought of it?

[Dana Hobson]

I believe the paper you meant is "Have a Snack, Pay with Bitcoins" 

http://www.tik.ee.ethz.ch/file/848064fa2e80f88a57aef43d7d5956c6/P2P2013_093.pdf