Readers of this list can probably directly skip to the "Future work" section. I believe my
"alternative proposal" should loosely reflect Matt's proposal from the very first mail of this
thread; note that I included anchors and new txs only in some places, as I think they aren't
necessary everywhere.

My current state-of-mind (subject to change as I discover more potential attacks) is that:

* The proposal to add more anchors and pre-signed txs adds non-negligible complexity and hurts
small HTLCs, so it would be better if we didn't need it
* The blind CPFP carve-out trick is a one shot, so you'll likely need to pay a lot of fees for it
to work which still makes you lose money in case an attacker targets you (but the money goes to
miners, not to the attacker - unless he is the miner). It's potentially hard to estimate what fee
you should put into that blind CPFP carve-out because you have no idea what the current fee of the
pinned success transaction package is, so it's unsure if that solution will really work in practice
* If we take a step back, the only attack we need to protect against is an attacker pinning a
preimage transaction while preventing us from learning that preimage for at least `N` blocks
(see the gist for the complete explanation). Please correct me if that claim is incorrect as it
will invalidate my conclusion! Thus if we have:
* a high enough `cltv_expiry_delta`
* [off-chain preimage broadcast](https://github.com/lightningnetwork/lightning-rfc/issues/783)
(or David's proposal to do it by sending txs that can be redeemed via only the preimage)
* LN hubs (or any party commercially investing in running a lightning node) participating in
various mining pools to help discover preimages
* decent mitigations for eclipse attacks
* then the official anchor outputs proposal should be safe enough and is much simpler?

Thank you for reading, I hope the work I put into this gist will be useful for some of you.

Bastien