On 2023-10-20 14:09, Peter Todd via bitcoin-dev wrote:
The basic problem here is after the HTLC-timeout path becomes
spendable, the
HTLC-preimage path remains spendable. That's bad, because in this case
we want
spending the HTLC-preimage - if possible - to have an urgency attached
to it to
ensure that it happens before the previous HTLC-timeout is mined.
So, why can't we make the HTLC-preimage path expire?
If the goal is to ensure the HTLC-preimage should be mined before an
upstream HTLC-timeout becomes mineable, then I don't think a consensus
change is required. We can just make the HTLC-preimage claimable by
anyone some time after the HTLC-timeout becomes mineable.
For example, imagine that Alice offers Bob an HTLC with a timeout at
block t+200. Bob offers Carol an HTLC with a timeout at block t+100.
The Bob-Carol HTLC script looks like this:
If
# Does someone have the preimage?
Hash <digest> EqualVerify
If
# Carol has the preimage at any time
<Carol key> CheckSig
Else
# Anyone else has the preimage after t+150
<t+150> CLTV
EndIf
Else
# Bob is allowed a refund after t+100
<Bob key> CheckSigVerify
<t+100> CLTV
EndIf
In English:
- At any time, Carol can spend the output by releasing the preimage
- After t+100, Bob can spend the output
- After t+150, anyone with the preimage can spend the output
Let's consider this in the wider context of the forwarded payment
Alice->Bob->Carol:
- If Carol attempts to spend the output by releasing the preimage but
pays too low of a feerate to get it confirmed by block t+100, Bob can
spend the output in block t+101. He then has 99 blocks to settle
(revoke) the Alice-Bob HTLC offchain.
- If Carol releases the preimage to the network in general but prevents
Bob from using it (e.g. using a replacement cycling attack), anyone who
saw the preimage can take Carol's output at t+150 and, by doing so, will
put the preimage in the block chain where Bob will learn about it.
He'll then have 49 blocks to settle (revoke) the Alice-Bob HTLC
offchain.
- (All the normal cases when the HTLC is settled offchain, or where
onchain operations occur in a timely manner)
I think that adequately satisfies the concern about the effect on LN
from replacement cycling. Looking at potential complications:
- If all miners acted together[1], they are incentivized to not mine
Carol's preimage transaction before t+150 because its fees are less than
the HTLC value they can receive at t+150. I think this level of miner
centralization would result in a general failure for LN given that
miners could be any LN user's counterparty (or bribed by a user's
counterparty). E.g., stuff like this:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/017997.html
- To allow anyone with the preimage to spend the output after t+150,
they need to know the script. For taproot, that means the t+150 tapleaf
script needs to follow a standard (e.g. a BOLT) and that any internal
merkle nodes needed to connect it to the taproot commitment need to be
shown in Carol's preimage transaction (or inferable from it or other
data).
- Classic RBF pinning of the t+150 transaction to prevent it from
confirming by block t+200 might be an issue. E.g., including it in a
400,000 weight low-feerate transaction.
- Full RBF might be required to ensure the t+150 transaction isn't sent
with a low feerate and no opt-in signal.
Deployment considerations:
- No changes are required to full nodes (no consensus change required)
- No changes are required to mining Bitcoin nodes[2]
- At least one well-connected Bitcoin relay node will need to be updated
to store preimages and related data, and to send the preimage claim
transactions. Data only needs to be kept for a rolling window of a few
thousand blocks for the LN case, bounding storage requirements. No
changes are required to other relaying Bitcoin nodes
- LN nodes will need to update to new HTLC scripts, but this should be
doable without closing/re-opening channels. Both anchor and non-anchor
channels can continue to be used
Compared to OP_EXPIRE:
- OP_EXPIRE requires consensus and policy changes; this does not
- OP_EXPIRE does not depend on special software; this depends on at
least one person running special software
Although this proposal is an alternative to Peter's proposal and is
primarily inspired by his idea, it's also a variation on a previous
suggestion of mine:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html
-Dave
[1] Perhaps under block censorship threat from a mining majority or a
sub-majority performing selfish mining.
[2] Although miners may want to consider running code that allows them
to rewrite any malleable transactions to pay themselve
_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
