{"type":"rich","version":"1.0","author_name":"npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","author_url":"https://nostr.ae/npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0s","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-06-19\n📝 Original message:\nGood morning list,\n\nSorry for being (very) late to the party on that subject, but better late\nthan never.\n\nA lot of ideas have been thrown at the problem and are scattered across\nemails, IRC discussions,\nand github issues. I've spent some time putting it all together in one\ngist, hoping that it will\nhelp stir the discussion forward as well as give newcomers all the\nbackground they need to ramp up\non this issue and join the discussion, bringing new ideas to the table.\n\nThe gist is here, and I'd appreciate your feedback if I have wrongly\ninterpreted some of the ideas:\nhttps://gist.github.com/t-bast/22320336e0816ca5578fdca4ad824d12\n\nReaders of this list can probably directly skip to the \"Future work\"\nsection. I believe my\n\"alternative proposal\" should loosely reflect Matt's proposal from the very\nfirst mail of this\nthread; note that I included anchors and new txs only in some places, as I\nthink they aren't\nnecessary everywhere.\n\nMy current state-of-mind (subject to change as I discover more potential\nattacks) is that:\n\n* The proposal to add more anchors and pre-signed txs adds non-negligible\ncomplexity and hurts\nsmall HTLCs, so it would be better if we didn't need it\n* The blind CPFP carve-out trick is a one shot, so you'll likely need to\npay a lot of fees for it\nto work which still makes you lose money in case an attacker targets you\n(but the money goes to\nminers, not to the attacker - unless he is the miner). It's potentially\nhard to estimate what fee\nyou should put into that blind CPFP carve-out because you have no idea what\nthe current fee of the\npinned success transaction package is, so it's unsure if that solution will\nreally work in practice\n* If we take a step back, the only attack we need to protect against is an\nattacker pinning a\npreimage transaction while preventing us from learning that preimage for at\nleast `N` blocks\n(see the gist for the complete explanation). Please correct me if that\nclaim is incorrect as it\nwill invalidate my conclusion! Thus if we have:\n* a high enough `cltv_expiry_delta`\n* [off-chain preimage broadcast](\nhttps://github.com/lightningnetwork/lightning-rfc/issues/783)\n(or David's proposal to do it by sending txs that can be redeemed via only\nthe preimage)\n* LN hubs (or any party commercially investing in running a lightning node)\nparticipating in\nvarious mining pools to help discover preimages\n* decent mitigations for eclipse attacks\n* then the official anchor outputs proposal should be safe enough and is\nmuch simpler?\n\nThank you for reading, I hope the work I put into this gist will be useful\nfor some of you.\n\nBastien\n\nLe ven. 24 avr. 2020 à 00:47, Matt Corallo via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e a écrit :\n\n\u003e\n\u003e\n\u003e On 4/23/20 8:46 AM, ZmnSCPxj wrote:\n\u003e \u003e\u003e\u003e -   Miners, being economically rational, accept this proposal and\n\u003e include this in a block.\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e The proposal by Matt is then:\n\u003e \u003e\u003e\u003e\n\u003e \u003e\u003e\u003e -   The hashlock branch should instead be:\n\u003e \u003e\u003e\u003e -   B and C must agree, and show the preimage of some hash H (hashlock\n\u003e branch).\n\u003e \u003e\u003e\u003e -   Then B and C agree that B provides a signature spending the\n\u003e hashlock branch, to a transaction with the outputs:\n\u003e \u003e\u003e\u003e -   Normal payment to C.\n\u003e \u003e\u003e\u003e -   Hook output to B, which B can use to CPFP this transaction.\n\u003e \u003e\u003e\u003e -   Hook output to C, which C can use to CPFP this transaction.\n\u003e \u003e\u003e\u003e -   B can still (somehow) not maintain a mempool, by:\n\u003e \u003e\u003e\u003e -   B broadcasts its timelock transaction.\n\u003e \u003e\u003e\u003e -   B tries to CPFP the above hashlock transaction.\n\u003e \u003e\u003e\u003e -   If CPFP succeeds, it means the above hashlock transaction exists\n\u003e and B queries the peer for this transaction, extracting the preimage and\n\u003e claiming the A-\u003eB HTLC.\n\u003e \u003e\u003e\n\u003e \u003e\u003e Note that no query is required. The problem has been solved and the\n\u003e preimage-containing transaction should now confirm just fine.\n\u003e \u003e\n\u003e \u003e Ah, right, so it gets confirmed and the `blocksonly` B sees it in a\n\u003e block.\n\u003e \u003e\n\u003e \u003e Even if C hooks a tree of low-fee transactions on its hook output or\n\u003e normal payment, miners will still be willing to confirm this and the B hook\n\u003e CPFP transaction without, right?\n\u003e\n\u003e Correct, once it makes it into the mempool we can CPFP it and all the\n\u003e regular sub-package CPFP calculation will pick it\n\u003e and its descendants up. Of course this relies on it not spending any other\n\u003e unconfirmed inputs.\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200619/70e88f70/attachment.html\u003e"}