Guess one, they made a big transaction with most of their hot wallet, partially paying out to someone who withdrew, with the rest going back to the hot wallet. This transaction is in the queue but not finalized yet.
The network won't accept any other spends of that money. Because that would be a double spend. So until that transaction is finalized (or it gets to old) that bitcoin is 'stuck'.
Or alternatively their hot wallet is empty and they have an outstanding transaction to refill it from their cold wallet. (They have the cash, but they have to wait until they can get it from their 'vault', and there is a traffic jam on the way to the vault).
I am not sure the first guess actually still works this way, I vaguely recall there are now mechanisms for one transaction to 'override' another non-confirmed transaction.
Ah ofcourse child pays for parent essentially always works. If I recall correctly replace-by-fee requires wallet support perhaps even at the time of creating the original transaction. But child pays for parent is just universal because it doesn't need to replace the transaction in the mempool, it just pays the miners to move it out of the mempool.
> What queue? Is there a queue in the bitcoin network?
Yes, that's what the mempool is.
>I thought it was a question of paying a high enough transaction fee and you would get your transaction done faster / within 10 minutes.
that's broadly true, but if transaction volume spikes then your initial fee estimate might be too low. there are ways around this (RBF, CPFP), but it's unknown whether their wallet software handles it.
They just described a situation where most of their readily available bitcoin (exchanges do not keep more than a minimum of their available cryptocurrencies in a programmatrically available wallet) could be stuck in the mempool.
It's a queue, but not a first-come first serve one.
The problem I imagine is that, once you set your transaction fee, and it turns out to be too low, it is hard to retroactively pay more fee. Just because the system doesn't allow two spends of the same output in the mempool at the same time, and canceling a transaction is hard.
Guess one, they made a big transaction with most of their hot wallet, partially paying out to someone who withdrew, with the rest going back to the hot wallet. This transaction is in the queue but not finalized yet. The network won't accept any other spends of that money. Because that would be a double spend. So until that transaction is finalized (or it gets to old) that bitcoin is 'stuck'.
Or alternatively their hot wallet is empty and they have an outstanding transaction to refill it from their cold wallet. (They have the cash, but they have to wait until they can get it from their 'vault', and there is a traffic jam on the way to the vault).
I am not sure the first guess actually still works this way, I vaguely recall there are now mechanisms for one transaction to 'override' another non-confirmed transaction.