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

[Anthony Towns]

On 13 October 2018 7:12:03 pm GMT+09:00, Christian Decker 
 wrote:
>Great find ZmnSCPxj, we can also have an adaptive scheme here, in which
>we
>start with a single update transaction, and then at ~90% of the
>available
>range we add a second. This is starting to look a bit like the DMC
>invalidation tree :-)
>But realistically speaking I don't think 1B updates is going to be
>exhausted any time soon, but the adaptive strategy gets the best of
>both worlds.
>
>Cheers,
>Christian
>
>On Fri, Oct 12, 2018 at 5:21 AM ZmnSCPxj 
>wrote:
>
>> Another way would be to always have two update transactions,
>effectively
>> creating a larger overall counter:
>>
>> [anchor] -> [update highbits] -> [update lobits] -> [settlement]
>>
>> We normally update [update lobits] until it saturates.  If lobits
>> saturates we increment [update highbits] and reset [update lobits] to
>the
>> lowest valid value.
>>
>> This will provide a single counter with 10^18 possible updates, which
>> should be enough for a while even without reanchoring.
>>
>> Regards,
>> ZmnSCPxj
>>
>>
>> Sent with ProtonMail  Secure Email.
>>
>> ‐‐‐ Original Message ‐‐‐
>> On Friday, October 12, 2018 1:37 AM, Christian Decker <
>> decker.christ...@gmail.com> wrote:
>>
>> Thanks Anthony for pointing this out, I was not aware we could
>> roll keypairs to reset the state numbers.
>>
>> I basically thought that 1billion updates is more than I would
>> ever do, since with splice-in / splice-out operations we'd be
>> re-anchoring on-chain on a regular basis anyway.
>>
>>
>>
>> On Wed, Oct 10, 2018 at 10:25 AM Anthony Towns 
>wrote:
>>
>>> On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
>>> > eltoo is a drop-in replacement for the penalty based invalidation
>>> > mechanism that is used today in the Lightning specification. [...]
>>>
>>> Maybe this is obvious, but in case it's not, re: the locktime-based
>>> sequencing in eltoo:
>>>
>>>  "any number above 0.500 billion is interpreted as a UNIX timestamp,
>and
>>>   with a current timestamp of ~1.5 billion, that leaves about 1
>billion
>>>   numbers that are interpreted as being in the past"
>>>
>>> I think if you had a more than a 1B updates to your channel (50
>updates
>>> per second for 4 months?) I think you could reset the locktime by
>rolling
>>> over to use new update keys. When unilaterally closing you'd need to
>>> use an extra transaction on-chain to do that roll-over, but you'd
>save
>>> a transaction if you did a cooperative close.
>>>
>>> ie, rather than:
>>>
>>>   [funding] -> [coop close / re-fund] -> [update 23M] -> [HTLCs etc]
>>> or
>>>   [funding] -> [coop close / re-fund] -> [coop close]
>>>
>>> you could have:
>>>   [funding] -> [update 1B] -> [update 23,310,561 with key2] ->
>[HTLCs]
>>> or
>>>   [funding] -> [coop close]
>>>
>>> You could repeat this when you get another 1B updates, making
>unilateral
>>> closes more painful, but keeping cooperative closes cheap.
>>>
>>> Cheers,
>>> aj
>>>
>>>
>>

Hmm - the range grows by one every second though, so as long as you don't go 
through a billion updates per second, you can go to 100% of the range, knowing 
that by the time you have to increment, you'll have 115% of the original range 
available, meaning you never need more than two transactions (until locktime 
overflows anyway) for the commitment, even at 900MHz transaction rates...

Cheers,
aj

-- 
Sent from my phone.
___
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]

Great find ZmnSCPxj, we can also have an adaptive scheme here, in which we
start with a single update transaction, and then at ~90% of the available
range we add a second. This is starting to look a bit like the DMC
invalidation tree :-)
But realistically speaking I don't think 1B updates is going to be
exhausted any time soon, but the adaptive strategy gets the best of
both worlds.

Cheers,
Christian

On Fri, Oct 12, 2018 at 5:21 AM ZmnSCPxj  wrote:

