<div dir="ltr">Good morning list,<br><br>Sorry for being (very) late to the party on that subject, but better late than never.<br><br>A lot of ideas have been thrown at the problem and are scattered across emails, IRC discussions,<br>and github issues. I've spent some time putting it all together in one gist, hoping that it will<br>help stir the discussion forward as well as give newcomers all the background they need to ramp up<br>on this issue and join the discussion, bringing new ideas to the table.<br><br>The gist is here, and I'd appreciate your feedback if I have wrongly interpreted some of the ideas:<br><a href="https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12">https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12</a><div><br>Readers of this list can probably directly skip to the "Future work" section. I believe my<br>"alternative proposal" should loosely reflect Matt's proposal from the very first mail of this<br>thread; note that I included anchors and new txs only in some places, as I think they aren't<br>necessary everywhere.<br><br>My current state-of-mind (subject to change as I discover more potential attacks) is that:<br><br>* The proposal to add more anchors and pre-signed txs adds non-negligible complexity and hurts<br>small HTLCs, so it would be better if we didn't need it<br>* The blind CPFP carve-out trick is a one shot, so you'll likely need to pay a lot of fees for it<br>to work which still makes you lose money in case an attacker targets you (but the money goes to<br>miners, not to the attacker - unless he is the miner). It's potentially hard to estimate what fee<br>you should put into that blind CPFP carve-out because you have no idea what the current fee of the<br>pinned success transaction package is, so it's unsure if that solution will really work in practice<br>* If we take a step back, the only attack we need to protect against is an attacker pinning a<br>preimage transaction while preventing us from learning that preimage for at least `N` blocks<br>(see the gist for the complete explanation). Please correct me if that claim is incorrect as it<br>will invalidate my conclusion! Thus if we have:<br>* a high enough `cltv_expiry_delta`<br>* [off-chain preimage broadcast](<a href="https://github.com/lightningnetwork/lightning-rfc/issues/783">https://github.com/lightningnetwork/lightning-rfc/issues/783</a>)<br>(or David's proposal to do it by sending txs that can be redeemed via only the preimage)<br>* LN hubs (or any party commercially investing in running a lightning node) participating in<br>various mining pools to help discover preimages<br>* decent mitigations for eclipse attacks<br>* then the official anchor outputs proposal should be safe enough and is much simpler?<br><br>Thank you for reading, I hope the work I put into this gist will be useful for some of you.<br><br>Bastien</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Le ven. 24 avr. 2020 à 00:47, Matt Corallo via bitcoin-dev <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> a écrit :<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 4/23/20 8:46 AM, ZmnSCPxj wrote:<br>
>>> -   Miners, being economically rational, accept this proposal and include this in a block.<br>
>>><br>
>>> The proposal by Matt is then:<br>
>>><br>
>>> -   The hashlock branch should instead be:<br>
>>> -   B and C must agree, and show the preimage of some hash H (hashlock branch).<br>
>>> -   Then B and C agree that B provides a signature spending the hashlock branch, to a transaction with the outputs:<br>
>>> -   Normal payment to C.<br>
>>> -   Hook output to B, which B can use to CPFP this transaction.<br>
>>> -   Hook output to C, which C can use to CPFP this transaction.<br>
>>> -   B can still (somehow) not maintain a mempool, by:<br>
>>> -   B broadcasts its timelock transaction.<br>
>>> -   B tries to CPFP the above hashlock transaction.<br>
>>> -   If CPFP succeeds, it means the above hashlock transaction exists and B queries the peer for this transaction, extracting the preimage and claiming the A->B HTLC.<br>
>><br>
>> Note that no query is required. The problem has been solved and the preimage-containing transaction should now confirm just fine.<br>
> <br>
> Ah, right, so it gets confirmed and the `blocksonly` B sees it in a block.<br>
> <br>
> Even if C hooks a tree of low-fee transactions on its hook output or normal payment, miners will still be willing to confirm this and the B hook CPFP transaction without, right?<br>
<br>
Correct, once it makes it into the mempool we can CPFP it and all the regular sub-package CPFP calculation will pick it<br>
and its descendants up. Of course this relies on it not spending any other unconfirmed inputs.<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev</a><br>
</blockquote></div>