Anchor Output Discussion

[nkohen]

From LDK DLC Slack channel for posterity:

@benthecarman asked:

Was thinking about anchor outputs for DLCs, @nkohen told me that @ariard and @Tibo-lg thought differently, but my understanding is that they should only be needed on the funding tx if one of the parties doesn't receive a change output, so they can CPFP to get it confirmed. Whereas for the closing tx they shouldn't be needed because you can always CPFP with your winnings and if you don't receive anything from the closing tx, then you shouldn't actually care if it gets confirmed or not.
Thoughts?

@TheBlueMatt responded:

Anchor isn’t quite sufficient to solve a whole host of relay vulnerabilities Antoine (and to some extent, I) have been researching lately, but it’s definitely required to have something the broadcasting party can use to make a commitment transaction confirm via CPFP, which may be important if your counterparty goes offline.
So, really, if you’re running a channel with a truly untrusted counterparty, you need anchor v2 + package relay. Until then, anchor is quite nice to have, in that if fees go up a bit, you may be completely unable to close your channel.
We’ll get it upstream sooner or later, then hopefully it’ll be easy to have support for it in DLC-LDK without effort :)

@Tibo-Ig responded:

If I remember our discussions correctly, I think we concluded that anchoring was not required with adaptor version since it's not possible to have a CET accepted that is not the one corresponding to the actual outcome, so your counter party cannot really do anything. I think the concern was with non-adaptor version, and I don't remember exactly how the attack we discussed with Antoine worked, but I think it was something like your counter party would use some bad CETs to prevent the correct one to get accepted. (That is for basic DLCs, not thinking about channels).

@ariard responded:

Since then, I thought more, if you offer a refunding transaction with your DLC that's a source of concern. That said I think it's less vulnerable than Lightning if you go onchain far before reaching the timelock, like ~50 block before (note Lightning soon 18). Ideally we want package relay which woud let any contracting application (think LN or DLC) increase unilateally feerate whatever your counterparty is doing (either irresponsive or malicious)

[ariard]

Beyond security issues, anchor output is first and foremost a tool to enable single-party fee-bumping of any counter-signed transactions in face of mempool-congestion and thus express its liquidity preferences which might not be the same than its counterparty. IMO, liquidity preferences doesn't matter for the funding transaction as funds are locked until absolute timelocks expiration (either signatures release or refund) independently of confirmation, for CET it matters more as you if you win/loose you want to get out your funds of the contract to reallocate them as quickly as you can instead of letting stuck in-flight in the mempool.

[benthecarman]

We might actually not need to specify anything for anchor outputs. No party should need an anchor output for the CET because they can just spend their winnings to themselves with CPFP. For the funding tx a user would only need one if they do not have a change output, however, the user should be able to give themselves a change output if they want by just adding an extra funding input.

[nkohen]

I believe that this is now done due to #87