Currently, when an order is triggered both parties send their amount to a timelocked address, including two types of transaction fees
fee1: the tx fee needed to submit the initial tx to the blockchain
fee2: the tx fee that will eventually be required to redeem the locked coins - ensuring each party gets the full, promised amount
Example:
If one were to send 1 LTC (trade_amount), the wallet would actually send
total = trade_amount + fee1 + fee2.
The redeeming side would then be able to claim
total = trade_amount + fee2,
while using fee2 to cover the tx costs, ending up with trade_amount in their wallet.
All of these calculations happen without any user interaction. This works fairly well as long as fee calculations are static and both parties use very similar fee settings.
When moving towards a more dynamic (estimated) fees system, certain problems arise. This ticket makes attempt to highlight some of the shortcomings of the current implementation as well as present possible solutions.
Problem:
Transaction fees are currently somewhat of a black box system. Fees are automatically calculated and added to the trading amounts without any user interaction. Consequently, the user never sees nor confirms the actual fee amounts. This works well with static tx fees as costs are fairly predictable, however it poses a problem with dynamic fees, where this is no longer the case. Dynamic fee estimations might add quite high, even ridiculous fees, aren't very reliable and shouldn't blindly be trusted.
there should be some UI element displaying the fees
user should have to confirm fees before the order is posted (or any prep tx is sent)
requires changes to the current order posting workflow
Problem:
Currently, fee1 and fee2 are calculated once during the order creation process and then never changed. Now, orders aren't necessary taken right away. In fact, a significant amount of time might pass between placing and taking an order. During that time estimated fees might drastically change leading to stuck/failed orders or to overpaid fees. In order to address this problem the client has to become more flexible when dealing with tx fees.
should reserve enough funds to cover any possible fee (might significantly change between placing and taking the order), recalculate fees when the order is triggered
should be able to handle the fact that both parties A and B might calculate very different dynamic fee rates
the implementation should be able to adjust the fee2 on the redeemer side (take from trade_amount, add to fee2, redeemer ends up with slightly less in their wallet)
allows to pay for missing fees from redeemed amount
allows to speed up the tx confirmation by increasing the fee
alternatively, redeemer could always pay the fee2, but this might lead to new problems (not enough funds, dust, etc)
the taker should always determine beforehand, if they deem the fee2 sufficient before triggering an order (would need a way of displaying this)
Additionally:
should have a max fee sanity check, fees can never exceed a certain amount (safety)
calculations should account for different address types (segwit vs legacy)
there are currently several (implicit) static fee assumptions in the code, which would need changing
an effort should be made to better consolidate things related to fee calculations into one place in the code
The above list is not complete, but has the intention to start a discussion on the topic.
Currently, when an order is triggered both parties send their amount to a timelocked address, including two types of transaction fees
Example: If one were to send 1 LTC (
trade_amount), the wallet would actually sendtotal = trade_amount + fee1 + fee2.The redeeming side would then be able to claim
total = trade_amount + fee2,while using
fee2to cover the tx costs, ending up withtrade_amountin their wallet.All of these calculations happen without any user interaction. This works fairly well as long as fee calculations are static and both parties use very similar fee settings.
When moving towards a more dynamic (estimated) fees system, certain problems arise. This ticket makes attempt to highlight some of the shortcomings of the current implementation as well as present possible solutions.
Problem: Transaction fees are currently somewhat of a black box system. Fees are automatically calculated and added to the trading amounts without any user interaction. Consequently, the user never sees nor confirms the actual fee amounts. This works well with static tx fees as costs are fairly predictable, however it poses a problem with dynamic fees, where this is no longer the case. Dynamic fee estimations might add quite high, even ridiculous fees, aren't very reliable and shouldn't blindly be trusted.
Problem: Currently,
fee1andfee2are calculated once during the order creation process and then never changed. Now, orders aren't necessary taken right away. In fact, a significant amount of time might pass between placing and taking an order. During that time estimated fees might drastically change leading to stuck/failed orders or to overpaid fees. In order to address this problem the client has to become more flexible when dealing with tx fees.fee2on the redeemer side (take fromtrade_amount, add tofee2, redeemer ends up with slightly less in their wallet)fee2, but this might lead to new problems (not enough funds, dust, etc)fee2sufficient before triggering an order (would need a way of displaying this)Additionally:
The above list is not complete, but has the intention to start a discussion on the topic.
Related: