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

Add metrics to interactive-tx funding #2997

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

pm47
Copy link
Member

@pm47 pm47 commented Feb 5, 2025

On funding amount/change, and on actual vs expected mining fee when selling liquidity.

On funding amount/change, and on actual vs expected mining fee when selling liquidity.
@pm47 pm47 requested a review from t-bast February 5, 2025 16:45
Comment on lines +67 to +74
/**
* Record actual vs estimated mining fee
*/
def recordInteractiveTxMiningFeeDiff(userMiningFee: Satoshi, actualMiningFee: Satoshi): Unit = {
// If actual mining fee is greater than what the user paid, we lose money
val diff = userMiningFee - actualMiningFee
Metrics.InteractiveTxMiningFeeDiff.withTag(Tags.DiffSign, if (diff > 0.sat) Tags.DiffSigns.plus else Tags.DiffSigns.minus).record(Math.abs(diff.toLong))
}
Copy link
Member

Choose a reason for hiding this comment

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

This is confusing: it's very specific to liquidity ads but without knowing this beforehand, it's really hard to figure out from the code. More generally, I think we should also add liquidity ads metrics in this PR:

  • amount purchased
  • service fee paid/received
  • mining fee refunded

That's where it would make sense to have this metric, which should be renamed LiquidityAdsMiningFeeRefund. The userMiningFee parameter from this function should be renamed refundedMiningFee IMO.

Comment on lines +888 to +891
// Liquidity requestor will pay the mining fee for the raw splice tx with a negative funding contribution, on top of that we add the mining fee for our inputs bring liquidity
val userMiningFee = -fundingParams.remoteContribution + p.fees.miningFee
log.info("funding fee check: serviceFee={} userMiningFee={} actualMiningFee={}", p.fees.serviceFee, userMiningFee, signedTx.tx.fees)
Metrics.recordInteractiveTxMiningFeeDiff(userMiningFee, signedTx.tx.fees)
Copy link
Member

Choose a reason for hiding this comment

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

I think that's incorrect? We should compute this by doing signedTx.tx.localFees - p.fees.miningFee? Or maybe the end result is the same, but it's less clear what we're computing, since we don't really care about the mining fee they're paying from their channel balance, the only thing we care about is comparing how much mining fees we paid compared to how much they're refunding as part of the liquidity purchase?

Metrics.recordInteractiveTxFunding(
targetAmount = fundingParams.localContribution,
inputsCount = result.tx.txIn.size - txNotFunded.txIn.size,
change = result.changePosition.map(i => result.tx.txOut(i).amount).sum)
Copy link
Member

Choose a reason for hiding this comment

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

I don't think this is the right place for this metric: since we have a mechanism to filter inputs below and retry calling bitcoind if it inserted inputs that cannot be used for dual funding, we may incorrectly increment the metric multiple times for the same funding attempt.

I think this should be done in filterInputs before returning the result to the caller, around those lines:

// We unlock the unusable inputs (if any) as they can be used outside of interactive-tx sessions.
sendResultAndStop(fundingContributions, unusableInputs.map(_.outpoint))

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