> Another way would be to always have two update transactions, effectively
> creating a larger overall counter:
>
> [anchor] -> [update highbits] -> [update lobits] -> [settlement]
>
> We normally update [update lobits] until it saturates.  If lobits
> saturates we increment [update highbits] and reset [update lobits] to the
> lowest valid value.
>
> This will provide a single counter with 10^18 possible updates, which
> should be enough for a while even without reanchoring.
>
> Regards,
> ZmnSCPxj
>
>
> Sent with ProtonMail  Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
> On Friday, October 12, 2018 1:37 AM, Christian Decker <
> decker.christ...@gmail.com> wrote:
>
> Thanks Anthony for pointing this out, I was not aware we could
> roll keypairs to reset the state numbers.
>
> I basically thought that 1billion updates is more than I would
> ever do, since with splice-in / splice-out operations we'd be
> re-anchoring on-chain on a regular basis anyway.
>
>
>
> On Wed, Oct 10, 2018 at 10:25 AM Anthony Towns  wrote:
>
>> On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
>> > eltoo is a drop-in replacement for the penalty based invalidation
>> > mechanism that is used today in the Lightning specification. [...]
>>
>> Maybe this is obvious, but in case it's not, re: the locktime-based
>> sequencing in eltoo:
>>
>>  "any number above 0.500 billion is interpreted as a UNIX timestamp, and
>>   with a current timestamp of ~1.5 billion, that leaves about 1 billion
>>   numbers that are interpreted as being in the past"
>>
>> I think if you had a more than a 1B updates to your channel (50 updates
>> per second for 4 months?) I think you could reset the locktime by rolling
>> over to use new update keys. When unilaterally closing you'd need to
>> use an extra transaction on-chain to do that roll-over, but you'd save
>> a transaction if you did a cooperative close.
>>
>> ie, rather than:
>>
>>   [funding] -> [coop close / re-fund] -> [update 23M] -> [HTLCs etc]
>> or
>>   [funding] -> [coop close / re-fund] -> [coop close]
>>
>> you could have:
>>   [funding] -> [update 1B] -> [update 23,310,561 with key2] -> [HTLCs]
>> or
>>   [funding] -> [coop close]
>>
>> You could repeat this when you get another 1B updates, making unilateral
>> closes more painful, but keeping cooperative closes cheap.
>>
>> Cheers,
>> aj
>>
>>
>
___
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]

Another way would be to always have two update transactions, effectively 
creating a larger overall counter:

[anchor] -> [update highbits] -> [update lobits] -> [settlement]

We normally update [update lobits] until it saturates.  If lobits saturates we 
increment [update highbits] and reset [update lobits] to the lowest valid value.

This will provide a single counter with 10^18 possible updates, which should be 
enough for a while even without reanchoring.

Regards,
ZmnSCPxj

Sent with [ProtonMail](https://protonmail.com) Secure Email.

‐‐‐ Original Message ‐‐‐
On Friday, October 12, 2018 1:37 AM, Christian Decker 
 wrote:

> Thanks Anthony for pointing this out, I was not aware we could
> roll keypairs to reset the state numbers.
>
> I basically thought that 1billion updates is more than I would
> ever do, since with splice-in / splice-out operations we'd be
> re-anchoring on-chain on a regular basis anyway.
>
> On Wed, Oct 10, 2018 at 10:25 AM Anthony Towns  wrote:
>
>> On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
>>> eltoo is a drop-in replacement for the penalty based invalidation
>>> mechanism that is used today in the Lightning specification. [...]
>>
>> Maybe this is obvious, but in case it's not, re: the locktime-based
>> sequencing in eltoo:
>>
>>  "any number above 0.500 billion is interpreted as a UNIX timestamp, and
>>   with a current timestamp of ~1.5 billion, that leaves about 1 billion
>>   numbers that are interpreted as being in the past"
>>
>> I think if you had a more than a 1B updates to your channel (50 updates
>> per second for 4 months?) I think you could reset the locktime by rolling
>> over to use new update keys. When unilaterally closing you'd need to
>> use an extra transaction on-chain to do that roll-over, but you'd save
>> a transaction if you did a cooperative close.
>>
>> ie, rather than:
>>
>>   [funding] -> [coop close / re-fund] -> [update 23M] -> [HTLCs etc]
>> or
>>   [funding] -> [coop close / re-fund] -> [coop close]
>>
>> you could have:
>>   [funding] -> [update 1B] -> [update 23,310,561 with key2] -> [HTLCs]
>> or
>>   [funding] -> [coop close]
>>
>> You could repeat this when you get another 1B updates, making unilateral
>> closes more painful, but keeping cooperative closes cheap.
>>
>> Cheers,
>> aj___
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]

Thanks Anthony for pointing this out, I was not aware we could
roll keypairs to reset the state numbers.

I basically thought that 1billion updates is more than I would
ever do, since with splice-in / splice-out operations we'd be
re-anchoring on-chain on a regular basis anyway.


On Wed, Oct 10, 2018 at 10:25 AM Anthony Towns  wrote:

