Using Per-Update Credential to enable Eltoo-Penalty

Summary:

Antoine proposed a new Eltoo-Penalty scheme to reintroduce penalties in the Lightning Network without affecting transaction symmetry and removing toxic waste. He addressed concerns about creating a fake "Mallory" and suggested using witnesses' asymmetry and signatures committed to a state number.Preimages had some issues, such as requiring a Hostile Settlement tx for every update, and unique preimages not being safe against reorg or mempool snooping. Friendly Settlement Tx must spend the Update Tx after some delay, and there should be an OP_CLTV in litigation script path. The main idea was to use Per-Update Commitment to solve the assignment problem safely.The Decker-Russell-Osuntokun protocol eliminates "toxic waste" by removing the punitive consideration so that being framed for theft does not lose all your funds, it merely closes your channels. However, an attacker might still be able to access your channel data and use an older version to frame you for theft and make you lose all your channel funds.The proposed Eltoo-Penalty Transaction Tree aims to solve this problem. The proposal uses per-update credentials, a secret committed to a state number, and SIGHASH magic to assign the faulty broadcast to the right party to punish it in consequence. The proposal also includes the Eltoo-Penalty Scripts, which utilize muSig and require parties broadcasting an Update tx to sign it with SIGHASH_ANYPREVOUTSCRIPT|SIGHASH_NONE|SIGHASH_SINGLE. If someone shows a Litigation Tx with a higher state than the Update, it means that this one has been revoked, and someone is cheating among channel parties. The script then enters the Litigation phase, where the Settlement Tx will be encumbered by a Challenge Tx against which you will need to produce a signature with the same SIGHASH flags as the Update Tx. If Alice tries to cheat, Bob can take the signature from her broadcast Update tx and Alice’s signature on the Challenge tx, pass it as a witness to a script verifying their validity and identity. If their validity is true and identity is false, you can spend with a Justice tx, splitting Alice’s funds between the other parties. If validity is true and identity is true, then the script should fail. After timelock expiration, if no one has proven Alice misbehaved, she can redeem her funds.The context describes a thought experiment involving Eltoo + penalties. The experiment involves Alice, Bob, and Caroll building new friendly settlement tx N, new Update Tx, and revoking the old one by generating a Justice tx with state higher than the previous one, a hostile Settlement tx plus Y challenge txn and Y justice txn with Y number of parties.After X updates, Alice broadcast the last Update tx N, by signing it with her private key with SIGHASH_NONE,SIGHASH_ANYPREVOUTANYSCRIPT,SIGHASH_SINGLE and using MuSig previously distributed between parties at state update. Her signature doesn't protect anything except commitment to the latest state number.In the Malicious Case, Bob broadcasts a lowest Update tx with his signature committing to it. Alice uses Litigation tx to spend it, if anyone has a highest Litigation tx, he can use it. After Litigation tx finalization, a hostile settlement transaction is used. Each output returning to a channel party is encumbered by a "challenge". To unlock your funds, you must provide a signature against same pubkey and same SIGHASH flags as the one encumbering your tapscript for funding output.Challenge tx is using a taproot output, one leaf returning fund to Alice after some timelock. The other one allows anyone with a MuSig and two valid signatures committing to different nLocktime to send challenged fund to a Justice tx, doing an equal split between other channel parties. You need signatures to be safe against third-party malleability, i.e being able to tweak your signatures to be still valid but diff being interpreted as proof of commitment on the lowest state number.On the Justice tx, you need a new key type to enforce that every signature must have SIGHASH_MASKLOCKTIMEWITH, where you expect the signature to be followed by the state number which is going to be used as locktime in transaction digest algorithm. Explicitly stating what transaction outputs are spent by each transaction input would be better, especially since the graph is unclear. The descriptions of the transactions and scripts involved are confusing, and it is uncertain if the target has been achieved.

Updated on: 2023-06-02T19:26:39.988285+00:00