Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Faucet cannot send transactions with more than 25 ancestors #237

Open
thunderbiscuit opened this issue Jan 31, 2023 · 3 comments
Open

Faucet cannot send transactions with more than 25 ancestors #237

thunderbiscuit opened this issue Jan 31, 2023 · 3 comments

Comments

@thunderbiscuit
Copy link
Owner

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.

@thunderbiscuit thunderbiscuit added this to the v1.0.0 milestone Feb 1, 2023
@yellowHatpro
Copy link
Contributor

Could the issue be related to the bdk-jvm library version we are using in tatooine faucet currently?

@thunderbiscuit
Copy link
Owner Author

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.

@yellowHatpro
Copy link
Contributor

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

@thunderbiscuit thunderbiscuit removed this from the v1.0.0 milestone Jul 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants