Post-Schnorr lightning txes



Summary:

The author proposes a new method for managing channel state updates in Bitcoin. The proposed method involves generating six-plus-eight times the number of HTLCs in-flight transactions every time the channel state is updated. 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 reveal the secret.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 the appropriate outputs are signed by each party. To avoid misbehavior, one side must hold a transaction with appropriate outputs that is timelocked via nSequence and signed by the other party. This ensures the other party has time to penalize misbehavior.Additionally, the author suggests using Schnorr to handle HTLCs via elliptic curve private keys, which would simplify scripts and make enforcing correct behavior cheaper. This approach allows users to forget information about old HTLCs while still enforcing correct behavior. Finally, the author notes that 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 allowing a penalty tx to be constructed based on the channel commitment tx. A formula can be arranged for constructing a penalty tx based on the channel commitment tx. The channel monitoring service can catch fraudulent transactions, work out the appropriate revocation secret, and finish the signature by catching any fraudulent transactions. Channel monitoring can be outsourced efficiently as little as a signature per state could be made to works as far as the author can see. The article also mentions that it is not possible to do better than the proposed method without serious changes to bitcoin. The author was hoping covenants and graftroot would be enough, but they are not. The author also notes that it is impossible to drop the muSig-style construction because it is needed to protect against potential malicious choice of the revocation secret. The author suggests that the proposed method could make it feasible and interesting to penalize disappearance as well as misbehavior.In conclusion, the article proposes a new method for managing channel state updates in Bitcoin. The method involves generating multiple transactions for each update, and all funding tx outputs can be pay2pubkey(hash). The author suggests outsourcing channel monitoring and believes it can be done efficiently. The article points out that there is no plausible way of doing constant space outsourced channel monitoring without some sort of SIGHASH_NOINPUT. The author also notes that the proposed method could make it feasible and interesting to penalize disappearance as well as misbehavior.


Updated on: 2023-05-20T08:05:53.066683+00:00