{"type":"rich","version":"1.0","author_name":"npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","author_url":"https://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrd","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2020-06-20\n📝 Original message:\nOn Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote:\n\u003e We're simply missing information, so it looks like the only good\n\u003e solution is to avoid being in that situation by having a foot in\n\u003e miners' mempools.\n\nThe problem I have with that approach is that the incentive is to\nconnect to the highest hashrate pools and ignore the long tail of\nsmaller pools and solo miners.  If miners realize people are doing this,\nthey may begin to charge for information about their mempool and the\nlargest miners will likely be able to charge more money per hashrate\nthan smaller miners, creating a centralization force by increasing\nexisting economies of scale.\n\nWorse, information about a node's mempool is partly trusted.  A node can\neasily prove what transactions it has, but it can't prove that it\ndoesn't have a certain transaction.  This implies incumbent pools with a\nlong record of trustworthy behavior may be able to charge more per\nhashrate than a newer pools, creating a reputation-based centralizing\nforce that pushes individual miners towards well-established pools.\n\nThis is one reason I suggested using independent pay-to-preimage\ntransactions[1].  Anyone who knows the preimage can mine the\ntransaction, so it doesn't provide reputational advantage or direct\neconomies of scale---pay-to-preimage is incentive equivalent to paying\nnormal onchain transaction fees.  There is an indirect economy of\nscale---attackers are most likely to send the low-feerate\npreimage-containing transaction to just the largest pools, so small\nminers are unlikely to learn the preimage and thus unlikely to be able\nto claim the payment.  However, if the defense is effective, the attack\nshould rarely happen and so this should not have a significant effect on\nmining profitability---unlike monitoring miner mempools which would have\nto be done continuously and forever.\n\nZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2]  I was\nhoping one of Bitcoin's several inventive cryptographers would come\nalong and describe how someone with an adaptor signature could use that\ninformation to create a pubkey that could be put into a transaction with\na second output that OP_RETURN included the serialized adaptor\nsignature.  The pubkey would be designed to be spendable by anyone with\nthe final signature in a way that revealed the hidden value to the\npubkey's creator, allowing them to resolve the PTLC.  But if that's\nfundamentally not possible, I think we could advocate for making\npay-to-revealed-adaptor-signature possible using something like\nOP_CHECKSIGFROMSTACK.[3]\n\n[1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html\n[2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html\n[3] https://bitcoinops.org/en/topics/op_checksigfromstack/\n\n\u003e Do you think it's unreasonable to expect at least some LN nodes to\n\u003e also invest in running nodes in mining pools, ensuring that they learn\n\u003e about attackers' txs and can potentially share discovered preimages\n\u003e with the network off-chain (by gossiping preimages found in the\n\u003e mempool over LN)?\n\nIgnoring my concerns about mining centralization and from the\nperspective of just the Lightning Network, that doesn't sound\nunreasonable to me.  But from the perspective of a single LN node, it\nmight make more sense to get the information and *not* share it,\nincreasing your security and allowing you to charge lower routing fees\ncompared to your competitors.  This effect would only be enhanced if\nminers charged for their mempool contents (indeed, to maximize their\nrevenue, miners might require that their mempool subscribers don't share\nthe information---which they could trivially enforce by occasionally\nsending subscribers a preimage specific to the subscriber and seeing if\nit propagated to the public network).\n\n\u003e I think that these recent attacks show that we need (at least some)\n\u003e off-chain nodes to be somewhat heavily invested in on-chain operations\n\u003e (layers can't be fully decoupled with the current security assumptions\n\u003e - maybe Eltoo will help change that in the future?).\n\nI don't see how eltoo helps.  Eltoo helps ensure you reach the final\nchannel state, but this problem involves an abuse of that final state.\n\n-Dave\n-------------- next part --------------\nA non-text attachment was scrubbed...\nName: signature.asc\nType: application/pgp-signature\nSize: 833 bytes\nDesc: not available\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200620/6085153a/attachment-0001.sig\u003e"}