-
-
Notifications
You must be signed in to change notification settings - Fork 34
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
Not accounting for non-RGB inputs in coin selection #113
Comments
Yes, you are right in your assumption. I remember writing that logic, but it seems somehow it is skipped. We need to move the issue into BP wallet since it happens there. |
Suppose Alice has one UTXO with 2000 sats. |
It would - you just need to add more tx inputs and feed additional sats into the witness transaction |
Re-opening and changing the name as explained in BP-WG/bp-wallet#13 (comment) |
Now, there is the question: when and how should we use non-RGB inputs for moving some BTCs to RGB outputs. In other words, this situation is not a bug but a feature - however possibly bad UX. I just do not know how to make it better: I assume many wallets will differenciate BTC and RGB balances, and if some BTC are "disappearing" after RGB transactions it would be even worse UX... |
I agree that using funds from the "BTC balance" without prior user consent would be bad UX. I propose doing something similar to what rgb-lib does to handle this. Specifically, I would:
|
This is a large feature request, and since |
Trying to execute a few transfers using this branch of rgb-sandbox I run into the following error:
The wallet should have enough bitcoins as the unspents come up as:
I guess this happens because the input selection is not adding more inputs if needed to cover fees (or outputs), but I haven't dug deeper than this.
The text was updated successfully, but these errors were encountered: