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

Fix CI #10

Closed
wants to merge 13 commits into from
Closed

Fix CI #10

wants to merge 13 commits into from

Conversation

luckysori
Copy link

No description provided.

holzeis and others added 13 commits February 22, 2024 13:57
The function has a lower bound defined by a `MIN_FEE` constant, which
can only apply to full transactions.

Usually we want to calculate the weight of a whole transaction, but
sometimes we do want to calculate, for example, the weight of a
transaction output.
We should fail if a funding transaction change output cannot be
created without making a loss (cost greater than value).

Currently, this logic does not take into account how much it will cost
to spend the output. We should include that in the future.
Before this patch, the extra fee reserve was expected when building
the funding transaction, but it was not included in the target amount
that we pass to `get_utxos_for_amount`.
Before this patch, we were including the weight of the funding
transaction[^1] when calculating the `amount` that we pass to
`get_utxos_for_amount`.

This was fine, but the weight of the funding transaction directly
impacts the transaction fee that the consumer of `rust-dlc` will pay
as soon as the channel is opened on-chain. This means that, before
this patch, the bulk of the transaction fee was implicit in the amount
that the consumer was selecting coins for.

That behaviour is a bit surprising and it obfuscates the transaction
fee to be paid, which is important information to be shown to the end
user. Therefore, this patch adds a `base_weight_wu` which consumers
must use to calculate the funding transaction fee during coin
selection.

[^1]: It's not correct, but the intention was there.
Inspired by this patch[^1] in `master`.

Since in the previous patch the `FUND_TX_BASE_WEIGHT` is passed
explicit to the implementer of `get_utxos_for_amount`, we can exclude
that from the target `amount` that we pass to `get_utxos_for_amount`.

Besides the party's collateral and all the fees related to opening a
_channel_, the only thing other that we need to take into account is
the transaction fee for the CET or the refund transaction.

The base weight can be split in half between the two parties, and each
party then has to pay for their own (possible) output on the CET or
refund transaction.

When constructing the fund transaction itself, we were also forgetting
to add the `8 + 1` bytes of each CET or refund transaction party
outputs.

[^1]: p2pderivatives@c4a0f88.
We are obviously still in the LN-DLC branch, but the buffer
transaction is smaller for vanilla DLC channels.

This change is only needed because we are not back on `master`.
This won't be a problem once we move to `p2pderivatives/master`.
@luckysori luckysori self-assigned this Feb 22, 2024
Copy link

@holzeis holzeis left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks 👍 Some tests might now be failing because of the issue that should be fixed with #11

@@ -2,7 +2,7 @@

set -e

CONTRACT_TEST_FILES=("Offered" "Accepted" "Confirmed" "Confirmed1" "Signed" "Signed1" "PreClosed" "Closed")
Copy link

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

❓ Why did you remove the Offered, Accepted and Confirmed test cases?

@luckysori luckysori force-pushed the feat/display-fees-in-10101 branch 2 times, most recently from 3cc980e to 1ab4bf5 Compare March 1, 2024 05:26
@luckysori
Copy link
Author

Not a priority atm, and it was annoying.

@luckysori luckysori closed this Apr 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants