search

bisq-network / proposals

@bisq-network improvement proposals
https://bisq.wiki/Proposals
43 stars 16 forks source link

Allow 1sat/vByte fee for withdrawals #343

Closed GordianLN closed 2 years ago

GordianLN commented 2 years ago

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

When withdrawing funds off the application, you can enable custom transaction fee, but it can only be lowered down to 2sat/vByte, trying to set 1sat/vByte returns an error. This will lead to spend fees 2x than needed during empty mempool periods, like this one; some might argue it is a minimal cost, and indeed it is, yet it still weights on the total costs, and should be trivial to alter in the application source in order to save something. Some might also argue that a 1sat/vByte fee could lead to the transaction not getting confirmed in a useful time frame, but this could still happen to any fee higher than 1 during high mempool usage, in the end it's the user's responsibility to choose the best fee; and in any case, a transaction not getting confirmed could either be sped up with Child Pays For Parent on the receiving wallet, or just be sent again with a higher fee once it comes back into Bisq wallet after having expired in mempool, so no damage there.

GordianLN commented 2 years ago

Thank you @pazza83 , I also forgot to mention that in the worst case scenario, where you were so unlucky to withdraw at 1sat/vB right before a huge mempool rush lasting for weeks, it wouldn't be much of a hassle even without RBF, since someone could probably do a CPFP or wait for the transaction to disappear to find the funds back in Bisq wallet.

pazza83 commented 2 years ago

Hi @asvdf thanks for making this proposal.

I think this is an important issue for discussion but would benefit from you expanding on the proposal to stand the best chance of engaging users. For more info on how to write an effective proposal please see https://bisq.wiki/Proposals

GordianLN commented 2 years ago

Thank you for getting back to me, I think I understood your post as "make the point so it will be more interesting for other users to accept", so I reworded the OP to this extent.

Liisachan commented 2 years ago

Basically, this is simply widening options without breaking anything that already exists in the current version.

When sending something to your peer, you should obviously try to do that quickly, paying reasonable fees if necessary, because your peer is waiting. But here we're talking about withdrawal, a solo/private action of the user. Even if such a transaction takes forever or even fails, no one would be annoyed in any way, except maybe that user themselves.

As such, I'm not really sure if discussion like this is even necessary. Why would anyone be against this? The only possible reason I can think of is, well, one could argue that by setting the withdrawal fee higher than actually necessary, users are somewhat discouraged from withdrawing their BTC from Bisq wallets, and thus encouraged (or implicitly forced) to use Bisq forever, which is beneficial to the community in a way. However, such an attitude (taking your fund as a hostage, so to speak) would be imho antithetical to what Bisq stands for - decentralization, anti-monopolization, liberty, etc. Moreover, high fees would only make it less attractive to potential new users, so that'll only backfire in the long run.

That said, the difference between 1 sat and 2 sats is so small, perhaps almost no one really cares whichever. Then again, every satoshi counts :) A satoshi saved is a satoshi earned. Relatively speaking, 1 sat/vB is a whapping 50% discount compared to 2 sat/vB, even though the absolute amount is negligible anyway!

GordianLN commented 2 years ago

At current prices, we are looking for 10c saved, or little less, for each transaction, by being able to set 1sat/vB per withdrawal. Don't know about you, but if I found a penny on the street I'd pick it up, so all the more reason not to throw away 10c in unneeded fees 😄

pazza83 commented 2 years ago

Are any of the @bisq-network/dev able to comment as to the benefits / negatives of reducing withdrawal fees to 1 sat/vB?

Is the 2 sat/vB min limit is to reduce potential support requests for users that fail to make a withdrawal with the appropriate fee? Or is there another reason/s?

GordianLN commented 2 years ago

We are probably looking at a long while (if not forever) with low onchain fees, thanks to a lot of traffic moving on lightning, so I'd say no reason not to let users save on fees. Plus, anything that will get stuck on mempool at 1sat/vB, would probably get stuck at 2sat/vB as well, just a little less.

chimp1984 commented 2 years ago

