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

Fee Warning on Sweeps #761

Open
editwentyone opened this issue May 21, 2024 · 4 comments · May be fixed by #764
Open

Fee Warning on Sweeps #761

editwentyone opened this issue May 21, 2024 · 4 comments · May be fixed by #764
Assignees
Labels
enhancement New feature or request UI/UX Issue related to cosmetics, design, or user experience
Milestone

Comments

@editwentyone
Copy link

image

Figma

Warning: Sweeps will use a more conservative estimate for the mining fee, which might end up being 80% more expensive than anticipated.

@editwentyone editwentyone added the enhancement New feature or request label May 21, 2024
@editwentyone editwentyone added this to JAM May 21, 2024
@theborakompanioni theborakompanioni added the UI/UX Issue related to cosmetics, design, or user experience label May 21, 2024
@theborakompanioni
Copy link
Collaborator

Ping @kristapsk..
Is

Warning: Sweeps will use a more conservative estimate for the mining fee, which might end up being 80% more expensive than anticipated.

a somewhat valid statement?

(Primary main objective is to make the user aware of it - not for them to know the technical details).

@theborakompanioni theborakompanioni linked a pull request May 22, 2024 that will close this issue
@kristapsk
Copy link
Contributor

Ping @kristapsk.. Is

Warning: Sweeps will use a more conservative estimate for the mining fee, which might end up being 80% more expensive than anticipated.

a somewhat valid statement?

(Primary main objective is to make the user aware of it - not for them to know the technical details).

No, fee estimation is the same. But output and fee amount is calculated for initial number of counterparties, if some of them drop during the process, actual feerate will be higher.

@theborakompanioni
Copy link
Collaborator

Ping @kristapsk.. Is

Warning: Sweeps will use a more conservative estimate for the mining fee, which might end up being 80% more expensive than anticipated.

a somewhat valid statement?
(Primary main objective is to make the user aware of it - not for them to know the technical details).

No, fee estimation is the same. But output and fee amount is calculated for initial number of counterparties, if some of them drop during the process, actual feerate will be higher.

Thanks @kristapsk 🙏
Hmm.. okay, I am still unsure on how to properly re-phrase the warning message to reflect that. I am specifically looking at https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/35e6f286fb9be0dc90c2c5c7648d380c103a3870/src/jmclient/taker.py#L357-L368:

est_ins = len(self.input_utxos)+3*self.n_counterparties
jlog.debug("Estimated ins: "+str(est_ins))
est_outs = 2*self.n_counterparties + 1
jlog.debug("Estimated outs: "+str(est_outs))
self.total_txfee = estimate_tx_fee(
    est_ins, est_outs, txtype=self.wallet_service.get_txtype(),
    outtype=self.wallet_service.get_outtype(self.coinjoin_address()))

Where est_ins assumes 3 inputs by counterparties, and from my understanding, the inability to adjust a change output, increases the fee - not the dropping during the communication process. And with max_sweep_fee_change being 80% by default, I am currently not sure how to come up with a correct and concise message.

On a side note: It would be nice to have access to estimate_tx_fee via RPC!

@theborakompanioni
Copy link
Collaborator

Ping @kristapsk.. Is

Warning: Sweeps will use a more conservative estimate for the mining fee, which might end up being 80% more expensive than anticipated.

a somewhat valid statement?
(Primary main objective is to make the user aware of it - not for them to know the technical details).

No, fee estimation is the same. But output and fee amount is calculated for initial number of counterparties, if some of them drop during the process, actual feerate will be higher.

Thanks @kristapsk 🙏 Hmm.. okay, I am still unsure on how to properly re-phrase the warning message to reflect that. I am specifically looking at https://github.com/JoinMarket-Org/joinmarket-clientserver/blob/35e6f286fb9be0dc90c2c5c7648d380c103a3870/src/jmclient/taker.py#L357-L368:

est_ins = len(self.input_utxos)+3*self.n_counterparties
jlog.debug("Estimated ins: "+str(est_ins))
est_outs = 2*self.n_counterparties + 1
jlog.debug("Estimated outs: "+str(est_outs))
self.total_txfee = estimate_tx_fee(
    est_ins, est_outs, txtype=self.wallet_service.get_txtype(),
    outtype=self.wallet_service.get_outtype(self.coinjoin_address()))

Where est_ins assumes 3 inputs by counterparties, and from my understanding, the inability to adjust a change output, increases the fee - not the dropping during the communication process. And with max_sweep_fee_change being 80% by default, I am currently not sure how to come up with a correct and concise message.

On a side note: It would be nice to have access to estimate_tx_fee via RPC!

@kristapsk Would you be able to clarify your thoughts on this? Would be nice to release soon and have this included. People have raised their unhappiness with the mismatch between their fee expectation and the actual fees paid on sweeps quite often lately and it should at least contain a proper explanation on why that is. At least until a proper fee estimate (maybe by accessing estimate_tx_fee via RPC) can be provided. Is it really only higher if makers drop during the process? Any suggestion would be highly appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request UI/UX Issue related to cosmetics, design, or user experience
Projects
Status: No status
Development

Successfully merging a pull request may close this issue.

3 participants