> On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
> > eltoo is a drop-in replacement for the penalty based invalidation
> > mechanism that is used today in the Lightning specification. [...]
>
> Maybe this is obvious, but in case it's not, re: the locktime-based
> sequencing in eltoo:
>
>  "any number above 0.500 billion is interpreted as a UNIX timestamp, and
>   with a current timestamp of ~1.5 billion, that leaves about 1 billion
>   numbers that are interpreted as being in the past"
>
> I think if you had a more than a 1B updates to your channel (50 updates
> per second for 4 months?) I think you could reset the locktime by rolling
> over to use new update keys. When unilaterally closing you'd need to
> use an extra transaction on-chain to do that roll-over, but you'd save
> a transaction if you did a cooperative close.
>
> ie, rather than:
>
>   [funding] -> [coop close / re-fund] -> [update 23M] -> [HTLCs etc]
> or
>   [funding] -> [coop close / re-fund] -> [coop close]
>
> you could have:
>   [funding] -> [update 1B] -> [update 23,310,561 with key2] -> [HTLCs]
> or
>   [funding] -> [coop close]
>
> You could repeat this when you get another 1B updates, making unilateral
> closes more painful, but keeping cooperative closes cheap.
>
> Cheers,
> aj
>
>
___
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

[Anthony Towns]

(bitcoin-dev dropped from cc)

On Mon, Apr 30, 2018 at 05:41:38PM +0200, Christian Decker wrote:
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. [...]

I think you can simplify eltoo further, both in the way the transactions
work and in the game theory ensuring people play fair.

In essence: rather than having a funding transaction spending to address
"X", and a set of ratcheting states that spend from-and-to the same
address "X", I think it's feasible to have a simpler ratchet mechanism:

  (1) funding address: multisig by A and B as usual

  (2) commit to state >=N by A

  (3a) commit to state N by A after delay D; or
  (3b) commit to state M (M>=N) by B

I believe those transactions (while partially signed, before posting to
the blockchain) would look like:

  (1) pay to "2 A1 B1 2 OP_CHECKMULTISIG"

  (2) signed by B1, nlocktime set to (N+E)
  pay to "(N+E) OP_CLTV OP_DROP 2 A2a B2a 2 OP_CHECKMULTISIG"

  (3a) signed by B2a, nSequence set to the channel pay to self delay,
   nlocktime set to (N+E)
   pays to the channel balances / HTLCs, with no delays or
   revocation clauses

  (3b) signed by A2a with SIGHASH_NOINPUT_UNSAFE, nlocktime set to (M+E)
   pays to the channel balances / HTLCs, with no delays or
   revocation clauses

You spend (2)+delay+(3a)+[claim balance/HTLC] if your counterparty
goes away.  You spend (2) and your counterparty spends (3b) if you're
both monitoring the blockchain. (3a) and (3b) should have the same tx
size, fee rate and outputs.

(A1, A2a are keys held by A; B1, B2a are keys held by B; E is
LOCKTIME_THRESHOLD; N is the current state number)

That seems like it has a few nice features:

 - txes at (3a) and (3b) can both pay current market fees with minimal
   risk, and can be CPFPed by a tx spending your own channel balance

 - txes at (2) can pay a non-zero fee, provided it's constant for the
   lifetime of the channel (to conform with the NOINPUT rules)

 - if both parties are monitoring the blockchain, then the channel
   can be fully closed in a single block, by (2)+(3b)+[balance/HTLC
   claims], and the later txes can do CPFP for tx (2).

 - both parties can claim their funds as soon as the other can, no
   matter who initiates the close

 - you only need 3 pre-signed txes for the current state; the txes
   for claiming HTLCs/balances don't need to be half-signed (unless
   you're doing them via schnorr scriptless scripts etc)

The game theory looks fine to me. If you're posting transaction (2), then
you can choose between a final state F, paying you f and your counterparty
b-f, or some earlier state N, paying you n, and your counterparty b-n. If
f>n, it makes sense for you to choose F, in which case your counterparty
is also forced to choose state F for (3b) and you're forced to choose F
for (3a). If n>f, then if you choose N, your counterparty will either
choose state F because b-f>b-n and you will receive f as before, or
will choose some other state M>N, where b-m>b-f, and you will receive
m eltoo addresses some of the issues we encountered while speficying and
> implementing the Lightning Network. For example outsourcing becomes very
> simple since old states becoming public can't hurt us anymore.

The scheme above isn't great for (untrusted) outsourcing, because if
you reveal enough for an adversary to post tx (3b) for state N, then
they can then collaborate with your channel counterparty to roll you
back from state N+1000 back to state N.

With eltoo if they do the same, then you have the opportunity to catch
them at it, and play state N+1000 to the blockchain -- but if you're
monitoring the blockchain carefully enough to catch that, why are you
outsourcing in the first place? If you're relying on multiple outsourcers
to keep each other honest, then I think you run into challenges paying
them to publish the txes for you.

Thoughts? Apart from still requiring NOINPUT and not working with
adversarial outsourcing, this seems like it works nicely to me, but
maybe I missed something...

Cheers,
aj

___
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]

Good morning Carsten,

