How can you detect a risky transaction before a single confirmation?

[absolutely-positioned]

I'm creating a payment gateway and I'm curious how some sites pre-credit users on certain gambling sites before 1 confirmation. I've heard to look for low fees but is that it?

[jackg]

No. I was testing with this a while ago. Even if the fee is high they can still go higher and it'll become more favourable.

Accepting inputs at 1 sat per byte can also cause some risks but not as big.


Reducing risk, you can wait for no confirmations if rbf is disabled and fee is fairly high (but they could still push it through a pool with a higher fee so you're still taking a risk)...

Until the 6th confirmation, holding bitcoin is a bit like holding cash in a store... After you have the first tx and its confirmed or it isn't rbfable then you shouldn't have funds stolen (unless they control a lot of hash power or know someone who does) if you're a large store/site, you don't have to care so much about tiny transactions and can care more about the big ones which I think is how those gambling sites go (they'll still want 6 confs at some point - normally before withdraw).

[AverageGlabella]

Don't accept instant payments on your payment gateway and always wait for confirmations. 1 confirmation is probably enough in most transactions to see if its able to be reversed or considered to be risky. I would advise that you always wait for that 6 confirmation to come in before processing the order however you could accept the transaction and get processing ready. Bitcoin is not meant to be used for instant payments and instead its to be used for high security payments and that's why its always best to wait for confirmations.

[DannyHamilton]

I'm creating a payment gateway and I'm curious how some sites pre-credit users on certain gambling sites before 1 confirmation. I've heard to look for low fees but is that it?

Everyone needs to decide for themselves how much risk they are willing to accept.

If you are going to accept an unconfirmed transaction, then you should take the time to learn what the risks are, as well as what can be done to reduce those risks.

For example, if you have an alternative method of collecting money (or retrieving whatever you have provided) from the payor (credit card on file, bank account ACH, court system, enforcer with a baseball bat, etc), then it is a lower risk to accept the unconfirmed transaction, since you can always use your backup method whenever the transaction fails to confirm.

If you are just asking about the technical details of a bitcoin transaction, then there are a few things to look at when determining risk...

1) Value of transaction.  It is MUCH riskier to accept a single 10 BTC transaction with no confirmations than it is to accept ten 0.0001 BTC transactions with no confirmations.

2) Transaction inputs. It is MUCH riskier to accept, with no confirmations, a transaction that has unconfirmed inputs than it is to accept a transaction that exclusively uses confirmed inputs.

3) Transaction fee. It is MUCH riskier to accept, with no confirmations, a transaction that doesn't include any transaction fee. The larger the transaction fee, the lower the risk.

4) Competing transactions.  It is MUCH riskier to accept, with no confirmations, a transaction that uses inputs which are also used in one or more other unconfirmed transactions.

5) Node isolation. It is MUCH riskier to accept (even confirmed) transactions when your nodes are completely isolated from the rest of the bitcoin network by a single entity.

[NeuroticFish]

and I'm curious how some sites pre-credit users

The only place I've seen such behavior was when the "wallet" was a service owned by a partner company of the receiver.
But in theory if one knows that certain addresses belong to certain services (custodian wallets or maybe exchanges too), he can whitelist them and credit unconfirmed transactions, because those don't double spend transactions, the risk is much lower. Just... how to obtain such a list of addresses?

[RHavar]

Yeah, you can. Some big sites like bustabit.com do this. Actually I originally authored the code, and it has been very successful. To all the people who think it's not possible, make a deposit on bustabit and try defraud the system. I'll wait 

However there's two things you to keep in mind to make it work

a) Charge for the service. It's really important people can't attempt to defraud you for free.  (For instance bustabit charges 1% for the precredit service, that way it costs money to try abuse the system. i.e. you need to be able to defraud them more than 1 or 2% of the time to be profitable).

b) Have a fallback for transactions without high enough enough confidence (i.e. accept a lot of false negatives)


---

The very first thing you need to do, is check if the transaction opts into bip125. If so, then it's never going to be safe prior to confirmations. Then assuming it's not bip125, what you want to do is make sure the transaction hasn't been raced. So have quite a few nodes in different spaced around the world, ideally with slightly different bitcoin core versions. Then wait a few seconds, and only precredit the transaction if every node has the transaction and it's got a decent fee rate.

Then if you want to get fancy, you can also monitor for double-spend attempts (but this is a pain in the ass, as you have to modify core) and they can report to you if they have seen an attempt.

And then most importantly, have a good system that notifies you (And possibly pulls the plug) if you get defrauded. Make sure you never precredit more than {uperBound} of bitcoin at any time, to cap your total risk.


--

Also keep in mind that it's perfectly possible to do now. HOWEVER tomorrow it might not be possible. If a small mining pool decided to (privately) accept double spends, you'd be irreparably screwed. So make sure your business model doesn't depend on "pre-crediting" or you could find yourself out of business overnight. (But it's a super cool nice-to-have to make an experience better).

[jackg]

Yeah, you can. Some big sites like bustabit.com do this. Actually I originally authored the code, and it has been very successful. To all the people who think it's not possible, make a deposit on bustabit and try defraud the system. I'll wait 


