Add imbued v3 based on template-matching #29427
Conversation
This attempts to imbue v3 semantics on transactions spending outputs from a transaction that looks like a LN commitment transaction.
|
The following sections might be updated with supplementary metadata relevant to reviewers and maintainers. Code CoverageFor detailed information about the code coverage, see the test coverage report. ReviewsSee the guideline for information on the review process. ConflictsReviewers, this pull request conflicts with the following ones:
If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first. |
|
one design feedback, look on how any imbuance mechanism would have to fit with dynamic upgrades, whatever the bitcoin use-cases. especially matters for time-sensitive flows: lightning/bolts#1117 |
|
can you precise where the imbuance mechanism should be applied? like in hardcoding a template in the imbuance mechanism is a dumb idea even for today Lightning, the “must have exactly 2 330-satoshi outputs” i can just add another HTLC p2wsh 330 sats and your template is broken. |
|
If the design goal of this imbuance mechanism is to apply "novel" transaction-relay policy in a backward fashion on pre-signed transactions in the context of multi-party applications and contracting protocols, I think there should be a cryptographic opt-in of one of the transaction issuer itself. I think the template approach is a dead-end as not only in practice each multi-party applications and contracting protocols have inherent malleability affecting the chain of transaction (amounts, scriptpubkeys types, inputs / outputs ordering), though even when there is a standard, each implementation and operations are applying their own policy. E.g for lightning on the lowest-value HTLC accepted, which is loosely documented (cf. Even assuming a standadization of the source of commitment transaction malleability on the LN-side, there is no certainty that old off-chain commitment transaction cannot be used to neutralize the pinning risk low reduction brought by v3. The only way to invalidate old state (in a no eltoo world) is an on-chain operation. I think a better imbuance approach is a new p2p extension, e.g The Such more generic imbuance mechanism could be deployed on top of bip331 package-relay by upgrading the version number of |
|
🐙 This pull request conflicts with the target branch and needs rebase. |
|
⌛ There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
I believe @ariard is correct: anchor-style commitment transactions can additionally have 330-sat HTLC outputs. |
|
⌛ There hasn't been much activity lately and the patch still needs rebase. What is the status here?
|
|
I believe this PR is no longer relevant, so closing for now. |
This attempts to imbue v3 semantics on transactions spending outputs from a transaction that looks like a LN commitment transaction.
Opening this as a draft now so that LN folks can see what this would look like, and concept ACK/NACK as appropriate. If we want to go down this route, I can add tests and comments indicating that this behavior should be deprecated at some point in the future.
See #29319 for context, and I wrote up a summary of some statistics I gathered from analyzing data from 2023 here.