Open thunderbiscuit opened 1 year ago
Could the issue be related to the bdk-jvm library version we are using in tatooine faucet currently?
This is a simple issue but with a potentially complex solution (or rather, the decision of which solution might be best is likely to involve complex tradeoffs).
The core of the issue is that bitcoin nodes will not accept nor rebroadcast transactions that have more than 25 ancestors in the mempool (so unconfirmed transactions). I ran into this issue a few times when big groups of people downloaded Padawan all at once and a bunch of people made pulls on the faucet at once.
One solution is to implement what is called "transaction batching", where the faucet might wait for a given amount of time (say 1, or 4 minutes) and pay all of the requests at once in one transaction (so you'd have a single tx with many outputs). This is a decent approach but doesn't maximise user experience, particularly because more than 99% of the time this is not an issue.
Another solution is to use coin selection properly to ensure that the wallet does not attempt to build transactions using utxos that have many ancestors in the mempool (maybe just using unbroadcast inputs for each tx). This is likely to be a bit more logic to implement and more code to review, but would ensure we don't build transactions that the mempool will reject.
I am assuming it will require a good amount of bdk libs digging, and once done, implementation won't be hard for android. Can you suggest some resources to get started with? Or should I have some digging into bdk docs: https://docs.rs/bdk/latest/bdk/ ?
This issue arises if too many users request satoshis within the same block. The tatooine wallet/faucet currently creates transactions using unconfirmed UTXOs and if too many of them are already in the mempool you can't broadcast new transactions.