~snip~

Also keep in mind that it's perfectly possible to do now. HOWEVER tomorrow it might not be possible. If a small mining pool decided to (privately) accept double spends, you'd be irreparably screwed. So make sure your business model doesn't depend on "pre-crediting" or you could find yourself out of business overnight. (But it's a super cool nice-to-have to make an experience better).

Yeah opting out of bip143 really does add a difficulty. I might have to run a retest on double spending non rbf transactions to see how far I can stretch it by devoting some hashing power to it last time I was just using two nodes to double spend rbf txs and didn't put much effort into not spending the non rbf tx...


Accepting just one confirmation is still pretty risky in some cases (when the fees are higher) especially since a new tx with a higher fee can push the one crediting you down further. This is negated if you have something running cpfp though (as I've seen a few sites do).

[RHavar]

Yeah opting out of bip143 really does add a difficulty.

I'm not sure if this is a typo, or a misunderstanding. The correct bip is bip125.

I might have to run a retest on double spending non rbf transactions to see how far I can stretch it by devoting some hashing power to it last time I was just using two nodes to double spend rbf txs and didn't put much effort into not spending the non rbf tx...

If you have >2% of the global bitcoin hash power, you will be able to double-spend against bustabit profitably.

Accepting just one confirmation is still pretty risky in some cases (when the fees are higher) especially since a new tx with a higher fee can push the one crediting you down further. This is negated if you have something running cpfp though (as I've seen a few sites do).

I don't think you've thought that through. Assuming 100% of miners are acting honestly, abusing 1 confirmation is exceedingly hard. You basically require a block-race in which the blocks abusably diverge, and then from the receivers point of view it reorgs.

But for something like bustabit, that's super easy to prevent. You can just give people their money after 1 confirmation, but prevent them withdrawing anything derived from that money until the deposit has N confirmations. At that point, it's just not even worth trying to abuse.

[nc50lc]

-snip- I've heard to look for low fees but is that it?

It's pretty simple actually.
Most of those site do not enable withdrawals if any of the deposit transactions didn't have 6 confirmations.
Even if the client decided to double spend his pending deposit, he won't be able to withdraw his winnings/pre-credited balance.

Nothing goes in -> Nothing goes out
Couple it with a strict terms and conditions and you're good to accept instant deposits.

[PrimeNumber7]

and I'm curious how some sites pre-credit users

But in theory if one knows that certain addresses belong to certain services (custodian wallets or maybe exchanges too), he can whitelist them and credit unconfirmed transactions, because those don't double spend transactions, the risk is much lower. Just... how to obtain such a list of addresses?

Moron, you aren't withdrawing from the gambling site until it is confirmed.

Even if the casino does not allow for unconfirmed deposits to be withdrawn, the gambler can make a single high probability bet, and if the bet is unsuccessful (losses), the gambler can try to double spend the transaction, and otherwise will wait for the transaction to confirm before trying to withdraw. This means the customer is able to make a risk free bet.

[NeuroticFish]

Somehow everybody missed the part where I was telling about 3rd party custody wallets. Like Xapo, or exchanges...

Good luck double spending from there.

[nc50lc]

Even if the casino does not allow for unconfirmed deposits to be withdrawn, the gambler can make a single high probability bet, and if the bet is unsuccessful (losses), the gambler can try to double spend the transaction, and otherwise will wait for the transaction to confirm before trying to withdraw. This means the customer is able to make a risk free bet.

Not accepting marked rbf transactions (like suggested above) might minimize those attempts since it will be troublesome or costly to contact a pool that's willing to include the double-spend tx instead of the 1st one.
And IMO, that's too much for a "risk free bet".

He can also, set a maximum allowed instant deposit, anything higher will require 1 confirmation.

Note: non-rbf tx aren't "replaceble" by default. The gambler needs to directly contact a pool operator or a solo miner to include the new tx.

[Pmalek]

There is an exchange called Liquid that credits a users Bitcoin deposit with zero block confirmations. They do it as soon as the transaction is broadcast to the network. They claim that their users can start trading in as fast as 10-20 seconds.
I remember that this exchange had no fees for withdrawals in the past, not sure if that is still the case.

Here is the announcement regarding the bitcoin deposits with zero block confirmations.
https://blog.liquid.com/fast-bitcoin-deposits-are-now-even-faster-on-liquid

[jackg]

~snip

Yeah I was trying to remember a derivation path at the same time oops...

I won't try it on any services offering that I was going to try it on one of my own addresses or someone I know just it see...

Somehow everybody missed the part where I was telling about 3rd party custody wallets. Like Xapo, or exchanges...

Good luck double spending from there.

I did. But all it takes is a bit of social engineering to try to get them to contact an engineer to push through a double spend... Or even someone in the inside could try doing something with some of the exchanges hot wallet. While it's unlikely you have to assess each exchange and see how likely that would be to happen and then difficulty is added. Also if you decide to delist an exchange from your service people are going to be greatly peeved that they used to get a confirmation quickly and now have to wait 20 minutes.


It's probably worth op doing some field research and buying some stuff from different sites to see how it works. If you sell goods but don't have fast delivery then some services accept an unconfirmed tx and then wait for confirmations before dispatching, similar to what a lot of gambling sites do as stated above.

[NeuroticFish]

I did.

Thank you. At least you didn't call me "moron" 

But all it takes is a bit of social engineering to try to get them to contact an engineer to push through a double spend...

I don't think that this is an easy task. It's pretty unlikely to happen.

Or even someone in the inside could try doing something with some of the exchanges hot wallet. While it's unlikely you have to assess each exchange and see how likely that would be to happen and then difficulty is added. Also if you decide to delist an exchange from your service people are going to be greatly peeved that they used to get a confirmation quickly and now have to wait 20 minutes.

OK. Quite unlikely situations, but at least this makes sense.

It's probably worth op doing some field research and buying some stuff from different sites to see how it works. If you sell goods but don't have fast delivery then some services accept an unconfirmed tx and then wait for confirmations before dispatching, similar to what a lot of gambling sites do as stated above.

Yup. OP has got some ideas in this thread and this is one important direction to take.

[absolutely-positioned]

Thank you for all the feedback! Extremely useful.

[Dabs]

There was a study some time ago, where after a transaction has been detected by your full node on the network, wait about 5 to 10 seconds, then check again if there have been any double spend attempts or broadcasts related to the original transaction.

You could also recognize that a transaction has been received, alert the user, but not process it until a confirmation or a block has a been mined. Some exchanges do this, they see the transaction and mark it as "incoming" but not actually credit your account until a few confirmations.

To summarize:

1. tx has a fee, maybe try to calculate this or estimate if it will confirm soon.
2. tx is NOT RBF.
3. wait 10 seconds.
4. check again, if nothing looks funny, can accept it.
5. if you have access to more than one full node, use them. put them on opposite ends of the planet (or pick two different countries at least.)

[Kprawn]

-snip- I've heard to look for low fees but is that it?

It's pretty simple actually.
Most of those site do not enable withdrawals if any of the deposit transactions didn't have 6 confirmations.
Even if the client decided to double spend his pending deposit, he won't be able to withdraw his winnings/pre-credited balance.

Nothing goes in -> Nothing goes out
Couple it with a strict terms and conditions and you're good to accept instant deposits.

Yea, I guess if you can manage the risk, then you can implement zero confirmation transactions. One example of this might be shops where the

maximum value of the transaction or credit given, would not be large amount to justify fraudulent transactions. Let's say a Coffee shop wants to

offer some instant payments for coffee, then they can do that for small valued transactions.. because it will not bankrupt them if they get the odd

fraudulent transaction for the cost of a cup of coffee. Some food merchants in our food court accepts "zero" confirmation transactions on single

purchases below $20.    (Gambling sites can restrict zero confirmation transactions on the deposit amount too)

[PrimeNumber7]

Even if the casino does not allow for unconfirmed deposits to be withdrawn, the gambler can make a single high probability bet, and if the bet is unsuccessful (losses), the gambler can try to double spend the transaction, and otherwise will wait for the transaction to confirm before trying to withdraw. This means the customer is able to make a risk free bet.

Not accepting marked rbf transactions (like suggested above) might minimize those attempts since it will be troublesome or costly to contact a pool that's willing to include the double-spend tx instead of the 1st one.
And IMO, that's too much for a "risk free bet".

He can also, set a maximum allowed instant deposit, anything higher will require 1 confirmation.

Note: non-rbf tx aren't "replaceble" by default. The gambler needs to directly contact a pool operator or a solo miner to include the new tx.

a non-rbf tx can still be "replaced" (double spent) without the assistance of a miner. If there are many unconfirmed txs competing with each other (such as what happened in late 2017), an unconfirmed tx may eventually get 'dropped' by most nodes, including the nodes the miners use, which would make it trivial to double spend one of the inputs as long as you use a sufficiently high tx fee.

Someone may also craft their tx so its chances of getting dropped by most nodes is higher, and they may for example wait until there is a higher chance there will be an increasing backlog to even attempt this bet, such as after a long delay between two blocks to even try the high probability bet. An attacker may for example, broadcast a tx immediately after a block is found, and if it has been at least xx minutes since the tx was broadcast, make the risk free bet, otherwise they may immediately withdraw their deposit after making a nominal sized bet after the tx confirms.

[NeuroticFish]

a non-rbf tx can still be "replaced" (double spent) without the assistance of a miner. If there are many unconfirmed txs competing with each other (such as what happened in late 2017), an unconfirmed tx may eventually get 'dropped' by most nodes, including the nodes the miners use, which would make it trivial to double spend one of the inputs as long as you use a sufficiently high tx fee.

Yup. That's why I suggested OP to allow 0-conf to certain (custodian) wallets which don't allow users do rbf at all.

An attacker may for example, broadcast a tx immediately after a block is found, and if it has been at least xx minutes since the tx was broadcast, make the risk free bet

The previous number of minutes between blocks doesn't necessarily give a hint for the number of minutes until the next block, so it's not risk free. It may reduce the risk (debatable), but doesn't make it risk free.