-
Notifications
You must be signed in to change notification settings - Fork 0
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
Fix CI #10
Conversation
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`.
There was a problem hiding this 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") |
There was a problem hiding this comment.
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?
3cc980e
to
1ab4bf5
Compare
Not a priority atm, and it was annoying. |
No description provided.