I think lowering it is ok but going too low adds risks for stuck txs. It is not only the users risk but extended to any trade peer as unconfirmed inputs are ok to be used but if they never get confirmed because of too low fees the trade for both traders end up as failed and both need to do a SPV resync which is a bit painful user experience. So it is a bit different to a normal wallet where in the worst case the user need to re-send a tx. I guess a range of 3-5 sat should be ok.

GordianLN commented 2 years ago

We are talking withdrawal fees in this topic, after trade has been concluded and you send your funds to private wallet, so 1sat or 2sat per vByte makes no difference at all, doesn't involve trades nor trade peers, and is a hardcoded limitation that I fail to understand.

Regarding trades miner fees, YES, they could be cheaper indeed. I almost intended to open another proposal for those as well, in the same range that you suggested, but I suppose for the trade's smooth operation, overspending is better than the risk of the trade going stale... something could be worked out though.

chimp1984 commented 2 years ago

But the change outputs of any withdrawal can be used as inputs for a trade, thus affecting another trader.

pazza83 commented 2 years ago

But the change outputs of any withdrawal can be used as inputs for a trade, thus affecting another trader.

Many thanks for the explanation. Makes sense,

Would it be possible to reserve the btc the moment they are attempted to be withdrawn to prevent them being used in subsequent trades?

GordianLN commented 2 years ago

True, albeit I find it far fetched as I'd think someone would be interested in withdrawing only whole utxo's, and then send trade deposits from their external wallet. In any case, 1sat vs 2sat is not the deciding point of a confirmed transaction vs one in limbo, only sure thing is that you're saving half of the fees... choice should be left to the user, I think it would be fair to those who know what they are doing, that they are not impaired by a decision made to protect inexperienced users from themselves

GordianLN commented 2 years ago

Would it be possible to reserve the btc the moment they are attempted to be withdrawn to prevent them being used in subsequent trades?

internal wallet should definitely be able to prevent spending unconfirmed utxo's to fund new trades

chimp1984 commented 2 years ago

Would it be possible to reserve the btc the moment they are attempted to be withdrawn to prevent them being used in subsequent trades?

internal wallet should definitely be able to prevent spending unconfirmed utxo's to fund new trades

That would decrease usability a lot. Much worse impace than to pay 20 cents instead of 5 cents on miner fees.

Just looked up a random tx. 5 sat is about 50 USD cents atm. So I think we are discussing nothingburgers here.... https://mempool.space/tx/e19a5fce774e8ea0566d446a067174f5a70ff5f7d9ab1e40a7fa1a09753e5f65

The problems when a trade tx gets stuck to loose weeks until the issue is clear and resolved and SPV resync is done, which can take quite some time with old and heavy wallets is far worse than to over pay a few cents. Also support costs are considerable in such times.

Bisq has experience such events in the past when we used other (bad) fee estimation services and when fees have ben spiking fast many trade got stuck. It has been messy situation over weeks and many users got frustrated and probably left Bisq after such an experience. To make it more clear what happens:

So thats whats at risk when we go too low...

Liisachan commented 2 years ago

But the change outputs of any withdrawal can be used as inputs for a trade, thus affecting another trader.

Correct me if I'm wrong but if that is allowed, the exact same problem can happen already, when one sends BTC with 1 sat/vB from another non-Bisq wallet to Bisq and use it for trading before confirmations. Also, if 1 sat could cause a problem, 2 sats (already allowed) can cause similar problems too. True, when mempool is kept super-crowded for a long time, 1 sat would never work. But in such a situation, 2 (or even 10) sats also might be too low. On the other hand, if mempool is empty, a tx with a 1 sat fee will be confirmed quickly perhaps within 10 minutes.

This is a custom option disabled by default, usable only when a user ticks a checkbox. If a user manually enables an advanced option, usually they know what they are doing. Maybe they're simply sending BTC between their own Bisq and non-Bisq wallets, thinking they won't mind even if it takes days. Plus, such a cost-conscious user is likely to check mempool before doing that.

I'd like to believe that Bisq users, being privacy-aware, tend to be careful and thoughtful. I'd never even think about using a fund that is not yet confirmed for trading, partially because there would be penalty if things go wrong. But admittedly, there might be careless users or innocent mistakes, and so it might be safer for the devs to assume that every user is like a stupid kid. Either way, allowing 2 sats and allowing 1 sat seem the same difference:

