Published on: 2018-02-22T19:28:45+00:00
In a discussion on the Lightning Network mailing list, Anthony Towns suggests an alternative approach to the mechanics of HTLC-Timeout and HTLC-Success transactions in Lightning. He acknowledges that he is unsure how his approach compares to the current one. The proposed method involves redoing all current transactions with Schnorr/muSig/scriptless-scripts. However, this would require sending signatures for 2+2N outputs for every channel update, making the claiming transactions larger. On average, there would be 50 HTLCs per second, with 1000 HTLCs active at any given time.The author proposes a new method for managing channel state updates in Bitcoin. This method requires generating six-plus-eight times the number of HTLCs in-flight transactions for each channel state update. These transactions include Channel State Commitment TX, Channel Fund Distribution TX, Timeout TX, and Success TX. All funding tx outputs can be pay2pubkey(hash), which allows HTLCs to work with pre-signed timelocked transactions and scriptless scripts/discreet-log contracts.To optimize non-cooperative channel closure in the Lightning Network, the author suggests using graftroot, which involves three transactions. The outputs of these transactions are treated as muSig Schnorr pay-to-pubkey addresses and are signed by each party. To prevent misbehavior, one side must hold a transaction with appropriate outputs that is timelocked via nSequence and signed by the other party.Additionally, the author proposes using Schnorr to handle HTLCs through elliptic curve private keys. This simplifies scripts and reduces the cost of enforcing correct behavior. It also allows users to forget information about old HTLCs while still ensuring correct behavior. Furthermore, this method simplifies the scripts and requires only a constant amount of data to be stored for channel monitoring.The author suggests outsourcing channel monitoring by constructing a penalty tx based on the channel commitment tx. A formula can be arranged for constructing a penalty tx, and the channel monitoring service can catch fraudulent transactions, determine the appropriate revocation secret, and complete the signature. Channel monitoring can be efficiently outsourced with as little as one signature per state.The article acknowledges that there is no plausible way to achieve constant space outsourced channel monitoring without SIGHASH_NOINPUT. The author also notes that the proposed method could make it feasible and interesting to penalize disappearance as well as misbehavior. The author concludes by stating that the proposed method offers a new approach to managing channel state updates in Bitcoin, involving multiple transactions for each update.
Updated on: 2023-07-31T19:46:46.406127+00:00