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

[PrimeNumber7]

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

[1713945426]

1713945426

[1713945426]

1713945426

[1713945426]

1713945426

[1713945426]

1713945426

[ranochigo]

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.

[NeuroticFish]

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.

[absolutely-positioned]

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?

[absolutely-positioned]

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

Ryan, thank you so much for your feedback! I'm implementing this now

[NeuroticFish]

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.

[Pmalek]

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.

[Dabs]

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.

[AdolfinWolf]

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.

[absolutely-positioned]

Thanks for all the feedback, I'm constructing the pre-credit system now with all of this advice.

[PrimeNumber7]

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.

[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?

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?

[ranochigo]

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.

[Kakmakr]

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. 

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

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