So the bottom line is "whichever"... until someday RBF is implemented in Bisq. Just my two sats :)

wiz commented 2 years ago

Hi there,

The minimum transaction fee is dynamically set for all Bisq nodes by the Bisq price servers once per minute. It is calculated by multiplying the "minimum fee" from mempool.space by 2, in order to avoid transactions being rejected or purged by the Bitcoin network in the event of a congested mempool. This works very well while the mempool is full, and when the mempool is empty it drops down to 2 sat/vB which is a reasonable minimum to keep things flowing smoothly. Quite often users would make large withdrawal transactions that consolidate all of their UTXOs at 1 sat/vB and because of CPFP effective rate calculation it could cause other transactions to have an effective fee rate of less than half of what was intended. In the future, Bisq could utilize the new CPFP effective fee rate calculation API we developed to optimize this, but for now the current system works well and I'd be against changing it just to save a few sats. And of course, if you are truly a hardcore 1 sat/vB maximalist then you're always welcome to load your seed words into electrum or another wallet and spend from there using 1 sat/vB but you're on your then if you get your transactions stuck :)

GordianLN commented 2 years ago

People spent probably a few cumulative hours of human time to discuss the issue of 1sat vs 2sat, while actually implementing the change in the code would have taken less than 5 minutes.

I beg to differ from wiz, the withdraw minimum custom fee is not set to double the mempool's suggested (probably you meant the trade miner fee?) I have had, and successfully took, the option of withdrawing funds at 2sat/vByte when the mempool block backlog was about 15 units. It's a hardcoded 2sats value in the source. One developer needs to go to that line, delete 2 and write 1... and then I'd be able to account myself responsible for my own money without doing officially-non-recommended seed import on an external wallet software (that would take time and defeat the purpose of saving on fees, since time has a cost, too, see above). That mempool.space tag that tells me "overpaid 2x" really stings, that's how I am, so sue me.

One day 1sat vs 2sat will mean 1 dollar more, not 10c.

Conza88 commented 2 years ago

Will bite my tongue re: save another rant, but allow the individual to control their own funds.

Give warnings, educate, remove mediation possibilities/escalations after properly indicating the risks etc etc. But allow FREEDOM OF CHOICE, I mean gawd damn.

cd2357 commented 2 years ago

There were periods when the min fee was 1sat/vB and when the mempool filled up for a few weeks, it caused countless issues with failed trades, DAO voting, BSQ compensation, support tickets, etc. People complaining

Many of us have spent a lot of time to optimize and minimize the mining fees (and overall trading fees) where possible:

So it is an ongoing balancing act. Its not just "devs go find the line, edit, save, done".

My personal opinion: before asking for a code change, it might be worth it to first look for easier / more profitable / less disruptive ways to make up for the 1 sat/vB difference in withdrawal mining fees:

GordianLN commented 2 years ago

Thank you for the detailed reply, I am on point for each bullet of that last list :) To let me get this straight: letting users go down to 1sat/vB fee when withdrawing funds from Bisq wallet to private wallet could be a problem because, if they then go and spend those unconfirmed UTXO's to start a new trade, it might mean a big headache if mempool fills up suddenly. And this won't happen by paying 2sat/vByte instead?

All the while, the miner fee is usually hefty on trade opens, so the effective fee rate ends up being higher than what you originally set anyway.

chimp1984 commented 2 years ago

until someday RBF is implemented in Bisq.

BitcoinJ has not implemented it and Bisq use BitcoinJ. Beside that it would not help for trade transactions as they are created interactively by both traders. Thus a RBF tx would required to re-do the trade process and as it cannot be assumed that both peers are online at the same time after the trade this is not feasible to do.

10 sat might be too high, I think reducing min. fee to 5 sat might be safe IMO.

Going much lower to 1-3 sat are not worth the risk as a fee spike can lead to many failed trades. It is not only damage for the involved user who caused it by trying to save a few cents, but its damage to the trade peer and add costs for Bisq support and cause reputation damage for Bisq (not every user will understand the complex reasons).

