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

Antoine Riard antoine.riard at gmail.com
Tue Jul 16 18:52:41 UTC 2019


Hi ZmnSCPxj,

Awesome resume, it's better lay-out than I did myself !!

> Thus, I would like to thank you for your tolerance and continued
attention.

Personally, it's a pleasure to read your weird but always thoughtful
proposals in other threads :)

"We have identified two requirements:

1.  We must identify which participant initiated the unilateral close
onchain.
    We do so that if later, we find that the unilateral close was to an
older state, we can punish the participant that initiated the unilateral
close.
2.  We must identify that a unilateral close was, in fact, to an older
state."

I think you have well-scoped the assignment problem. But it would add
another requirement :

3. Identity commitment must not be replayable or counterfeited by another
participant.

I thought to use unique preimage in a previous versions of my proposal but
it seems really unsafe due to reorgs and mempool snooping. If another
channel participant is able to take back your identity preimage and uses it
to spend with a lower state update tx you are know flagged as the
cheater. So we want preimage to be tied to a state number and best scheme
I've thought of is not using preimage but signatures.

May we build a commitment with preimage and state number without signatures
?

> * comment: we use the common key, and the requirement to provide the
Alice fingerprint preimage, *and* the requirement to enable RBF, to force
the output to be revoked to miners as fees: when the entire output is given
as fee, no higher RBF is possible.
              * comment: outputs may become too tiny to care about if we
split up a tiny reserve between dozens of honest participants.

On the other side, giving back funds to participants let them cover back
the expenses to pay onchain fees for last state enforcement.

> * Add branches for revocation, where proof that one side attempted to
steal allows the other side to control the coin immediately.

Hmm that's the point we argue a lot, but by broadcasting a previous update,
if HTLC is Bob->Caroll, Bob didn't only try to rob Caroll
but potentially every others channel participants. Why they should get a
part of Bob funds as compensation ?

> It is safe to publish the revocation key if you publish only the latest
Update Transaction, as the latest Update Transaction cannot enable any
Litigation Transaction.

Exact, even if you're a honest participant you have to commit to a secret
or revocation key, because the blockchain can
only know after the nSequence expiration delay of the Friendly Settlement
transaction that you are honest.

Le lun. 15 juil. 2019 à 05:58, ZmnSCPxj via Lightning-dev <
lightning-dev at lists.linuxfoundation.org> a écrit :

