Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
use
feerate
instead offee
while sending a transaction #343base: master
Are you sure you want to change the base?
use
feerate
instead offee
while sending a transaction #343Changes from 1 commit
0b1819d
1d94e2c
dfd67f8
aec4eec
d0e8a5b
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think this logic can be moved to the call sites, or better, create wrapper APIs on top of a common send API. Weather a utxo is valid for spend should be determined at the call site.
For ex: if you wanna spend only fidelity bonds in API like
spend_fildiety()
you filter out the fidelity utxo, and then feed to the commonspend_coins()
API.This will also allow us to use a common logic for all kind of spendings and use that everywhere, instead of current individual design of each spend functions. This refactor is much needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Makes sense. Partially addressed via aec4eec.
I'll try once to get the
size
of tx using the descriptor instead of current workaround(hardcoding witness sizes). Once that's done, the API would be lot cleaner.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This doesn't have to be 0. You can set it to the actual value needed here only.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm validating
send_amount
against fee parameters later, that's why I kept it 0, and the value is added later. Does keeping it this way makes more sense, or shall I change it?There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Change it, please. There is no ambiguity about the send amount. Just set the value here.
This approach makes sense for change amount where you don't know the value before hand.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I see, you need this to handle the max spend case. Cool then it can stay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
On a second thought. Lets remove this
SendAmount::Max
thing. It's not working as expected. It will only create a non-change spend from with the given inputs. That doesn't mean thats the max wallet amount. The current design is not ideal too. SpecifyingMax
and selected coin list in the input together is redundant and circular. Makes it almost unusable for the sweeping purpose.Instead there should a be dedicated API called
seep_wallet(dest_addr)
, which doesn't need any other input from the user, finds the total spendable utxos, create one tx with no change to sweep the whole wallet balance todest-addr
. This can be done in a followup PR. For now we can simplify the spend logic much more if we remove the Max enum.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One good way of doing it would be to have a
SpendType
enum.When
NoChange
is given, it will create a change less tx, sending the wholetotal_input - fee
to thedest_addr
. This will be useful for fidelity, and contract spendings.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
https://github.com/claddyy/coinswap/blob/d0e8a5b165d26a0e8a4c34a5b126f20814e51044/src/wallet/direct_send.rs#L201-L204
SpendType seems to be just same as the SendAmount enum. Currently when
Max
is given, the change less tx is created.