And it can be even worse as described above. When we had last time that fee spike with many failed trades, there have been a few power users how had a long chain of such transactions and polluted othere traders by that. This continued long after the fee spike. It was a nightmare. Damage for all involved was huge and I guess we lost quite some users in that time. Support costs have been considerable and it required also lot of dev support. So would estimate just that costs to about 10k USD.

So lets not play with fire after getting burnt several times in the past. Bisq is a complex collaborative system and not a single user model. Your savings can result in costs for others. Your risk appetite might cause damage to others.

GordianLN commented 2 years ago

I think you are still talking about trade fees while I am talking about withdrawing my own funds to my own wallet and being able to choose my own fee, be it even 1sat/vB, being totally fine to get it after a week, if ever. I could do CPFP if I really need it, but let me get down to 1sat/vB when withdrawing to my own wallet, and remove the 2sat/vB limitation please.

chimp1984 commented 2 years ago

You seem to ignore my comment that a change output of a withdrawal can be used for the next offer/trade and thus affect other users. Sure there can be the isolated single user case but most users are not aware of the details (like change). Requireing confirmation before using funds for offers/trades would decrease UX a lot, so thats our of question and was also never a problem, beside the cases when txs got stuck because of too low fees.

pazza83 commented 2 years ago

Having read the comments about the risks of low fees for withdrawals I am giving this proposal a thumbs down. I a a big fan of low fees and the ability to transfer out sats at a miner fee of your choosing, but not when it will potentially impact subsequent trades negatively impact the experience of other users.

Still think it would be good in the long run to look at ways to reduce miner fees on trades and withdrawals.

GordianLN commented 2 years ago

You seem to ignore my comment that a change output of a withdrawal can be used for the next offer/trade and thus affect other users. Sure there can be the isolated single user case but most users are not aware of the details (like change). Requireing confirmation before using funds for offers/trades would decrease UX a lot, so thats our of question and was also never a problem, beside the cases when txs got stuck because of too low fees.

I wasn't actually ignoring this peculiar use case, rather placing it in its context, which is in fact peculiar: someone withdrawing funds to external wallet by using just part of a UTXO, and spending the unconfirmed change to make/take another trade... even if withdraw fees were not the issue at hand, it seems curious to even let users do that in the first place (spending unconfirmed UTXO on trade deposit) while, in order to let users do exactly that, you don't let them withdraw their funds at the go-to fee rate instead.

I hope this dilemma will be sorted out in the near future as it sounds a bit concerning to me, past the merits themselves (or lack thereof) of saving 1sat/vB on withdraw fees: it's cool that you can make offers even before deposit tx is confirmed, but using unconfirmed parent on top of that? hmmm

chimp1984 commented 2 years ago

To use unconfirmed inputs for the trade has no security issues as a doublespend would render the whole trade txs invalid. The usability costs to need to wait for a confirmation when funding your wallet are much higher than the benefit to let users choose minimal miner fees in withdrawals and require them then to wait for confirmations of change outputs to avoid the risk that it leads to failed trades.

Liisachan commented 2 years ago

Thank you very much. This was very educational and though-provoking. Some people might be a bit unhappy about this conclusion, but I believe that every user is strongly supporting the fundamental philosophy of Bisq, and thus basically deeply respecting and thankful for those who made this platform possible, especially active developers :) I hope there will be no hard feelings for anyone.

After all this is just a 1-sat difference, not realistically a big deal at all (maybe one can save more by just turning off their PC for a few hours... electric bills and such).

From what I have (poorly) understood, there might be potential problems/weakness due to hidden complexity and the "sometimes user experience is more important than safety" design principle. However, Bisq is working fine now and as they say "don't fix what is not broken." I guess basically that's the bottom line here (at least for now). This proposal, even if not accepted, was/is a good one, the not-so-simple situation being clarified because of it. Thanks again!

pazza83 commented 2 years ago

Hi, I will look to close this issue in 4 weeks or so. Please feel free to add any comments or give a thumbs up or down in support of the proposal.

GordianLN commented 2 years ago

