Author: Mark Friedenbach 2015-08-14 21:29:31
Published on: 2015-08-14T21:29:31+00:00
The context discusses the use of the assumed malleability-fix CHECKSIG2 version of lightning, which allows for outsourcing the monitoring and response to bad behavior. This is achieved by synchronizing channel state with a third party that watches for replay of old transactions on the mainnet and starts the refund process if it observes them. However, this requires users' wallets to be online to observe and respond to the behavior. The proposal also discusses the need for mitigations against a systemic supervillain attack that floods the network with transactions, which can hypothetically be mitigated with something like a timestop bit. However, the proposal does not include such a provision.The scenario discussed involves a hub turning evil and cheating all of its users out of their bonds, but users can protect themselves by broadcasting their own transactions spending part or all of the balance as fees. Although having a threat of "everyone could update their software to a new version, which will destroy all coins right now" is useless, users don't have to coordinate with each other to cooperate. If the hub cheats many users at once by DoS'ing the network, users can react together, making the attack unprofitable.However, the concern is raised about how to automate this process, and coming up with reasonable metrics as to when to move from paying the fee to destroying coins is challenging. Additionally, implementation is tricky and should not be considered anytime soon. A simpler solution is to outsource the response to an attack to a third party or engineer ways for users to respond-by-default even if their wallet is offline. It is uncertain whether sufficient coordination is a sufficient solution in the event of a bad hub shutting down and everyone trying to flush to the chain with a backlog of transactions that take longer than a day to confirm.
Updated on: 2023-06-10T19:23:10.198137+00:00