Pages:
Author

Topic: How can you detect a risky transaction before a single confirmation? (Read 741 times)

legendary
Activity: 3430
Merit: 1957
Leading Crypto Sports Betting & Casino Platform
You guys have blown my mind, I have always thought that the credit being given to the user, was only a entry in the database of the gambling software and not directly linked to the actual Bitcoin deposited. So the risk of a fraudulent transaction can quickly be reversed, by simply subtracting the credit that were given, when the site notice that the confirmations are not going through.  Huh

I also now understand why delays are being imposed on withdrawals to prevent people from depositing fraudulent coins and then quickly withdrawing real coins from the instant credit that was granted by the site.  Wink

It is mind blowing how many attacks and exploits needs to be defended against by these site, to prevent losses for the house.  Angry

legendary
Activity: 2954
Merit: 4158
Transaction Inputs are interesting. Is there an easy way to view this via bitcoin-cli without having to loop and make many calls? Or would it be best practice to just loop through the vins and check if they're confirmed?
You don't have to make many calls to check if your UTXOs are confirmed. You can just use listunspent to check all your confirmed UTXOs at once. If you'd like, you can add arguments to filter out the transactions with less than or more than X confirmations.
copper member
Activity: 173
Merit: 62
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.

Transaction Inputs are interesting. Is there an easy way to view this via bitcoin-cli without having to loop and make many calls? Or would it be best practice to just loop through the vins and check if they're confirmed?
copper member
Activity: 1624
Merit: 1899
Amazon Prime Member #7
Is there an efficient way to detect wallets that are from exchanges etc?
For some exchanges, yes, you could create a database of addresses that can be inferred to belong to an exchange by linking addresses together if the addresses have signed the same transaction, either directly or via a link. For example, if addresses a and b signed the same transaction, and addresses b and c signed another transaction, you can infer that addresses a, b, and c all belong to the same entity. There are limits to this logic, for example this will not hold true if the transaction linking the addresses together is a CoinJoin transaction, or is a LN funding transaction.

For other exchanges that don't spend link all their transactions together, it is more difficult to tell if a particular address is associated with an exchange.
copper member
Activity: 173
Merit: 62
Thanks for all the feedback, I'm constructing the pre-credit system now with all of this advice.
legendary
Activity: 1946
Merit: 1427
If exchanges publish their addresses, maybe. They don't normally do this except for maybe their cold storage addresses, and usually they only do so if there has been some noise about a particular address because it has a large number of coins in it.
Well, no, Walletexplorer for example just looks at a single adress the exchange/service uses, and then connects the dots together
(All the merging transactions for example. see https://www.walletexplorer.com/info).

No need for an exchange to publish their adresses.

And i can only imagine services such as Chainanalysis do this squared,  with much, much more detailed data.
legendary
Activity: 3416
Merit: 1912
The Concierge of Crypto
If exchanges publish their addresses, maybe. They don't normally do this except for maybe their cold storage addresses, and usually they only do so if there has been some noise about a particular address because it has a large number of coins in it.
legendary
Activity: 2730
Merit: 7065
Farewell, Leo. You will be missed!
Is there an efficient way to detect wallets that are from exchanges etc?
Besides https://www.walletexplorer.com/, which was already suggested, you can also take a look at https://bitinfocharts.com/top-100-richest-bitcoin-addresses.html
If you scroll down you can see that several addresses are tagged and belong to Kraken, Binance, Bittrex, Huobi, etc.
legendary
Activity: 3668
Merit: 6382
Looking for campaign manager? Contact icopress!
Is there an efficient way to detect wallets that are from exchanges etc?

I know that https://www.walletexplorer.com/ shows some such addresses. I don't know if the list is perfect (or good enough) though.
copper member
Activity: 173
Merit: 62
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  Grin

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).

Ryan, thank you so much for your feedback! I'm implementing this now Smiley
copper member
Activity: 173
Merit: 62
If you broadcast a tx 9.5 mins after the last block, it might cost 10 sat/byte to get your tx confirmed in the next block but if no blocks are found in the next hour and a half, it might cost 70 sat/byte to get your tx confirmed in the next block and this amount may stay elevated for some time.