Watching mempool.space chugging along now I just say, it comments itself, or rather, screams a comment in favor of my proposal :) I understand this is minor, as trading 0.01btc and being peeved by 141sats more to withdraw is not a game changer. I also understand the reasons behind this decision by the devs, as explained above. I don't share the conviction that 2sat/vB vs 1sat/vB would be able to save the day in the end, I bet 2sat/vB back in april would have gotten your funds locked in mempool just as bad... so are we going to lock customizable minimum to 10sat/vB just in case that happens again? (I don't think it will, with Lightning and all)

I'd say, with the previous argumentnin mind, implementing RBF and/or CPFP in Bisq would be a way to cover for any "surprises" in the future, for the sake of safety alone. And then, it would allow to enable down to 1sat/vB.

Or (should I open another issue/proposal/question about it?) it might be a nice idea to officially resize the "FUD" about loading Bisq wallet into another wallet to manage the fees for withdrawal yourself, while reading the wiki it is multiple times unadvised to load the keys in another wallet because it might have bad consequences. Maybe compile a guideline to "load bisq wallet into external wallet, and spend from it, in a safe way, without messing anything"

pazza83 commented 2 years ago

Watching mempool.space chugging along now I just say, it comments itself, or rather, screams a comment in favor of my proposal :)

Yes, understood. From my perspective I would like mining fees on trades to be lower. That being said I appreciate the answers provided above about the reasons this has the potential to cause issues that affects traders.

I don't share the conviction that 2sat/vB vs 1sat/vB would be able to save the day in the end, I bet 2sat/vB back in april would have gotten your funds locked in mempool just as bad... so are we going to lock customizable minimum to 10sat/vB just in case that happens again? (I don't think it will, with Lightning and all).

Yes, understand the point. Anywhere the line is drawn could have the same issues.

I'd say, with the previous argumentnin mind, implementing RBF and/or CPFP in Bisq would be a way to cover for any "surprises" in the future, for the sake of safety alone. And then, it would allow to enable down to 1sat/vB.

This could be another proposal. If accepted it could lead to a different outcome for 1 sat vb withdrawals.

VlVEK commented 2 years ago

this thread is interesting and critical at the same time if we are expecting the price of bitcoin to only go up

I appreciate these efforts being done in the past to arrive at a consensus

Many of us have spent a lot of time to optimize and minimize the mining fees (and overall trading fees) where possible:

  • switched from earn.com to mempool.space fee estimation
  • ongoing efforts to reduce trading protocol from 3 on-chain to 1 on-chain transactions
  • year-long efforts, backed by generous donors, to fund custom dev work to fully enable segwit
  • tweaking of fee estimation at different stages of the trade protocol, to ensure trade is reliable, but to not overpay
  • and countless more

The ways highlighted by @cd2357 are indeed useful to reduce the overall transaction fees

My personal opinion: before asking for a code change, it might be worth it to first look for easier / more profitable / less disruptive ways to make up for the 1 sat/vB difference in withdrawal mining fees:

  • for all your trades, pay the trading fees in BSQ instead of BTC (about 50% savings)
  • become a market maker, instead of a taker (those who create offers pay much smaller trading fees)
  • try to create trade offers when the mempool is free (lower estimated mining fees for both trade participants)
  • instead of many trades with small amounts, go for fewer trades with higher amounts

Here's a calculation for 0.00100000 BTC trade (average expected trade in BTC/INR) using the above ways suggested

  1. deposit transaction from external wallet of maker at 1 sat/byte = 0.00000145 BTC
  2. trade fees for maker 0.03 BSQ = 0.00000100 BTC / trade fee in BTC = 0.00005000 BTC
  3. mining fees for maker = 0.00002000 (appx at the minimum of 10 sat/vbyte)
  4. deposit transaction from external wallet of taker at 1 sat/byte = 0.00000145 BTC
  5. trade fees for taker 0.03 BSQ = 0.00000100 BTC / trade fee in BTC = 0.00005000 BTC
  6. mining fees for taker = 0.00007000 (appx at the minimum of 10 sat/vbyte)
  7. withdrawal transaction for maker = 0.00000220 (at 2 sat/vbyte)
  8. withdrawal transaction for taker = 0.00000220 (at 2 sat/vbyte)

