feat(trading-proto-upgrade): fees fixes among other things#2109
feat(trading-proto-upgrade): fees fixes among other things#2109mariocynicys wants to merge 44 commits intodevfrom
Conversation
|
@mariocynicys please add label for if this is under review or in progress. |
|
@mariocynicys please merge dev to feature branch as it contains build fixes |
fdd2451 to
a9dbd14
Compare
| // FIXME: I am lost here, is this the fee for funding spend or taker payment spend? | ||
| // if it's the former, where is the fee for the the taker payment spend? | ||
| let taker_payment_spend_trade_fee = match state_machine.taker_coin.get_receiver_trade_fee(stage).compat().await | ||
| { |
There was a problem hiding this comment.
This is the fee paid by the receiver of a payment, it was an htlc spend fee in the legacy swap protocol. For v2, it should be 0 for maker like we agreed before (but maybe not in this PR, and we make it the taker payment spend fee for now), and for taker it should be the fee needed to spend the maker payment which is the same as the legacy protocol. Is this clear enough?
https://github.com/KomodoPlatform/komodo-defi-framework/blob/3c888aaf513eefe6ffbc99a6f2320dfe566223cb/mm2src/coins/lp_coins.rs#L3102-L3103
There was a problem hiding this comment.
and for taker it should be the fee needed to spend the maker payment which is the same as the legacy protocol.
As discussed in DM with @mariocynicys, this should be different than legacy protocol too since the redeem script is a bit different due to the immediate refund path. I will make this in progress again @mariocynicys
Actually should be called funding spend fee or taker payment fee, but we are just following the current code naming at the moment. The negotiation goes as follows: 1- Taker and maker each decide how much this fee should be at the beginning of the swap. 2- The taker will send the maker their proposed fee during negotiation, if the maker deems the fee as low enough (less than 90% of the maker's own calculated fee), they will refuse to trade before the trade starts. Otherwise, they will continue and use this fee for validation later. 3- The maker will validate that the taker has accounted for this fee in the funding transaction. 4- The taker will validate that the taker payment preimage (generated by the maker) uses the negotiated fee or greater (greater number will deduct from the maker's trading volume anyway). If not, the taker will stop the trade since the maker is clearly stealing funds that isn't his which might affect the completion of the swap if the fee is low.
…o u64 The big decimal might be a fraction less than zero and gets converted to zero when sent over the wire (because we send the fee as u64). Scale it properly before sending it.
noticed this in the integration tests, the fee might be a fraction so clamping it to one yields a fee higher than the actually one, thus fails the ratio check
use a signature-size dummy date instead
taker payment spend is actually taker payment here, next commit should fix the naming inconsistencies
a9dbd14 to
481ba3e
Compare
revising the commit history, looks like this was deliberate
c68b87a to
28fc442
Compare
always rename discuss markers to fixmes since i forget about them xD
there is no calculatable tx_size for other tx (non-htlc) (like funding and maker payment txs). their fees depend really on the utxos we have and whether they are segwit or not. used get_sender_trade_fee for now, though I think this method needs reviewing since its doc comment doesn't make a lot of sense
b16f050 to
bc32198
Compare
|
ps @mariocynicys this pr started to have conflicts |
|
Converted this to draft although we might need it for TPU |
The main feat here is
taker payment spend feenegotiation (I guess we will refactor namings in the swaps v2 code and rename this totaker payment fee/funding spend fee):The negotiation goes as follows:
if the maker deems the fee as low enough (less than 90% of the maker's own calculated fee),
they will refuse to trade before the trade starts. Otherwise, they
will continue and use this fee for validation later.
the funding transaction.
uses the negotiated fee or greater (greater number will deduct from the maker's trading volume anyway).
If not, the taker will stop the trade since the maker is clearly stealing funds that isn't his
which might affect the completion of the swap if the fee is low.
Proto v2 issue pool:
accept_only_fromour order peer.u8fork idrecover_funds_for_swaprpc for swaps v2test_taker_completes_swap_after_restartis flakyFixmes & discuss comments are intended to be covered in the PR.