The suggestion is to make the HTLC-preimage claimable by anyone some time after the HTLC-timeout becomes mineable. The example given is that if Alice offers Bob an HTLC with a timeout at block t+200, and Bob offers Carol an HTLC with a timeout at block t+100, the Bob-Carol HTLC script would allow Carol to spend the output by releasing the preimage at any time, Bob to spend the output after t+100, and anyone with the preimage to spend the output after t+150.

In the wider context of a forwarded payment from Alice to Bob to Carol, several scenarios are mentioned. If Carol tries 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. If Carol releases the preimage to the network but prevents Bob from using it, anyone who saw the preimage can take Carol's output at t+150, putting the preimage in the blockchain where Bob will learn about it. Other normal cases where the HTLC is settled offchain or onchain operations occur in a timely manner are also considered.

Regarding potential complications, if all miners acted together, they would be incentivized not to mine Carol's preimage transaction before t+150 due to lower fees compared to the HTLC value they can receive at t+150. This level of miner centralization could result in a general failure for the Lightning Network. It is noted that for taproot, the t+150 tapleaf script needs to follow a standard, and any internal merkle nodes needed to connect it to the taproot commitment should be shown in Carol's preimage transaction. Classic RBF pinning and full RBF are also mentioned as potential issues.

In terms of deployment considerations, no changes are required to full nodes or mining Bitcoin nodes. However, at least one well-connected Bitcoin relay node will need to be updated to store preimages and related data and send the preimage claim transactions. LN nodes will need to update to new HTLC scripts, but this should be doable without closing/re-opening channels.

The proposal is compared to OP_EXPIRE, noting that OP_EXPIRE requires consensus and policy changes, while this proposal does not. Additionally, OP_EXPIRE does not depend on special software, whereas this proposal requires at least one person running special software. It is mentioned that this proposal is an alternative to Peter's proposal and is also a variation on a previous suggestion made by Dave. The email ends abruptly with a mention of a sub-majority performing selfish mining to rewrite any malleable transactions to pay themselves, but it is unclear how this relates to the rest of the discussion.