rich1.0npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdhttps://nostr.ae/npub16dt55fpq3a8r6zpphd9xngxr46zzqs75gna9cj5vf8pknyv2d7equx4wrdnjumphttps://nostr.ae📅 Original date posted:2020-06-20 📝 Original message: On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote: > We're simply missing information, so it looks like the only good > solution is to avoid being in that situation by having a foot in > miners' mempools. The problem I have with that approach is that the incentive is to connect to the highest hashrate pools and ignore the long tail of smaller pools and solo miners. If miners realize people are doing this, they may begin to charge for information about their mempool and the largest miners will likely be able to charge more money per hashrate than smaller miners, creating a centralization force by increasing existing economies of scale. Worse, information about a node's mempool is partly trusted. A node can easily prove what transactions it has, but it can't prove that it doesn't have a certain transaction. This implies incumbent pools with a long record of trustworthy behavior may be able to charge more per hashrate than a newer pools, creating a reputation-based centralizing force that pushes individual miners towards well-established pools. This is one reason I suggested using independent pay-to-preimage transactions[1]. Anyone who knows the preimage can mine the transaction, so it doesn't provide reputational advantage or direct economies of scale---pay-to-preimage is incentive equivalent to paying normal onchain transaction fees. There is an indirect economy of scale---attackers are most likely to send the low-feerate preimage-containing transaction to just the largest pools, so small miners are unlikely to learn the preimage and thus unlikely to be able to claim the payment. However, if the defense is effective, the attack should rarely happen and so this should not have a significant effect on mining profitability---unlike monitoring miner mempools which would have to be done continuously and forever. ZmnSCPxj noted that pay-to-preimage doesn't work with PTLCs.[2] I was hoping one of Bitcoin's several inventive cryptographers would come along and describe how someone with an adaptor signature could use that information to create a pubkey that could be put into a transaction with a second output that OP_RETURN included the serialized adaptor signature. The pubkey would be designed to be spendable by anyone with the final signature in a way that revealed the hidden value to the pubkey's creator, allowing them to resolve the PTLC. But if that's fundamentally not possible, I think we could advocate for making pay-to-revealed-adaptor-signature possible using something like OP_CHECKSIGFROMSTACK.[3] [1] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002664.html [2] https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-April/002667.html [3] https://bitcoinops.org/en/topics/op_checksigfromstack/ > Do you think it's unreasonable to expect at least some LN nodes to > also invest in running nodes in mining pools, ensuring that they learn > about attackers' txs and can potentially share discovered preimages > with the network off-chain (by gossiping preimages found in the > mempool over LN)? Ignoring my concerns about mining centralization and from the perspective of just the Lightning Network, that doesn't sound unreasonable to me. But from the perspective of a single LN node, it might make more sense to get the information and *not* share it, increasing your security and allowing you to charge lower routing fees compared to your competitors. This effect would only be enhanced if miners charged for their mempool contents (indeed, to maximize their revenue, miners might require that their mempool subscribers don't share the information---which they could trivially enforce by occasionally sending subscribers a preimage specific to the subscriber and seeing if it propagated to the public network). > I think that these recent attacks show that we need (at least some) > off-chain nodes to be somewhat heavily invested in on-chain operations > (layers can't be fully decoupled with the current security assumptions > - maybe Eltoo will help change that in the future?). I don't see how eltoo helps. Eltoo helps ensure you reach the final channel state, but this problem involves an abuse of that final state. -Dave -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: not available URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200620/6085153a/attachment-0001.sig>