[Lightning-dev] Using Per-Update Credential to enable Eltoo-Penalty

[ZmnSCPxj]

Good morning Antoine,


> Biggest gains with Eltoo are of course transaction symmetry and removing toxic waste. Reintroducing penalty on top of
> this shouldn't affect this two goals,

I agree with Christian that introducing penalty introduces toxic waste.
Inadvertent misuse of a backup of an old database will still result in punishment.
Indeed, this is part of the toxic waste problem: operator error can lead to loss of funds.

> > If a later Litigation Tx is used, than the Update Tx that was put onchain, is the signature from the Update Tx valid on the same transaction where the Challenge Tx is valid?
>
> Main idea of this scheme is to used Per-Update Commitment to solve the assignment problem in a safe way. What we need
> on a higher-level are messages tied to a specific party and committed to a given state number. If anyone can prove to the
> blockchain you have broadcast 2 messages with different state number it means you breach the contract.
>
> Now how to do that with Script ? Only messages interpreted by the blockchain are bitcoin transactions.
>
> If we follow Taproot current transaction digest algorithm, without sighash flags set, assuming we spend a taproot output
> we have the following hashed elements : epoch, hash_type, nVersion, nLockTime, sha_prevouts, sha_amounts,
> sha_sequences, sha_outputs, spend_type, input_index, sha_annex.
>
> If we use SIGHASH_ANYPREVOUTANYSCRIPT + SIGHASH_NONE, we get the following hashed elements :
> epoch, hash_type, nVersion, nLocktime, spend_type, amount, nSequence, sha_annex.
>
> If we force to sign 2 different transactions with these both sighashes against same pubkey, and assuming there are
> spending the same amount and nSequences are equals, we should get identical signatures. If they are not,
> the only difference element is the nLocktime.
>
> That could be a way to make script aware of committed per-party state number.
>
> Using this in a Eltoo-Penalty scheme, the Challenge tx script is encumbered by a branch where if you show up
> with 2 valid signatures but non-identical, that's a proof the challenged party has tried to cheat. Of course, I guess
> you need a bit of expansion on script primitives, like SIGHASH_ANYPREVOUTANYSCRIPTANYAMOUNT and
> an  OP_CHECKSIG_WITH_STATE_NUMBER with following syntax <sig> <state_number> <pubkey> OP_CSWSN
> and following semantic "verify this signature against this pubkey but first mask nLocktime of transaction with the
> second-to-top stack item". Because signatures need to be both valid on same transaction but they have committed
> to different nLocktime, Justice tx need to have a mutable nLocktime field at verification.
>
> I didn't think about the need of something like OP_CSWSN in first mail, some people pointed me the issue, so here 
> the updated scripts.

This requires adding more at the base layer, which is much more strongly contentious (at the Lightning layer you can arrange to use whatever construction you want with your peer, and in general still be able to route, except that with anything other than Poon-Dryja channels also have a minimum CSV delay that needs to be considered by the source).

At what little I understand there is not much consensus yet at Bitcoin blockchain layer to add *any* vsriant of `SIGHASH_NOINPUT` yet.
But now this construction requires, in addition to `SIGHASH_NOINPUT`:

* Pubkeys that require specific `SIGHASH` flags in their signature.
* A way to validate that a particular signature commits to a particular `nLockTime`.

The only advantage this construction has on top of Poon-Dryja is the ability to have 3 or more participants.
The disadvantages relative to Poon-Dryja are:

* A CSV restriction on routed HTLCs.
* Needs *much* more to be added to the blockchain, including 1 controversial feature (admittedly has a reasonable chance of appearing in some form) and 2 completely new features (which will need to be very strongly reviewed in bitcoin-dev and elsewhere first).

---

Now I believe you agree that channel factories are better:

> "I would argue that channel factories are better used than multiparticipant channels, as channel factories allow *some* limited transport of funds even if one participant is offline, whereas multiparticipant channels prevent *all* transport of funds as soon as any one participant is offline"
>
> I agree too

So let me counterpropose instead:

* Use Decker-Wattenhofer (mostly the multiple-stage decrementing `nSequence` part, drop the duplex Spilman-like channels) or Decker-Russell-Osuntokun ("eltoo") at the Factory level.
  * Do not allow participants to hold a singlesig output at the Factory level, all states at this level should have only 2-of-2s that back channels.
* Use Poon-Dryja at the Channel level for all channels inside the factory.

This prevents thieves from *practically* stealing with old factory-level state, since the funds are still in individual Poon-Dryja channels.

When you reorganize a channel (change its total balance) during a factory-level update, you go about things this way.

1.  Sign new commitment transactions for the modified channels, spending the post-modified amount of the channel.
    (assume we use `SIGHASH_NOINPUT` in the Poon-Dryja commitment txes, to avoid the "stale factory problem" for channels that are not modified in the factory-level update)
2.  Sign the new factory-level update and settlement transactions (assuming we use Decker-Russel-Osuntokun).
3.  Revoke the previous commitment transactions of the modified channels (the ones that spent from the pre-modified amounts).

If this aborts after step 1, the new commitment transactions cannot be used since the latest factory output values will not match the values expected by the new commitment transactions.

If this aborts after step 2, the individual channels that were modified will be "frozen" (cannot add/fail/fulfill HTLCs) until both sides have performed step 3.
If the freeze lasts long enough to reach HTLC locktimes, then this forces a unilateral close of the entire factory and all its channels.

With this, an attacker that wants to steal using an older factory state would still contend with the fact that channels that have been modified since that state will have had their latest transaction revoked, thus will lose all their funds there.
And as long as each individual Poon-Dryja channel has a reserve, there is still some money that each participant will be risking losing.

In short: replaying old factory state is pointless since the thief still has to contend with the individual channel-level punishments.

This returns punishment while still allowing channel factory scaling, which is the important thing we *actually* want (the goal of transaction symmetry is aesthetic, but not useful), at the cost of returning toxic waste.

Regards,
ZmnSCPxj