> > The setup transaction is simply a transaction that spends some funds and
> > 
> > creates a single output, which has the script from Figure 2, but since
> > 
> > that would be a forward reference, I decided to handwave and call it a
> > 
> > multisig. A simple fix would be to change the setup phase bullet point
> > 
> > at the beginning of section 3, would that be sufficient?
> 
> A first clarification, which just regards the naming, would be to use
> 
> just one of "setup transaction" and "funding transaction".

Calling it "funding transaction" is my fault, as I prefer that term since it 
matches in spirit the funding transaction in LN-penalty (Poon-Dryja).

> The symbol
> 
> T_{u,0} is only used once, on page 6. I'd either remove it, or used it
> 
> in other places (Fig. 1?), too.
> 
> Without your mail (thanks!) I did not see that the setup transaction
> 
> output is complicated (has branches) as shown in Fig. 2. A clarification
> 
> at the named bullet point would indeed help (although I see the issue of
> 
> forward references).
> 
> One idea (just to get my idea across, I'm sure you can do better):
> 
> old: "to a 2-of-2 multisig address"
> 
> new: "to a script making use of 2-of-2 multisig"

Note, that when we add the trigger transaction later in the paper, the funding 
transaction output becomes an ordinary 2-of-2 multisig address.  The complex 
script becomes relegated to the output of the trigger transaction.

So in the final design of eltoo, the funding transaction output is indeed a 
2-of-2 multisig.

This is useful as the mutual close transaction (what the paper calls a "final 
settlement" transaction) just spends an ordinary 2-of-2 multisig and thus has a 
greater anonymity set, i.e. it prevents blockchain analysis from realizing that 
it was actually a channel (unless, of course, it was also tracking gossip from 
LN).

> 
> > If instead of calling it a multisig we call it a multiparty output and
> > 
> > reference the script in Figure 2, that'd be addressed as well.
> 
> I agree.
> 
> > Well, it has arbitrary inputs, and a single output with the script from
> > 
> > Figure 2, in the non-trigger case, and in the trigger case it'd be just
> > 
> > a `2 A B 2 OP_CMSV`.
> 
> Got it. Follow up question: would a second output (change) be OK? I see
> 
> some advantages, but I'm not sure if it would work.

Yes, it definitely would be OK.  In fact, it is good to talk about funding 
outpoints rather than funding transactions.  It is possible for a single 
Bitcoin transaction to serve as an anchor for several channels at once, and the 
BOLT spec supports this (but I know of no implementation that actually 
implements this).  Basically, the funding outpoint is some transaction output 
that pays to a 2-of-2 multisig and which will be spent using some offchain 
mechanism, or a mutual close transaction --- this is what I call the "funding 
transaction pattern".

Regards,
ZmnSCPxj

> 
> Thanks
> 
> Carsten
> 
> 
> -
> 
> andrena objects ag
> 
> Ganghoferstraße 70
> 
> 80339 München
> 
> http://www.andrena.de
> 
> Vorstand: Hagen Buchwald, Dr. Dieter Kuhn, Stefan Schürle
> 
> Aufsichtsratsvorsitzender: Rolf Hetzelberger
> 
> Sitz der Gesellschaft: Karlsruhe
> 
> Amtsgericht Mannheim, HRB 109694
> 
> USt-IdNr. DE174314824
> 
> Bitte beachten Sie auch unsere anstehenden Veranstaltungen:
> 
> http://www.andrena.de/events


___
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]

Carsten Otto  writes:
> the paper is a bit confusing regarding the setup transaction, as it is
> not described formally. There also seems to be a mixup of "setup
> transaction" and "funding transaction", also named T_{u,0} without
> showing it in the diagrams.

The setup transaction is simply a transaction that spends some funds and
creates a single output, which has the script from Figure 2, but since
that would be a forward reference, I decided to handwave and call it a
multisig. A simple fix would be to change the setup phase bullet point
at the beginning of section 3, would that be sufficient?

> In 3.1 the funding transaction is described as funding "to a multisig
> address". In the description of trigger transactions the change is
> described as "The output from the setup transaction is changed into a
> simple 2-of-2 multisig output" - which it already is?

If instead of calling it a multisig we call it a multiparty output and
reference the script in Figure 2, that'd be addressed as well.

> As far as I understand the situation, the trigger transaction is needed
> because the broadcasted initial/funding/setup transaction includes an
> OP_CLV, which then starts the timer and could lead to premature
> settlement. Removing OP_CLV (and having in a transaction that is only
> published later when it is needed), i.e. by changing it to a simple
> multisig output, seems to solve this issue.
>
> Could you (Christian?) explain how the "setup transaction" is supposed
> to look like without the changes described in section 4.2?

Well, it has arbitrary inputs, and a single output with the script from
Figure 2, in the non-trigger case, and in the trigger case it'd be just
a `2 A B 2 OP_CMSV`.
___
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]

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 

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

[ZmnSCPxj via Lightning-dev]

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

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