Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[ZmnSCPxj via Lightning-dev]

Good morning Christian,

It seems to me we can remove the trigger transaction.

The observation is that `nSequence`-encumbered transactions are only settlement 
transactions and not any update transactions.

Thus, it is not needed for a trigger transaction to exist, if we can make 
update transactions behave as the trigger transaction for its settlement 
transaction or any later update transaction.

So, let me propose, that the funding transaction outpoint could have the below 
SCRIPT:

OP_IF
# Settlement branch
OP_FALSE
OP_ELSE
# Update branch. 500,000,000 is the minimum state number under 
Decker-Russell-Osuntokun.
5 OP_CHECKLOCKTIMEVERIFY
2 Au Bu 2 OP_CHECKMULTISIGVERIFY
OP_ENDIF

Thus, the funding outpoint can be spent directly by any update transaction, 
which has `  OP_FALSE` at its `witness` script.

When creating a mutual close transaction, we simply use the update branch of 
the funding transaction above, again signing with `  OP_FALSE`.  
This does have the drawback that the mutual close transaction can be RBFed away 
by an update transaction (requiring more code to handle this case); but the 
latest update transaction can still be published in that case and we simply 
devolve down to the usual unilateral close branch.

The drawback is that the mutual close transaction increases by 1 weight unit 
(the `OP_FALSE` in the `witness` script) plus the size of the more complicated 
funding transaction SCRIPT, which is no longer a regular 2-of-2 P2WSH and 
indelibly marking it as a Decker-Russel-Osuntokun mutual close.  Taproot would 
help there by implicitly including a plain 2-of-2 fallback.

Finally, we could argue that the mutual close transaction is expected to be the 
more common case, so increasing its size by even a small amount may outweigh 
the size reduction in the much rarer unilateral close case.

Regards,
ZmnSCPxj
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker]

ZmnSCPxj  writes:
> Good morning Christian,
>
> This is very interesting indeed!
>
> I have started skimming through the paper.
>
> I am uncertain if the below text is correct?
>
>> Throughout this paper we will use the terms *input script* to refer to 
>> `witnessProgram` and `scriptPubKey`, and *output script* to refer to the 
>> `witness` or `scriptSig`.
>
> Figure 2 contains to what looks to me like a `witnessProgram`, 
> `scriptPubKey`, or `redeemScript` but refers to it as an "output script":
>
>>OP_IF
>>10 OP_CSV
>>2 As Bs 2 OP_CHECKMULTISIGVERIFY
>>OP_ELSE
>>2 Au Bu 2 OP_CHECKMULTISIGVERIFY
>>OP_ENDIF
>>
>> Figure 2: The output script used by the on-chain update transactions.
>
> Regards,
> ZmnSCPxj

Darn last minute changes! Yes, you are right, I seem to have flipped the
two definitions. I'll fix that up and push a new version.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[ZmnSCPxj via Lightning-dev]

Hi Christian,

Let me know if I have summarized the paper accurately below:

1.  SIGHASH_NOINPUT removes all inputs of the transaction copy before 
signing/verifying.

2.  SIGHASH_NOINPUT can be combined with SIGHASH_SINGLE.  It is dangerous to 
combine it with SIGHASH_NONE (as this also deletes all outputs of the 
transaction copy, so the signature only commits to nLockTime) and possibly 
pointless to combine it with SIGHASH_ANYONECANPAY (which deletes other inputs, 
but since there are no inputs after SIGHASH_NOINPUT, there is nothing else to 
delete).  The BIP only mentions combining it with SIGHASH_SINGLE, in any case.

3.  We have these kinds transactions: (1) funding transaction paying out to an 
ordinary N-of-N multisig (confirmed onchain); (2) offchain trigger transaction 
spending a funding transaction and paying out to the "update transaction 
script"; (3) offchain update transaction spending a trigger or update 
transaction and paying out to the "update transaction script" (the same script 
template as in trigger transaction); (4) offchain settlement transaction 
spending a trigger or update transaction and paying out to the counterparties 
according to the final agreed distribution of funds.  Update and settlement 
transactions are signed with SIGHASH_NOINPUT flags.

4.  The update transaction script has two branches: a CSV-encumbered N-of-N 
"settlement" branch, and a CLTV-encumbered N-of-N "update" branch.  Crucially, 
we use past Unix timestamps for the CLTV encumberance on the update.  The 
CLTV-encumberance starts with a minimum time value on the trigger transaction, 
and increments by 1 for every update transaction.

5.  The CLTV-encumberance ensures that if a past update transaction is 
confirmed, we can spend it using any later update transaction, since CLTV uses 
`stackTop <= nLockTime`.  The actual `nLockTime` we use is a past Unix 
timestamp so they are not actually time-encumbered, but the `OP_CLTV` still 
ensures that any later update transaction can be used to spend from any earlier 
update transaction, but not vice versa.  This is actually quite clever.

6.  The pubkeys on the settlement branch of each update transaction are 
different, and are derived using any hierarchical derivation method (trivially 
we can simply use the CLTV-encumberance value as the derivation index).  This 
ensures that each settlement transaction can only spend a particular update 
transaction.  Or in other words: There is a one-to-one correspondence between 
update and settlement transaction, and a settlement transaction can only 
confirm if the corresponding update transaction can be confirmed deeply enough 
without having its output re-spent.

7.  The pubkeys on the update branch are all the same in all update 
transactions.  This lets any update transaction replace any other update 
transaction, as long as the CLTV-encumberance (which is used for ordering 
rather than actual absolute locktime) is respected; together they mean that any 
later update transaction can replace any earlier update transaction.

8.  If an old update transaction is confirmed, the settlement transaction 
corresponding to it is still encumbered by CSV and cannot be confirmed 
immediately.  During this time, a later update transaction can spend it and be 
confirmed.  If that update transaction is still not the latest available, it 
can be further replaced with any, later transaction (since the 
CLTV-encumberance and the `nLockTime` increase in lockstep with each other) 
until the latest update transaction is confirmed.

9.  When the latest update transaction gets confirmed, no other update 
transaction can successfully spend its "update" branch (as their `nLockTime` is 
less than the CLTV-encumberance on that branch).  This lets the CSV-encumbered 
settlement transaction be confirmable after some blocks.

10.  Update transactions pay no fees!  Instead, for update transactions (but 
not settlement transactions) we additionally give SIGHASH_SINGLE: thus, no 
matter what transaction they end up in, the signatures for the update 
transaction will always be verified against only the update transaction output 
that pays out to the update transaction script.  We join update transactions 
with a spend of some onchain UTXO we control, which pays for the fees of the 
joined the update transactions, and may have a second output that is the 
remainder of the fund after paying the fees.

11.  Settlement transactions can carry contracts (in much the same way that 
Poon-Dryja commitment transactions); however contracts that contain absolute 
timelock components will be affected by the CSV-encumberance of the settlement 
transaction.

---

Some pros and cons relative to Poon-Dryja (LN-penalty) channels:

- Requires more transactions in the worst-case: trigger, update, settlement.  
Compare to Poon-Dryja: commitment, claim.  Decker-Russell-Osuntokun channels 
can be trigger-settlement but only in the degenerate case where the channel was 
never