rich1.0npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0shttps://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0snjumphttps://nostr.ae📅 Original date posted:2020-06-19 📝 Original message: Good morning list, Sorry for being (very) late to the party on that subject, but better late than never. A lot of ideas have been thrown at the problem and are scattered across emails, IRC discussions, and github issues. I've spent some time putting it all together in one gist, hoping that it will help stir the discussion forward as well as give newcomers all the background they need to ramp up on this issue and join the discussion, bringing new ideas to the table. The gist is here, and I'd appreciate your feedback if I have wrongly interpreted some of the ideas: https://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12 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 Le ven. 24 avr. 2020 à 00:47, Matt Corallo via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> a écrit : > > > On 4/23/20 8:46 AM, ZmnSCPxj wrote: > >>> - Miners, being economically rational, accept this proposal and > include this in a block. > >>> > >>> The proposal by Matt is then: > >>> > >>> - The hashlock branch should instead be: > >>> - B and C must agree, and show the preimage of some hash H (hashlock > branch). > >>> - Then B and C agree that B provides a signature spending the > hashlock branch, to a transaction with the outputs: > >>> - Normal payment to C. > >>> - Hook output to B, which B can use to CPFP this transaction. > >>> - Hook output to C, which C can use to CPFP this transaction. > >>> - B can still (somehow) not maintain a mempool, by: > >>> - B broadcasts its timelock transaction. > >>> - B tries to CPFP the above hashlock transaction. > >>> - 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. > >> > >> Note that no query is required. The problem has been solved and the > preimage-containing transaction should now confirm just fine. > > > > Ah, right, so it gets confirmed and the `blocksonly` B sees it in a > block. > > > > 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? > > Correct, once it makes it into the mempool we can CPFP it and all the > regular sub-package CPFP calculation will pick it > and its descendants up. Of course this relies on it not spending any other > unconfirmed inputs. > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev at lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200619/70e88f70/attachment.html>