summary with trade fees in BSQ: total maker fees = 0.00002465 (2.5% of trade amount) total taker fees = 0.00007465 (7.5% of trade amount) total fees = 0.00009930 (10% of trade amount of 0.001 BTC)

summary with trade fees in BTC total maker fees = 0.00007365 (7.5% of trade amount) total taker fees = 0.00012365 (12.5% of trade amount) total fees = 0.00019730 (20% of trade amount of 0.001 BTC)

the elephant here is not the withdrawal fees at 2 sat/vbyte but the minimum mining fees at 10 sat/vbyte - let's find out ways to address this elephant

suggested ways:

  1. i understand there are ongoing efforts to reduce trading protocol from 3 on-chain to 1 on-chain transactions
  2. when the mempool is below 10 sat/vbyte can we reduce the minimum trade fee to 2 sat/vbyte the way it is for withdrawals?
  3. can we have an option for fast & slow trades where the maker creates a slower trade with 1X minimum mempool fees or a faster trade with 2X of minimum mempool fees as highlighted by @wiz?
  4. there is a discussion on using RBF & CPFP [bisq-network/bisq/discussions/5890] however i'm personally not in favour of using RBF as it is prone to misuse & unnecessary disputes.
jkciw commented 2 years ago

I agree with @VlVEK about the maker being able to publish offers with a fee threshold (Fast vs Slow) or (1x vs 2x) etc. Hope someone is able to delineate the implications of such a setup.

chimp1984 commented 2 years ago

I think just the value of work time and effort spent on that proposal exceeds already the potential savings for the few who really want this. Not counting in potential problems to other traders and mediation/arbitration support. As state elsewhere its more complex as the people proposing this are willing or able to understand. I don't want to repeat myself as it was discussed in length at the discussion page.

I would demand a DAO voting for that proposal if it would get enough support by up votes to be considered to be implemented.

pazza83 commented 2 years ago

Hi @asvdf, thanks for opening this discussion.

I am closing this as rejected due to potential issues that could be caused for users with 1 sat vb withdrawals / trades.

wiz commented 2 years ago

wiz commented on Oct 29, 2021

The minimum transaction fee is dynamically set for all Bisq nodes by the Bisq price servers once per minute. It is calculated by multiplying the "minimum fee" from mempool.space by 2, in order to avoid transactions being rejected or purged by the Bitcoin network in the event of a congested mempool. This works very well while the mempool is full, and when the mempool is empty it drops down to 2 sat/vB which is a reasonable minimum to keep things flowing smoothly. Quite often users would make large withdrawal transactions that consolidate all of their UTXOs at 1 sat/vB and because of CPFP effective rate calculation it could cause other transactions to have an effective fee rate of less than half of what was intended. In the future, Bisq could utilize the new CPFP effective fee rate calculation API we developed to optimize this, but for now the current system works well and I'd be against changing it just to save a few sats. And of course, if you are truly a hardcore 1 sat/vB maximalist then you're always welcome to load your seed words into electrum or another wallet and spend from there using 1 sat/vB but you're on your then if you get your transactions stuck :)

In response to your feedback, we've recently added a new "no priority" fee rate suggestion on mempool.space. The way it works is very similar to the current mechanism I described above in the Bisq pricenodes, using 2x the "minimum fee", however in cases where the mempool is nearly completely empty it will suggest the actual minimum fee of 1 sat/vByte.

For example when there are 3 or less blocks full of transactions:

Screen Shot 2022-06-06 at 22 45 56

But when there are > 3 blocks full of transactions, it becomes 2x the minimum fee, which in this case is 2 sat/vByte:

Screen Shot 2022-06-06 at 21 12 01

So I would propose we change the Bisq pricenodes to use this new economyFee rate now available on https://mempool.space/api/v1/fees/recommended - if we have a rough consensus from @chimp1984 and the other developers I would ask @jmacxx to implement this simple change in the Bisq pricenode code and have @Emzy coordinate with the pricenode operators to upgrade.

chimp1984 commented 2 years ago

Sounds ok for me.