rich1.0npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0uhttps://nostr.ae/npub1r3san9v5njl6798hvauyu9ntm6r9c7u8s0t65wls58gpfdcvqp5sa48d0unjumphttps://nostr.ae📅 Original date posted:2015-08-13 📝 Original message:On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev < bitcoin-dev at lists.linuxfoundation.org> wrote: > I haven't tested the details of this, but is there another bit available > for use in the future for the relative blockheight? > > I strongly believe that Lightning needs mitigations for a systemic > supervillan attack which attemps to flood the network with transactions, > which can hypothetically be mitigated with something like a timestop > bit (as originally suggested by gmaxwell). > This proposal includes no such provision. Since we talked about it, I spent considerable time thinking about the supposed risk and proposed mitigations. I'm frankly not convinced that it is a risk of high enough credibility to worry about, or if it is that a protocol-level complication is worth doing. The scenario as I understand it is a hub turns evil and tries to cheat every single one of its users out of their bonds. Normally a lightning user is protected form such behavior because they have time to broadcast their own transactions spending part or all of the balance as fees. Therefore because of the threat of mutually assured destruction, the optimal outcome is to be an honest participant. But, the argument goes, the hub has many channels with many different people closing at the same time. So if the hub tries to cheat all of them at once by DoS'ing the network, it can do so and spend more in fees than any one participant stands to lose. My issue with this is that users don't act alone -- users can be assured that other users will react, and all of them together have enough coins to burn to make the attack unprofitable. The hub-cheats-many-users case really is the same as the hub-cheats-one-user case if the users act out their role in unison, which they don't have to coordinate to do. Other than that, even if you are still concerned about that scenario, I'm not sure timestop is the appropriate solution. A timestop is a protocol-level complication that is not trivial to implement, indeed I'm not even sure there is a way to implement it at all -- how do you differentiate in consensus code a DoS attack from regular old blocks filling up? And if you could, why add further complication to the consensus protocol? A simpler solution to me seems to be outsourcing the response to an attack to a third party, or otherwise engineering ways for users to respond-by-default even if their wallet is offline, or otherwise assuring sufficient coordination in the event of a bad hub. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150813/a161abd7/attachment.html>