> Good morning list,
>
> As usual, I am spamming the list for my amusement.
>
> Thus, I would like to thank you for your tolerance and continued attention.
>
> ----
>
> We have identified two requirements:
>
> 1.  We must identify which participant initiated the unilateral close
> onchain.
>     We do so that if later, we find that the unilateral close was to an
> older state, we can punish the participant that initiated the unilateral
> close.
> 2.  We must identify that a unilateral close was, in fact, to an older
> state.
>
> Thus, I will counterpropose a construction similar to that originally
> proposed here, but with the weaknesses fixed and key details filled in.
> (while part of it is similar to the Decker-Russell-Osuntokun "eltoo", it
> is different enough that I would not suggest calling it "eltoo-penalty")
>
> ----
>
> On initiation, Alice, Bob, and Charlie indicate:
>
> * Alice/Bob/Charlie "fingerprint" hash/preimage.
>   Alice/Bob/Charlie publish the fingerprint hashes, but keep the
> fingerprint preimages secret.
> * Alice/Bob/Charlie "normal" pubkey.
> * Alice/Bob/Charlie "lawyer" pubkey.
> * All participants indicate a `delay`, a number of blocks.
>   Funds may be locked, in worst case, up to `2 * delay`.
>
> We also introduce a "common" key whose private key is known to all
> participants.
> For example, we can use a key whose private key is `SHA256("ZmnSCPxj is a
> human being and not any kind of AI")` as a consensus-accepted fact.
>
> We have the below transactions:
>
> * Funding transaction
>   * inputs: unspecified
>   * outputs:
>     * change output(s): unspecified
>     * funding output:
>       * Internal Taproot Key: `P = MuSig(Alice normal pubkey, Bob normal
> pubkey, Charlie normal pubkey)`
>       * Scripts:
>         * `OP_1 OP_CHECKSIGVERIFY OP_HASH160 <Alice fingerprint hash>
> OP_EQUALVERIFY`
>         * `OP_1 OP_CHECKSIGVERIFY OP_HASH160 <Bob fingerprint hash>
> OP_EQUALVERIFY`
>         * `OP_1 OP_CHECKSIGVERIFY OP_HASH160 <Charlie fingerprint>
> OP_EQUALVERIFY`
>
> * Update Transaction
>   * comment: this transaction initiates a unilateral close attempt.
>   * comment: Updates have a "hidden" `n`, which is an "update" number
> incrementing from 0.
>     This number could be encoded as `nLockTime` by using `500e6 + n`, but
> in principle does not need to be encoded there (we could use the current
> encoding in Poon-Dryja, which is encrypted so that normal unilateral closes
> do not reveal how many updates occurred).
>   * Update transaction might have other inputs/outputs used to pay for
> onchain fees.
>   * input:
>     * Funding transaction output
>     * witness: one of the following, depending on which participant
> initiated the unilateral close:
>       * `<Alice fingerprint preimage> sign(MuSig(A normal, B normal, C
> normal), SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_SINGLE)`
>       * `<Bob fingerprint preimage> sign(MuSig(A normal, B normal, C
> normal), SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_SINGLE)`
>       * `<Charlie fingerprint preimage> sign(MuSig(A normal, B normal, C
> normal), SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_SINGLE)`
>     * comment: which witness script appears onchain depends on which
> participant initiated the unilateral close.
>   * output:
>     * Internal Taproot Key: `MuSig(A normal, B normal, C normal)`
>     * Scripts:
>       * `<delay> OP_CHECKSEQUENCEVERIFY OP_DROP <MuSig(A normal, B normal,
> C normal)> OP_CHECKSIG`
>         * This is the "normal" unilateral path where the participant did
> not steal any funds.
>       * `<500e6 + n + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP <MuSig(A lawyer, B
> lawyer, C lawyer)> OP_CHECKSIG`
>         * This is the "litigation" path where the participant is proven to
> have stolen funds by showing a litigation transaction with later `n` than
> the update transaction.
>
> * Friendly Settlement Transaction
>   * comment: This transaction completes a unilateral close attempt and
> publishes all contracts transported in the channel without revocability
> branches.
>   * `nSequence`: `<delay>`
>   * input:
>     * Update transaction output
>     * witness: `sign(MuSig(A normal, B normal, C normal),
> SIGHASH_ANYPREVOUTANYSCRIPT)`
>   * outputs: unencumbered outputs for this state.
>
> * Litigation Transaction
>   * comment: The appearance of this transaction onchain is taken as proof
> that the unilateral close attempt is definitely a theft attempt.
>     It can only be broadcast and confirmed if and only if the unilateral
> close Update Transaction has an `n` that is less than the latest agreed `n`.
>   * comment: A Litigation Transaction can be spent by another Litigation
> Transaction with higher `n`.
>     The intent is to force the current state onchain, in order to punish
> the thief using the *latest* state instead of punishing from old state.
>   * `nLockTime`: `500e6 + n`, where `n` is the update index for this
> Litigation Transaction.
>     * comment: a Litigation Transaction with `n` cannot spend an Update
> Transaction of same `n`, only `n - 1` or less.
>   * input:
>     * Update transaction output *OR* another Litigation Transaction
> output; Update/Litigation tx has `n` less than this Litigation transaction.
>     * witness: `sign(MuSig(A lawyer, B lawyer, C lawyer),
> SIGHASH_ANYPREVOUTANYSCRIPT | SIGHASH_SINGLE)`
>   * output:
>     * Internal Taproot Key: `MuSig(A lawyer, B lawyer, C lawyer)`
>     * scripts:
>       * `<500e6 + n + 1> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_1 OP_CHECKSIG`
>         * comment: This allows a Litigation Transaction with later
> `nLockTime` to spend this Litigation Transaction.
>       * `<delay> OP_CHECKSEQUENCEVERIFY OP_DROP <500e6 + n>
> OP_CHECKLOCKTIMEVERIFY OP_DROP OP_1 OP_CHECKSIG`
>         * comment: This is the "Hostile Settlement" path that allows
> revocation of outputs owned by the participant that initiated the
> unilateral close.
>
> * Hostile Settlement Transaction
>   * `nLockTime`: `500e6 + n`
>   * input:
>     * Litigation Transaction output
>     * witness: `sign(MuSig(A lawyer, B lawyer, C lawyer),
> SIGHASH_ANYPREVOUTANYSCRIPT)`
>   * outputs:
>     * Depending on type of contract, outputs are revocable:
>       * Single-ownership contract (example below is Alice-owned)
>         * Taproot Internal Key: `P = NUMS point` (cannot be spent via
> non-Taproot path)
>         * scripts:
>           * `<delay> OP_CHECKSEQUENCEVERIFY OP_DROP <A lawyer> OP_CHECKSIG`
>             * comment: This lets Alice recover its funds if it is not the
> thief.
>           * `OP_0 OP_CHECKSEQUENCEVERIFY OP_DROP OP_HASH160 <Alice
> fingerprint hash> OP_EQUALVERIFY <common key> OP_CHECKSIG`
>             * comment: Alice fingerprint preimage is published if Alice is
> the one who published the old Update Transaction.
>               Any participant can take that preimage and re-publish it
> here.
>             * comment: the `0 OP_CHECKSEQUENCEVERIFY` ensures the spending
> script has RBF enabled.
>             * comment: we use the common key, and the requirement to
> provide the Alice fingerprint preimage, *and* the requirement to enable
> RBF, to force the output to be revoked to miners as fees: when the entire
> output is given as fee, no higher RBF is possible.
>               * comment: outputs may become too tiny to care about if we
> split up a tiny reserve between dozens of honest participants.
>                 But the important point is to punish the thief, not award
> the honest participants.
>               * comment: further, since the Litigation Transaction
> *should* make valid the latest Hostile Settlement, the outputs of the
> honest participants are at the latest state, already, so they cannot lose
> funds by having the thief-owned outputs be revoked in favor of miners.
>       * Dual-ownership contract (example below is an HTLC from Bob to
> Charlie)
>         * Taproot Internal Key: `P = NUMS point`
>         * scripts:
>           * `<delay> OP_CHECKSEQUENCEVERIFY OP_DROP <locktime>
> OP_CHECKLOCKTIMEVERIFY OP_DROP <B lawyer> OP_CHECKSIG`
>             * comment: Timelock branch, Bob reclaims money.
>           * `<delay> OP_CHECKSEQUENCEVERIFY OP_DROP OP_HASH160 <hash>
> OP_EQUALVERIFY <C lawyer> OP_CHECKSIG`
>             * comment: Hashlock branch, Charlie claims funds in exchange
> for publishing payment preimage.
>           * `OP_HASH160 <Bob fingerprint hash> OP_EQUALVERIFY <C lawyer>
> OP_CHECKSIG`
>             * comment: Revocation branch, Bob attempted to steal, so
> Charlie gets the money outright.
>           * `OP_HASH160 <Charlie fingerprint hash> OP_EQUALVERIFY <B
> lawyer> OP_CHECKSIG`
>             * comment: Revocation branch, Charlie attempted to steal, so
> Bob gets the money outright.
>         * Any two-participant contract can be made revocable by the same
> pattern:
>           * Use a NUMS point for taproot internal key.
>           * Give every branch explicitly as a branch in the Taproot MAST;
> prepend an additional `<delay> OP_CHECKSEQUENCEVERIFY OP_DROP`.
>           * Add branches for revocation, where proof that one side
> attempted to steal allows the other side to control the coin immediately.
>         * Sub-channels will need to use `SIGHASH_ANYPREVOUTANYSCRIPT`, so
> that signatures that can spend from an output of the Friendly Settlement
> can also spend from an output of the Hostile Settlement (once the
> additional encumberance has been passed).
>
> So, here are some changes to the original proposal:
>
> * We use a hash/preimage challenge to identify *who* attempted to steal.
>   * The "revocation key" is the same as the "fingerprint".
>     It is safe to publish the revocation key if you publish only the
> latest Update Transaction, as the latest Update Transaction cannot enable
> any Litigation Transaction.
> * Single-ownership outputs of the current state are encumbered by a
> revocability clause that revokes in favor of miners.
> * Dual-ownership outputs of the current state are encumbered by a
> revocability clause that revokes in favor of the non-thief participant if
> one of the participants is the thief.
> * Outputs with more than two owners are not supported by this construction.
>
> It was not very clear from the original proposal, but the Litigation
> Transaction path ensures we can go to the latest state, and the Hostile
> Settlement transaction represents the latest state, plus allowing
> revocability of outputs in that state.
> This behavior allows us to perform our punishments based on the latest
> state, compared to Poon-Dryja which punishes based on the old published
> state (which is simpler since it always just rewards the entire channel
> funds to the honest party).
>
> The Friendly Settlement transaction does not allow any revocability, but
> can only be published if no Litigation Transaction has been published.
>
> Regards,
> ZmnSCPxj
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190716/f4a61b21/attachment-0001.html>


More information about the Lightning-dev mailing list