In the scenario I am describing, an attacker could make a deposit 1 second after the last block was found, if a block is found within 10 minutes, they could just withdraw their deposit, but if no blocks are found for say an hour, they could make a high probability bet and attempt to withdraw if it is a loosing bet. In this scenario the market cost to get a tx confirmed will have increased due to a lower supply of block space (even if this is temporary). 

I didn't say that your scenario is impossible. I only said that it's not 100% risk free. There can be some blocks found very quick, there can be low fee transactions included in them (CPFP for example), ... which can spoil the plans of the attacker. However, his chances are still very high indeed.
We are on the same page: private (proper) wallets are not to be trusted for 0-confirmation funding.

Is there an efficient way to detect wallets that are from exchanges etc?
legendary
Activity: 3668
Merit: 6382
Looking for campaign manager? Contact icopress!
If you broadcast a tx 9.5 mins after the last block, it might cost 10 sat/byte to get your tx confirmed in the next block but if no blocks are found in the next hour and a half, it might cost 70 sat/byte to get your tx confirmed in the next block and this amount may stay elevated for some time.

In the scenario I am describing, an attacker could make a deposit 1 second after the last block was found, if a block is found within 10 minutes, they could just withdraw their deposit, but if no blocks are found for say an hour, they could make a high probability bet and attempt to withdraw if it is a loosing bet. In this scenario the market cost to get a tx confirmed will have increased due to a lower supply of block space (even if this is temporary). 

I didn't say that your scenario is impossible. I only said that it's not 100% risk free. There can be some blocks found very quick, there can be low fee transactions included in them (CPFP for example), ... which can spoil the plans of the attacker. However, his chances are still very high indeed.
We are on the same page: private (proper) wallets are not to be trusted for 0-confirmation funding.
legendary
Activity: 2954
Merit: 4158
If you broadcast a tx 9.5 mins after the last block, it might cost 10 sat/byte to get your tx confirmed in the next block but if no blocks are found in the next hour and a half, it might cost 70 sat/byte to get your tx confirmed in the next block and this amount may stay elevated for some time.

In the scenario I am describing, an attacker could make a deposit 1 second after the last block was found, if a block is found within 10 minutes, they could just withdraw their deposit, but if no blocks are found for say an hour, they could make a high probability bet and attempt to withdraw if it is a loosing bet. In this scenario the market cost to get a tx confirmed will have increased due to a lower supply of block space (even if this is temporary). 
There's a simple solution to this possible problem. The reference nodes do not relay transactions that are already in their mempool, unless it has an Opt-in RBF flag. This means that if there is another transaction that spends the same input as another transaction in the mempool, the client would automatically reject that transaction and thus it would have a bad propagation. It takes quite a while for the transaction to be dropped from the mempool of the individual nodes in the network. Until then, you won't be able to double spend the inputs. Even if it does get dropped, the casino can simply just rebroadcast the transaction and it would be back in the mempool.

Of course, this could still be successful in certain instances but with a proper risk management, the losses suffered by the casino would be negligible.
copper member
Activity: 1624
Merit: 1899
Amazon Prime Member #7
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.
If you broadcast a tx 9.5 mins after the last block, it might cost 10 sat/byte to get your tx confirmed in the next block but if no blocks are found in the next hour and a half, it might cost 70 sat/byte to get your tx confirmed in the next block and this amount may stay elevated for some time.

In the scenario I am describing, an attacker could make a deposit 1 second after the last block was found, if a block is found within 10 minutes, they could just withdraw their deposit, but if no blocks are found for say an hour, they could make a high probability bet and attempt to withdraw if it is a loosing bet. In this scenario the market cost to get a tx confirmed will have increased due to a lower supply of block space (even if this is temporary). 
legendary
Activity: 3668
Merit: 6382
Looking for campaign manager? Contact icopress!
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.
copper member
Activity: 1624
Merit: 1899
Amazon Prime Member #7
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.
legendary
Activity: 1904
Merit: 1073
-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.  Grin  (Gambling sites can restrict zero confirmation transactions on the deposit amount too)
legendary
Activity: 3416
Merit: 1912
The Concierge of Crypto
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.)
copper member
Activity: 173
Merit: 62
Thank you for all the feedback! Extremely useful.
legendary
Activity: 3668
Merit: 6382
Looking for campaign manager? Contact icopress!
I did.

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

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.
Pages:
Jump to: