{"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-22\n📝 Original message:\nThanks for the detailed write-up on how it affects incentives and\ncentralization,\nthese are good points. I need to spend more time thinking about them.\n\nThis is one reason I suggested using independent pay-to-preimage\n\u003e transactions[1]\n\u003e\n\nWhile this works as a technical solution, I think it has some incentives\nissues too.\nIn this attack, I believe the miners that hide the preimage tx in their\nmempool have\nto be accomplice with the attacker, otherwise they would share that tx with\nsome of\ntheir peers, and some non-miner nodes would get that preimage tx and be\nable to\ngossip them off-chain (and even relay them to other mempools).\n\nIf they are actively helping the attacker, they wouldn't spend the\npay-to-preimage tx,\nunless they gain more from it than the share the attacker gives them. This\nbecomes\na simple bidding war, and the honest user will always be the losing party\nhere (the\nattacker has nothing to lose). For this reason I'm afraid it wouldn't work\nout in practice\nas well as we'd hope...what do you think? And even if the honest user wins\nthe bidding\nwar, the attack still steals money from that user; it just goes into the\nminer's pocket.\n\nBut from the perspective of a single LN node, it\n\u003e might make more sense to get the information and *not* share it\n\u003e\n\nI think it depends. If this attack becomes doable in practice and we see it\nhappening,\nLN routing nodes and service providers have a very high incentive to thwart\nthese attacks,\nbecause otherwise they'd lose their business as people would leave the\nlightning network.\n\nAs long as enough nodes think that way (with \"enough\" being a very hard to\ndefine quantity),\nthis should mitigate the attack. The only risk would be a big \"exit scam\"\nscenario, but the\ncoordination cost between all these nodes makes that scenario unlikely\n(IMHO).\n\nThanks,\nBastien\n\nLe sam. 20 juin 2020 à 12:37, David A. Harding \u003cdave at dtrt.org\u003e a écrit :\n\n\u003e On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:\n\u003e \u003e We're simply missing information, so it looks like the only good\n\u003e \u003e solution is to avoid being in that situation by having a foot in\n\u003e \u003e miners' mempools.\n\u003e\n\u003e The problem I have with that approach is that the incentive is to\n\u003e connect to the highest hashrate pools and ignore the long tail of\n\u003e smaller pools and solo miners.  If miners realize people are doing this,\n\u003e they may begin to charge for information about their mempool and the\n\u003e largest miners will likely be able to charge more money per hashrate\n\u003e than smaller miners, creating a centralization force by increasing\n\u003e existing economies of scale.\n\u003e\n\u003e Worse, information about a node's mempool is partly trusted.  A node can\n\u003e easily prove what transactions it has, but it can't prove that it\n\u003e doesn't have a certain transaction.  This implies incumbent pools with a\n\u003e long record of trustworthy behavior may be able to charge more per\n\u003e hashrate than a newer pools, creating a reputation-based centralizing\n\u003e force that pushes individual miners towards well-established pools.\n\u003e\n\u003e This is one reason I suggested using independent pay-to-preimage\n\u003e transactions[1].  Anyone who knows the preimage can mine the\n\u003e transaction, so it doesn't provide reputational advantage or direct\n\u003e economies of scale---pay-to-preimage is incentive equivalent to paying\n\u003e normal onchain transaction fees.  There is an indirect economy of\n\u003e scale---attackers are most likely to send the low-feerate\n\u003e preimage-containing transaction to just the largest pools, so small\n\u003e miners are unlikely to learn the preimage and thus unlikely to be able\n\u003e to claim the payment.  However, if the defense is effective, the attack\n\u003e should rarely happen and so this should not have a significant effect on\n\u003e mining profitability---unlike monitoring miner mempools which would have\n\u003e to be done continuously and forever.\n\u003e\n\u003e ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2]  I was\n\u003e hoping one of Bitcoin's several inventive cryptographers would come\n\u003e along and describe how someone with an adaptor signature could use that\n\u003e information to create a pubkey that could be put into a transaction with\n\u003e a second output that OP_RETURN included the serialized adaptor\n\u003e signature.  The pubkey would be designed to be spendable by anyone with\n\u003e the final signature in a way that revealed the hidden value to the\n\u003e pubkey's creator, allowing them to resolve the PTLC.  But if that's\n\u003e fundamentally not possible, I think we could advocate for making\n\u003e pay-to-revealed-adaptor-signature possible using something like\n\u003e OP_CHECKSIGFROMSTACK.[3]\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html\n\u003e [2]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html\n\u003e [3] https://bitcoinops.org/en/topics/op_checksigfromstack/\n\u003e\n\u003e \u003e Do you think it's unreasonable to expect at least some LN nodes to\n\u003e \u003e also invest in running nodes in mining pools, ensuring that they learn\n\u003e \u003e about attackers' txs and can potentially share discovered preimages\n\u003e \u003e with the network off-chain (by gossiping preimages found in the\n\u003e \u003e mempool over LN)?\n\u003e\n\u003e Ignoring my concerns about mining centralization and from the\n\u003e perspective of just the Lightning Network, that doesn't sound\n\u003e unreasonable to me.  But from the perspective of a single LN node, it\n\u003e might make more sense to get the information and *not* share it,\n\u003e increasing your security and allowing you to charge lower routing fees\n\u003e compared to your competitors.  This effect would only be enhanced if\n\u003e miners charged for their mempool contents (indeed, to maximize their\n\u003e revenue, miners might require that their mempool subscribers don't share\n\u003e the information---which they could trivially enforce by occasionally\n\u003e sending subscribers a preimage specific to the subscriber and seeing if\n\u003e it propagated to the public network).\n\u003e\n\u003e \u003e I think that these recent attacks show that we need (at least some)\n\u003e \u003e off-chain nodes to be somewhat heavily invested in on-chain operations\n\u003e \u003e (layers can't be fully decoupled with the current security assumptions\n\u003e \u003e - maybe Eltoo will help change that in the future?).\n\u003e\n\u003e I don't see how eltoo helps.  Eltoo helps ensure you reach the final\n\u003e channel state, but this problem involves an abuse of that final state.\n\u003e\n\u003e -Dave\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200622/09e39b02/attachment-0001.html\u003e"}