{"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-14\n📝 Original message:With the assumed malleability-fix CHECKSIG2 version of lightning, watching\nfor and responding to bad behavior is fully outsourceable. You can\nsynchronize channel state (signed refund transactions) with a third party\nthat watches for replay of old transactions on the mainnet, and starts the\nrefund process if it observes them, paying the fees necessary to get on the\nchain.\n\nWith the CLTV/CSV-only form of the hash time-lock contracts that Rusty has\ndeveloped, this is indeed something the users' wallets would have to be\nonline to observe happening and respond to. I presume that we are\neventually going to get a CHECKSIG2 with some kind of malleability-immune\nsigning scheme in the long term, and that we are not interested in\nintroducing new consensus behavior to cover that short stopgap.\n\n\u003e I'm not even sure if sufficient coordination is a sufficient solution.\n\nA regrettable choice of words. In this case it is game theoretic\ncooperation, not coordination. The users need only expect that each other\nwould react the same way, being willing to burn money as fees that would\notherwise be stolen. They don't actually have to communicate with each\nother in order to cooperate.\n\nYou are correct though that hubs-with-hashpower complicate this situation.\nAlthough a hub with hashpower also creates risk in the timestop scenario\ntoo...\n\nOn Fri, Aug 14, 2015 at 11:53 AM, Matt Corallo \u003clf-lists at mattcorallo.com\u003e\nwrote:\n\n\u003e\n\u003e\n\u003e On 08/14/15 00:47, Mark Friedenbach via bitcoin-dev wrote:\n\u003e \u003e On Thu, Aug 13, 2015 at 4:42 PM, Joseph Poon via bitcoin-dev\n\u003e \u003e \u003cbitcoin-dev at lists.linuxfoundation.org\n\u003e \u003e \u003cmailto:bitcoin-dev at lists.linuxfoundation.org\u003e\u003e wrote:\n\u003e \u003e\n\u003e \u003e     I haven't tested the details of this, but is there another bit\n\u003e available\n\u003e \u003e     for use in the future for the relative blockheight?\n\u003e \u003e\n\u003e \u003e     I strongly believe that Lightning needs mitigations for a systemic\n\u003e \u003e     supervillan attack which attemps to flood the network with\n\u003e transactions,\n\u003e \u003e     which can hypothetically be mitigated with something like a timestop\n\u003e \u003e     bit (as originally suggested by gmaxwell).\n\u003e \u003e\n\u003e \u003e\n\u003e \u003e This proposal includes no such provision.\n\u003e \u003e\n\u003e \u003e Since we talked about it, I spent considerable time thinking about the\n\u003e \u003e supposed risk and proposed mitigations. I'm frankly not convinced that\n\u003e \u003e it is a risk of high enough credibility to worry about, or if it is that\n\u003e \u003e a protocol-level complication is worth doing.\n\u003e \u003e\n\u003e \u003e The scenario as I understand it is a hub turns evil and tries to cheat\n\u003e \u003e every single one of its users out of their bonds. Normally a lightning\n\u003e \u003e user is protected form such behavior because they have time to broadcast\n\u003e \u003e their own transactions spending part or all of the balance as fees.\n\u003e\n\u003e My concern is how the hell do you automate this? Having a threat of\n\u003e \"well, everyone could update their software to a new version which will\n\u003e destroy all coins right now\" is kinda useless, and trying to come up\n\u003e with a reasonable set of metrics as to how much and when you move from\n\u003e just paying the fee to destroying coins is really hard, especially if\n\u003e you assume the attacker is a miner with, say, enough hashrate (maybe\n\u003e rented) to get one or three blocks in the next day (the timeout period).\n\u003e\n\u003e \u003e Therefore because of the threat of mutually assured destruction, the\n\u003e \u003e optimal outcome is to be an honest participant.\n\u003e \u003e\n\u003e \u003e But, the argument goes, the hub has many channels with many different\n\u003e \u003e people closing at the same time. So if the hub tries to cheat all of\n\u003e \u003e them at once by DoS'ing the network, it can do so and spend more in fees\n\u003e \u003e than any one participant stands to lose. My issue with this is that\n\u003e \u003e users don't act alone -- users can be assured that other users will\n\u003e \u003e react, and all of them together have enough coins to burn to make the\n\u003e \u003e attack unprofitable.\n\u003e\n\u003e Now users are coordinating quickly in an attack scenario?\n\u003e\n\u003e \u003e The hub-cheats-many-users case really is the same\n\u003e \u003e as the hub-cheats-one-user case if the users act out their role in\n\u003e \u003e unison, which they don't have to coordinate to do.\n\u003e \u003e\n\u003e \u003e Other than that, even if you are still concerned about that  scenario,\n\u003e \u003e I'm not sure timestop is the appropriate solution. A timestop is a\n\u003e \u003e protocol-level complication that is not trivial to implement, indeed I'm\n\u003e \u003e not even sure there is a way to implement it at all -- how do you\n\u003e \u003e differentiate in consensus code a DoS attack from regular old blocks\n\u003e \u003e filling up? And if you could, why add further complication to the\n\u003e \u003e consensus protocol?\n\u003e\n\u003e Yea, implementation is really tricky here. I do not at all think we\n\u003e should be thinking about implementing this any time soon, and should\n\u003e assume Lightning will have to stand reasonably on its own without it\n\u003e first, and only if it gains a lot of traction will there be enough\n\u003e motivation for making such a change at the Bitcoin protocol level for\n\u003e Lightning.\n\u003e\n\u003e \u003e A simpler solution to me seems to be outsourcing the response to an\n\u003e \u003e attack to a third party\n\u003e\n\u003e Doesnt that defeat the purpose of Lightning?\n\u003e\n\u003e \u003e or otherwise engineering ways for users to\n\u003e \u003e respond-by-default even if their wallet is offline, or otherwise\n\u003e \u003e assuring sufficient coordination in the event of a bad hub.\n\u003e\n\u003e I'm not even sure if sufficient coordination is a sufficient solution.\n\u003e If you assume a hub just shut down, and everyone is trying to flush to\n\u003e the chain, with a backlog of a few days worth of transactions (with\n\u003e timeouts of a day or so), and users are even paying huge fees (99% of\n\u003e what they'd get back), if the former-hub is a miner, it can claim that\n\u003e last 1% of many of the transactions that take longer than a day to confirm.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150814/55d9334f/attachment-0001.html\u003e"}