{"type":"rich","version":"1.0","author_name":"npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","author_url":"https://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0u","provider_name":"njump","provider_url":"https://nostr.ae","html":"📅 Original date posted:2015-08-13\n📝 Original message:On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e I haven't tested the details of this, but is there another bit available\n\u003e for use in the future for the relative blockheight?\n\u003e\n\u003e I strongly believe that Lightning needs mitigations for a systemic\n\u003e supervillan attack which attemps to flood the network with transactions,\n\u003e which can hypothetically be mitigated with something like a timestop\n\u003e bit (as originally suggested by gmaxwell).\n\u003e\n\nThis proposal includes no such provision.\n\nSince we talked about it, I spent considerable time thinking about the\nsupposed risk and proposed mitigations. I'm frankly not convinced that it\nis a risk of high enough credibility to worry about, or if it is that a\nprotocol-level complication is worth doing.\n\nThe scenario as I understand it is a hub turns evil and tries to cheat\nevery single one of its users out of their bonds. Normally a lightning user\nis protected form such behavior because they have time to broadcast their\nown transactions spending part or all of the balance as fees. Therefore\nbecause of the threat of mutually assured destruction, the optimal outcome\nis to be an honest participant.\n\nBut, the argument goes, the hub has many channels with many different\npeople closing at the same time. So if the hub tries to cheat all of them\nat once by DoS'ing the network, it can do so and spend more in fees than\nany one participant stands to lose. My issue with this is that users don't\nact alone -- users can be assured that other users will react, and all of\nthem together have enough coins to burn to make the attack unprofitable.\nThe hub-cheats-many-users case really is the same as the\nhub-cheats-one-user case if the users act out their role in unison, which\nthey don't have to coordinate to do.\n\nOther than that, even if you are still concerned about that  scenario, I'm\nnot sure timestop is the appropriate solution. A timestop is a\nprotocol-level complication that is not trivial to implement, indeed I'm\nnot even sure there is a way to implement it at all -- how do you\ndifferentiate in consensus code a DoS attack from regular old blocks\nfilling up? And if you could, why add further complication to the consensus\nprotocol?\n\nA simpler solution to me seems to be outsourcing the response to an attack\nto a third party, or otherwise engineering ways for users to\nrespond-by-default even if their wallet is offline, or otherwise assuring\nsufficient coordination in the event of a bad hub.\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150813/a161abd7/attachment.html\u003e"}