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

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

[Christian Decker]

(cross-posting to bitcoin-dev since this serves as motivation behind the
sighash_noinput proposal)

> TL;DR: we announce a new, simple, update mechanism for off-chain protocols,
> see the announcement [1] and the paper [2] :-)

A little over a year ago, the three Lightning Network implementation
teams joined forces to work on a common specification for the protocol
stack. Now that both that specification and our three implementations
are becoming stable and usable, it is time to look forward: to further
improve the protocol, to add new features, to simplify, and to fix
downsides.

One of the core innovations that enabled Lightning in the first place was an
off-chain update mechanism to renegotiate a new state and ensure that the old
state can not be settled on-chain. Today, we're excited to release our latest
research paper on a new, simplified, update mechanism for layer 2 protocols,
called eltoo.

eltoo is a drop-in replacement for the penalty based invalidation
mechanism that is used today in the Lightning specification. It is
similar in many ways to the sequence number mechanism that was already
present in the original Bitcoin implementation. But, while sequence
numbers were unenforceable on the blockchain, eltoo is enforceable by
overriding subsequent states on-chain.

Unlike the current mechanism used in Lightning so far, it is not penalty
based, i.e., publishing an old state does not result in the faulty node
to automatically lose funds, and is most similar to the duplex
micropayment channels construction. It is a symmetric scheme, i.e., all
participants share an identical set of transactions, and it ensures that the
last agreed upon state is settled on-chain, with similar tradeoffs as
today's Lightning (timelock vs. online requirement).

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. We
completely remove the need to estimate fees ahead of time. The
construction allows us to attach fees when settling, and even allows for
fees to be bumped using CPFP or RBF.

Beyond Lightning, eltoo can be used as a generic update mechanism for an
off-chain contract, for a larger number of participants. This was not
possible in the current update mechanism since reactions to a
misbehaving participant needed to be tailore to that participant. This
enables other protocols such as the channel factories, and in
combination with Schnorr signatures allows for very large off-chain
contracts with minimal on-chain footprint.

Before we can implement eltoo, we need a minor change to Bitcoin: the
introduction of the SIGHASH_NOINPUT flag for signatures. This was first
discussed a few months ago in the context of watchtowers to help secure
Lightning channels, but was not formally proposed. A formal proposal may
now be found in the eltoo paper.

We invite the community to consider our proposal and to participate in
its discussion. We hope to arrive at a consensus for the usage of
SIGHASH_NOINPUT, so that it can be accepted and included in a future
soft fork of Bitcoin Script. Doing so will put us on the road to a more
reliable and simpler Lightning Network, incorporating a new update
mechanism that can also be used for many other applications.

The full official announcement can be found at [1] and the paper with the full
details can be found at [2].

Looking forward to the communities feedback,
Christian

[1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
[2] https://blockstream.com/eltoo.pdf

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

[Jim Posen]

[-- Attachment #1: Type: text/plain, Size: 5250 bytes --]

This construction is pretty neat and seems to solve a lot of problems. I
find the use of CLTV with past timestamps to provide ordering in particular
to be quite clever.

If my understanding is correct though, this construction would
significantly increase the safe CLTV delta requirements because HTLCs
cannot be timed out immediately on the settlement transaction. Consider a
case where node B receives an HTLC from A and forwards to C. If the HTLC
offered to C times out and C does not fail the HTLC off-chain, Lightning
currently guarantees that the CLTV delta is sufficient that I may close the
channel to C on-chain and claim the timed-out HTLC before my upstream HTLC
to A times out. If the CLTV delta is too small, I may fail the upstream
HTLC as soon as it times out, and then C may still claim the downstream
HTLC with the preimage on-chain. With eltoo, when B closes the downstream
channel on-chain, it must wait the CSV timeout on the update transaction
before locking in the timed-out HTLC. This effectively means the CLTV delta
has to be greater than the CSV timeout, plus some extra (whereas it is
currently safe to make it significantly shorter). Is that true or am I
missing something?

On Mon, Apr 30, 2018 at 8:41 AM, Christian Decker via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> (cross-posting to bitcoin-dev since this serves as motivation behind the
> sighash_noinput proposal)
>
> > TL;DR: we announce a new, simple, update mechanism for off-chain
> protocols,
> > see the announcement [1] and the paper [2] :-)
>
> A little over a year ago, the three Lightning Network implementation
> teams joined forces to work on a common specification for the protocol
> stack. Now that both that specification and our three implementations
> are becoming stable and usable, it is time to look forward: to further
> improve the protocol, to add new features, to simplify, and to fix
> downsides.
>
> One of the core innovations that enabled Lightning in the first place was
> an
> off-chain update mechanism to renegotiate a new state and ensure that the
> old
> state can not be settled on-chain. Today, we're excited to release our
> latest
> research paper on a new, simplified, update mechanism for layer 2
> protocols,
> called eltoo.
>
> eltoo is a drop-in replacement for the penalty based invalidation
> mechanism that is used today in the Lightning specification. It is
> similar in many ways to the sequence number mechanism that was already
> present in the original Bitcoin implementation. But, while sequence
> numbers were unenforceable on the blockchain, eltoo is enforceable by
> overriding subsequent states on-chain.
>
> Unlike the current mechanism used in Lightning so far, it is not penalty
> based, i.e., publishing an old state does not result in the faulty node
> to automatically lose funds, and is most similar to the duplex
> micropayment channels construction. It is a symmetric scheme, i.e., all
> participants share an identical set of transactions, and it ensures that
> the
> last agreed upon state is settled on-chain, with similar tradeoffs as
> today's Lightning (timelock vs. online requirement).
>
> 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. We
> completely remove the need to estimate fees ahead of time. The
> construction allows us to attach fees when settling, and even allows for
> fees to be bumped using CPFP or RBF.
>
> Beyond Lightning, eltoo can be used as a generic update mechanism for an
> off-chain contract, for a larger number of participants. This was not
> possible in the current update mechanism since reactions to a
> misbehaving participant needed to be tailore to that participant. This
> enables other protocols such as the channel factories, and in
> combination with Schnorr signatures allows for very large off-chain
> contracts with minimal on-chain footprint.
>
> Before we can implement eltoo, we need a minor change to Bitcoin: the
> introduction of the SIGHASH_NOINPUT flag for signatures. This was first
> discussed a few months ago in the context of watchtowers to help secure
> Lightning channels, but was not formally proposed. A formal proposal may
> now be found in the eltoo paper.
>
> We invite the community to consider our proposal and to participate in
> its discussion. We hope to arrive at a consensus for the usage of
> SIGHASH_NOINPUT, so that it can be accepted and included in a future
> soft fork of Bitcoin Script. Doing so will put us on the road to a more
> reliable and simpler Lightning Network, incorporating a new update
> mechanism that can also be used for many other applications.
>
> The full official announcement can be found at [1] and the paper with the
> full
> details can be found at [2].
>
> Looking forward to the communities feedback,
> Christian
>
> [1] https://blockstream.com/2018/04/30/eltoo-next-lightning.html
> [2] https://blockstream.com/eltoo.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 6214 bytes --]

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

[ZmnSCPxj]

[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]

Good morning Jim,

> If my understanding is correct though, this construction would significantly increase the safe CLTV delta requirements because HTLCs cannot be timed out immediately on the settlement transaction. Consider a case where node B receives an HTLC from A and forwards to C. If the HTLC offered to C times out and C does not fail the HTLC off-chain, Lightning currently guarantees that the CLTV delta is sufficient that I may close the channel to C on-chain and claim the timed-out HTLC before my upstream HTLC to A times out. If the CLTV delta is too small, I may fail the upstream HTLC as soon as it times out, and then C may still claim the downstream HTLC with the preimage on-chain. With eltoo, when B closes the downstream channel on-chain, it must wait the CSV timeout on the update transaction before locking in the timed-out HTLC. This effectively means the CLTV delta has to be greater than the CSV timeout, plus some extra (whereas it is currently safe to make it significantly shorter). Is that true or am I missing something?

I believe this is quite true; indeed only the LN-penalty/Poon-Dryja channels do not have this drawback, as Decker-Wattenhofer invalidation trees also have the same drawback that the CSV and CLTV add up.

However the worst-case invalidation tree total CSV timeouts under Decker-Wattenhofer can grow quite massive; it seems the new eltoo Decker-Russell-Osuntokun CSV timeouts can be shorter.

Regards,
ZmnSCPxj

[-- Attachment #2: Type: text/html, Size: 1684 bytes --]

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

[Christian Decker]

Jim Posen <jim.posen@gmail.com> writes:
> If my understanding is correct though, this construction would
> significantly increase the safe CLTV delta requirements because HTLCs
> cannot be timed out immediately on the settlement transaction. Consider a
> case where node B receives an HTLC from A and forwards to C. If the HTLC
> offered to C times out and C does not fail the HTLC off-chain, Lightning
> currently guarantees that the CLTV delta is sufficient that I may close the
> channel to C on-chain and claim the timed-out HTLC before my upstream HTLC
> to A times out. If the CLTV delta is too small, I may fail the upstream
> HTLC as soon as it times out, and then C may still claim the downstream
> HTLC with the preimage on-chain. With eltoo, when B closes the downstream
> channel on-chain, it must wait the CSV timeout on the update transaction
> before locking in the timed-out HTLC. This effectively means the CLTV delta
> has to be greater than the CSV timeout, plus some extra (whereas it is
> currently safe to make it significantly shorter). Is that true or am I
> missing something?

That's a good point Jim. We need to make sure that the CLTVs are far
enough in the future for the CSV timeout to expire and to grab any
preimage downstream and insert it upstream. Overall this results in an
offset of all the CLTVs to (less than) the maximum CSV timeout along the
path. This would be a fixed offset for each channel and can be announced
using the gossip protocol, so senders can take it into consideration
when computing the routes. Notice that this is not really the CLTV
delta, which would accumulate along the path, but an offset on which the
CLTV deltas build on.

In today's network we have many nodes that have a CLTV delta of 144
blocks, which quickly results in HTLC funds unavailable for several days
depending on the route length, so I don't think that adding a fixed
offset is much worse. Once we have watch-towers we can reduce both the
offset as well as the CLTV deltas. Since eltoo makes watch-towers less
expensive, given the reduced storage costs, I'd argue that it's a net
positive for the Lightning network (but then again I'm biased) :-)

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

[Jim Posen]

[-- Attachment #1: Type: text/plain, Size: 2466 bytes --]

Can you explain why a fixed offset along the whole circuit is enough to
ensure safely as opposed to an increased delta at each hop?

On Tue, May 1, 2018, 5:05 AM Christian Decker <decker.christian@gmail.com>
wrote:

> Jim Posen <jim.posen@gmail.com> writes:
> > If my understanding is correct though, this construction would
> > significantly increase the safe CLTV delta requirements because HTLCs
> > cannot be timed out immediately on the settlement transaction. Consider a
> > case where node B receives an HTLC from A and forwards to C. If the HTLC
> > offered to C times out and C does not fail the HTLC off-chain, Lightning
> > currently guarantees that the CLTV delta is sufficient that I may close
> the
> > channel to C on-chain and claim the timed-out HTLC before my upstream
> HTLC
> > to A times out. If the CLTV delta is too small, I may fail the upstream
> > HTLC as soon as it times out, and then C may still claim the downstream
> > HTLC with the preimage on-chain. With eltoo, when B closes the downstream
> > channel on-chain, it must wait the CSV timeout on the update transaction
> > before locking in the timed-out HTLC. This effectively means the CLTV
> delta
> > has to be greater than the CSV timeout, plus some extra (whereas it is
> > currently safe to make it significantly shorter). Is that true or am I
> > missing something?
>
> That's a good point Jim. We need to make sure that the CLTVs are far
> enough in the future for the CSV timeout to expire and to grab any
> preimage downstream and insert it upstream. Overall this results in an
> offset of all the CLTVs to (less than) the maximum CSV timeout along the
> path. This would be a fixed offset for each channel and can be announced
> using the gossip protocol, so senders can take it into consideration
> when computing the routes. Notice that this is not really the CLTV
> delta, which would accumulate along the path, but an offset on which the
> CLTV deltas build on.
>
> In today's network we have many nodes that have a CLTV delta of 144
> blocks, which quickly results in HTLC funds unavailable for several days
> depending on the route length, so I don't think that adding a fixed
> offset is much worse. Once we have watch-towers we can reduce both the
> offset as well as the CLTV deltas. Since eltoo makes watch-towers less
> expensive, given the reduced storage costs, I'd argue that it's a net
> positive for the Lightning network (but then again I'm biased) :-)
>

[-- Attachment #2: Type: text/html, Size: 2960 bytes --]

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

[Christian Decker]

Jim Posen <jim.posen@gmail.com> writes:
> Can you explain why a fixed offset along the whole circuit is enough to
> ensure safely as opposed to an increased delta at each hop?

Sure. Let's assume we have chosen a path `A->B->C->D->E`. For simplicity
let's assume they all have a CLTV delta of 144 blocks (lnd's default
setting). Furthermore let's assume that the CSV timeout for the channels
is also 144.

This means that with the current LN-penalty mechanism you'd have the
following CLTV deltas in the HTLC:

```
A -(576)-> B -(432)-> C -(288)-> D -(144)-> E
```

Meaning that if the current time is approaching the absolute CLTV we
need initiate a channel closure to safely fetch the preimage on-chain,
and be able to turn around and send it on the upstream channel.

This is minimal, but can be arbitrarily higher, if you follow the best
practice of obfuscating the final destination by building a shadow route
behind the real recipient, and add it's CLTV deltas and fees to your
route.

With eltoo you'd need to make sure that you have the settlement
transaction confirmed before your desired CLTV timeout delta begins to
count down. So if the CLTV of the HTLC is `now + CSV timeout + CLTV
delta` you need to initiate a close, whereas Lightning allows you to
wait for time `now + CLTV delta`. Effectively this results in the
following time deltas:

```
A -(576+144)-> B -(432+144)-> C -(288+144)-> D -(144+144)-> E
```

Taking the last hop for example, if we had a CLTV of 1000 with eltoo
we'd need to start closing at height 712, instead of 856 with
LN-penalty. However, this increased delta does not accumulate along the
path, it's just a fixed offset. The longer the route, the smaller the
actual impact of this offset.

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

[Jim Posen]

[-- Attachment #1: Type: text/plain, Size: 2712 bytes --]

I'm still not following why this doesn't accumulate.

In the example route, let's look at it from the point of view of C. C sees
the following regardless of whether D or E or someone behind E is the last
hop in the route:

B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D

So D is not required to reveal the preimage before time X, and in the case
of an on-chain settle, C needs to be able to redeem the HTLC output through
the timeout clause before time X + delta. C can't redeem the HTLC (with
sufficient confirmations) at least until the settlement transaction is
confirmed. So it seems to me that regardless of the overall route and the
maximum CSV on it, the delta for the C hop has to be greater than the CSV
delay on the update transaction. And that this must be true at every hop
for the same reason.

On Tue, May 1, 2018 at 9:29 AM, Christian Decker <decker.christian@gmail.com
> wrote:

> Jim Posen <jim.posen@gmail.com> writes:
> > Can you explain why a fixed offset along the whole circuit is enough to
> > ensure safely as opposed to an increased delta at each hop?
>
> Sure. Let's assume we have chosen a path `A->B->C->D->E`. For simplicity
> let's assume they all have a CLTV delta of 144 blocks (lnd's default
> setting). Furthermore let's assume that the CSV timeout for the channels
> is also 144.
>
> This means that with the current LN-penalty mechanism you'd have the
> following CLTV deltas in the HTLC:
>
> ```
> A -(576)-> B -(432)-> C -(288)-> D -(144)-> E
> ```
>
> Meaning that if the current time is approaching the absolute CLTV we
> need initiate a channel closure to safely fetch the preimage on-chain,
> and be able to turn around and send it on the upstream channel.
>
> This is minimal, but can be arbitrarily higher, if you follow the best
> practice of obfuscating the final destination by building a shadow route
> behind the real recipient, and add it's CLTV deltas and fees to your
> route.
>
> With eltoo you'd need to make sure that you have the settlement
> transaction confirmed before your desired CLTV timeout delta begins to
> count down. So if the CLTV of the HTLC is `now + CSV timeout + CLTV
> delta` you need to initiate a close, whereas Lightning allows you to
> wait for time `now + CLTV delta`. Effectively this results in the
> following time deltas:
>
> ```
> A -(576+144)-> B -(432+144)-> C -(288+144)-> D -(144+144)-> E
> ```
>
> Taking the last hop for example, if we had a CLTV of 1000 with eltoo
> we'd need to start closing at height 712, instead of 856 with
> LN-penalty. However, this increased delta does not accumulate along the
> path, it's just a fixed offset. The longer the route, the smaller the
> actual impact of this offset.
>

[-- Attachment #2: Type: text/html, Size: 3798 bytes --]

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

[Christian Decker]

Jim Posen <jim.posen@gmail.com> writes:
> I'm still not following why this doesn't accumulate.
>
> In the example route, let's look at it from the point of view of C. C sees
> the following regardless of whether D or E or someone behind E is the last
> hop in the route:
>
> B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D
>
> So D is not required to reveal the preimage before time X, and in the case
> of an on-chain settle, C needs to be able to redeem the HTLC output through
> the timeout clause before time X + delta. C can't redeem the HTLC (with
> sufficient confirmations) at least until the settlement transaction is
> confirmed. So it seems to me that regardless of the overall route and the
> maximum CSV on it, the delta for the C hop has to be greater than the CSV
> delay on the update transaction. And that this must be true at every hop
> for the same reason.

That'd be a purely reactionary behavior, i.e., chosing the delta in such
a way that I can both settle the channel and have enough time to react
to turn around and reveal the preimage. So with the assumptions we had
before (CSV = 144 and CLTV delta = 144) you'd have an effective delta of
288 on each hop, yes. That's basically the case in which each channel
reacts serially.

You can trivially parallelize these closures by looking ahead and
noticing that each hop really just cares about its own closure deadline,
i.e., each node just cares to close 288 blocks before the CLTV expires,
not that its delta w.r.t. to the downstream channel is that far in the
future. So all we care about is that once we are due to give the
upstream hop the preimage we've already closed the downstream channel
and can now read the HTLC preimage from that channel.

The CSV timeout isn't part of the delta on each hop, but we need to
implement the deadline computation as:

```
CLTV - CLTV delta - CSV
```

instead of LN-penaltiy's

```
CLTV - CLTV delta
```

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

[Jim Posen]

[-- Attachment #1: Type: text/plain, Size: 4765 bytes --]

OK, I see what you are saying. You are effectively suggesting pipelining
the broadcasts of the update transactions. I think this introduces a
problem that a node in the circuit that withholds the preimage for too long
can force all upstream channels to be closed, at only the expense of their
one upstream channel being closed. I believe such an attack could
significantly disrupt the network.

Let me elaborate on the way I'm thinking about this:

So say I'm a routing node with an upstream HTLC with CLTV = X. I need to
ensure that if I learn the preimage, that I have time to broadcast and
confirm an HTLC-success transaction before height X. We'll call this number
of blocks D_success. So if I know the preimage, let's say X - D_success is
the latest height that I can safely broadcast the HTLC-success transaction,
assuming the settlement transaction is already final (ie. the update
transaction is confirmed and the CSV delay has passed). So now I also need
to know when to close the channel with the update transaction. I'll assume
it will take at most D_update blocks from the time I broadcast the update
transaction for it to be mined. So unless the downstream HTLC is already
failed, I should always close the upstream channel at height X - D_success
- CSV_update - D_update.

Now we'll look at the downstream HTLC with CLTV = Y. In order to minimize
the safe delta between the upstream and downstream CLTVs, I will want to
broadcast and confirm an HTLC-timeout transaction as soon after height Y as
possible. So assuming that the downstream settlement transaction is final
at height Y and it takes at most D_timeout blocks for the HTLC timeout
transaction to confirm once it is final assuming no double spends, then Y +
D_timeout is very latest I might learn the payment preimage from the
downstream channel on-chain. So I should be safe as long as X - D_success >
Y + D_timeout. This assumes that the update transaction for the downstream
channel is already mined and the CSV has passed. However, we know from
above that I had to close the upstream channel at time X - D_success -
CSV_update - D_update, which may very well be before Y. So if the
downstream hop waits until just before Y to publish the preimage, they can
force me to close my upstream channel. This applies transitively for
further upstream hops, assuming a large enough CSV value.

Granted, upstream hops can watch the blockchain for preimage reveals in
other closings transaction and perhaps fulfill off-chain if there is
sufficient time. This would not be possible with payment decorrelation
through scriptless scripts or the like.

Does that logic sound right to you?

On Tue, May 1, 2018 at 10:31 AM, Christian Decker <
decker.christian@gmail.com> wrote:

> Jim Posen <jim.posen@gmail.com> writes:
> > I'm still not following why this doesn't accumulate.
> >
> > In the example route, let's look at it from the point of view of C. C
> sees
> > the following regardless of whether D or E or someone behind E is the
> last
> > hop in the route:
> >
> > B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D
> >
> > So D is not required to reveal the preimage before time X, and in the
> case
> > of an on-chain settle, C needs to be able to redeem the HTLC output
> through
> > the timeout clause before time X + delta. C can't redeem the HTLC (with
> > sufficient confirmations) at least until the settlement transaction is
> > confirmed. So it seems to me that regardless of the overall route and the
> > maximum CSV on it, the delta for the C hop has to be greater than the CSV
> > delay on the update transaction. And that this must be true at every hop
> > for the same reason.
>
> That'd be a purely reactionary behavior, i.e., chosing the delta in such
> a way that I can both settle the channel and have enough time to react
> to turn around and reveal the preimage. So with the assumptions we had
> before (CSV = 144 and CLTV delta = 144) you'd have an effective delta of
> 288 on each hop, yes. That's basically the case in which each channel
> reacts serially.
>
> You can trivially parallelize these closures by looking ahead and
> noticing that each hop really just cares about its own closure deadline,
> i.e., each node just cares to close 288 blocks before the CLTV expires,
> not that its delta w.r.t. to the downstream channel is that far in the
> future. So all we care about is that once we are due to give the
> upstream hop the preimage we've already closed the downstream channel
> and can now read the HTLC preimage from that channel.
>
> The CSV timeout isn't part of the delta on each hop, but we need to
> implement the deadline computation as:
>
> ```
> CLTV - CLTV delta - CSV
> ```
>
> instead of LN-penaltiy's
>
> ```
> CLTV - CLTV delta
> ```
>

[-- Attachment #2: Type: text/html, Size: 5516 bytes --]

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

[Olaoluwa Osuntokun]

[-- Attachment #1: Type: text/plain, Size: 7668 bytes --]

Hi Jimpo,

You're correct that the introduction of symmetric state now re-introduces
the
dependency between the CSV value of the commitment, and the HTLC timeouts.
It's
worth nothing that this issue existed in an earlier version of the BOLT
spec,
this was pointed out by Mats in the past: [1][2]. The dependency meant that
if
we wanted to allow very long CSV time outs (like 1 month +), then this would
have the adverse effect of increasing the total CLTV timeout along the
entire
route. As a result, we moved to the 2-stage HTLC scheme which is now
implemented and deployed as a part of BOLT 1.0. It may be the case that in
the
mid to near future, most implementations aren't concerned about long time
locks
due to the existence of robust and reliable private outsourcers.

As a side effect of the way the symmetric state changes the strategy around
breach attempts, we may see more breach attempts (and therefore update
transactions) on the chain since attempting to cheat w/ vanilla symmetric
state
is now "costless" (worst case we just use the latest state, best case I can
commit the state better for me. This is in stark contrast to
punishment/slashing based approaches where a failed breach attempt results
in
the cheating party losing all their funds.

However, with a commitment protocol that uses symmetric state. The 2-stage
HTLC
scheme doesn't actually apply. Observe that with Lighting's current
asymmetric
state commitment protocol, the "clock" starts ticking as soon as the
commitment
hits the chain, and we follow the "if an output pays to me, it must be
delayed
as I may be attempting a breach". With symmetric state this no longer
applies,
the clock instead starts "officially" ticking after the latest update
transaction has hit the chain, and there are no further challenges. As a
result
of this, the commitment transaction itself doesn't need to have any CSV
delays
within the Script branches of the outputs it creates. Instead, each of those
outputs can be immediately be spent as the challenge period has already
elapsed,
and from the PoV of the chain, this is now the "correct" commitment. Due to
this, the HTLC outputs would now be symmetric themselves, and look very much
like an HTLC output that one would use in a vanilla on-chain cross-chain
atomic
swap.

[1]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000182.html
[2]:
https://lists.linuxfoundation.org/pipermail/lightning-dev/2015-November/000339.html


On Tue, May 1, 2018 at 6:15 PM Jim Posen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> OK, I see what you are saying. You are effectively suggesting pipelining
> the broadcasts of the update transactions. I think this introduces a
> problem that a node in the circuit that withholds the preimage for too long
> can force all upstream channels to be closed, at only the expense of their
> one upstream channel being closed. I believe such an attack could
> significantly disrupt the network.
>
> Let me elaborate on the way I'm thinking about this:
>
> So say I'm a routing node with an upstream HTLC with CLTV = X. I need to
> ensure that if I learn the preimage, that I have time to broadcast and
> confirm an HTLC-success transaction before height X. We'll call this number
> of blocks D_success. So if I know the preimage, let's say X - D_success is
> the latest height that I can safely broadcast the HTLC-success transaction,
> assuming the settlement transaction is already final (ie. the update
> transaction is confirmed and the CSV delay has passed). So now I also need
> to know when to close the channel with the update transaction. I'll assume
> it will take at most D_update blocks from the time I broadcast the update
> transaction for it to be mined. So unless the downstream HTLC is already
> failed, I should always close the upstream channel at height X - D_success
> - CSV_update - D_update.
>
> Now we'll look at the downstream HTLC with CLTV = Y. In order to minimize
> the safe delta between the upstream and downstream CLTVs, I will want to
> broadcast and confirm an HTLC-timeout transaction as soon after height Y as
> possible. So assuming that the downstream settlement transaction is final
> at height Y and it takes at most D_timeout blocks for the HTLC timeout
> transaction to confirm once it is final assuming no double spends, then Y +
> D_timeout is very latest I might learn the payment preimage from the
> downstream channel on-chain. So I should be safe as long as X - D_success >
> Y + D_timeout. This assumes that the update transaction for the downstream
> channel is already mined and the CSV has passed. However, we know from
> above that I had to close the upstream channel at time X - D_success -
> CSV_update - D_update, which may very well be before Y. So if the
> downstream hop waits until just before Y to publish the preimage, they can
> force me to close my upstream channel. This applies transitively for
> further upstream hops, assuming a large enough CSV value.
>
> Granted, upstream hops can watch the blockchain for preimage reveals in
> other closings transaction and perhaps fulfill off-chain if there is
> sufficient time. This would not be possible with payment decorrelation
> through scriptless scripts or the like.
>
> Does that logic sound right to you?
>
> On Tue, May 1, 2018 at 10:31 AM, Christian Decker <
> decker.christian@gmail.com> wrote:
>
>> Jim Posen <jim.posen@gmail.com> writes:
>> > I'm still not following why this doesn't accumulate.
>> >
>> > In the example route, let's look at it from the point of view of C. C
>> sees
>> > the following regardless of whether D or E or someone behind E is the
>> last
>> > hop in the route:
>> >
>> > B -> HTLC(expire = X + delta) -> C -> HTLC(expire = X) -> D
>> >
>> > So D is not required to reveal the preimage before time X, and in the
>> case
>> > of an on-chain settle, C needs to be able to redeem the HTLC output
>> through
>> > the timeout clause before time X + delta. C can't redeem the HTLC (with
>> > sufficient confirmations) at least until the settlement transaction is
>> > confirmed. So it seems to me that regardless of the overall route and
>> the
>> > maximum CSV on it, the delta for the C hop has to be greater than the
>> CSV
>> > delay on the update transaction. And that this must be true at every hop
>> > for the same reason.
>>
>> That'd be a purely reactionary behavior, i.e., chosing the delta in such
>> a way that I can both settle the channel and have enough time to react
>> to turn around and reveal the preimage. So with the assumptions we had
>> before (CSV = 144 and CLTV delta = 144) you'd have an effective delta of
>> 288 on each hop, yes. That's basically the case in which each channel
>> reacts serially.
>>
>> You can trivially parallelize these closures by looking ahead and
>> noticing that each hop really just cares about its own closure deadline,
>> i.e., each node just cares to close 288 blocks before the CLTV expires,
>> not that its delta w.r.t. to the downstream channel is that far in the
>> future. So all we care about is that once we are due to give the
>> upstream hop the preimage we've already closed the downstream channel
>> and can now read the HTLC preimage from that channel.
>>
>> The CSV timeout isn't part of the delta on each hop, but we need to
>> implement the deadline computation as:
>>
>> ```
>> CLTV - CLTV delta - CSV
>> ```
>>
>> instead of LN-penaltiy's
>>
>> ```
>> CLTV - CLTV delta
>> ```
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

[-- Attachment #2: Type: text/html, Size: 9418 bytes --]

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

[Christian Decker]

Olaoluwa Osuntokun via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> writes:

> Hi Jimpo,
>
> You're correct that the introduction of symmetric state now
> re-introduces the dependency between the CSV value of the commitment,
> and the HTLC timeouts.  It's worth nothing that this issue existed in
> an earlier version of the BOLT spec, this was pointed out by Mats in
> the past: [1][2]. The dependency meant that if we wanted to allow very
> long CSV time outs (like 1 month +), then this would have the adverse
> effect of increasing the total CLTV timeout along the entire route. As
> a result, we moved to the 2-stage HTLC scheme which is now implemented
> and deployed as a part of BOLT 1.0. It may be the case that in the mid
> to near future, most implementations aren't concerned about long time
>  locks due to the existence of robust and reliable private
> outsourcers.

It's worth mentioning that the requirement for extremely large CLTV deltas
would already create incredibly long CLTV deltas between the endpoints,
since the endpoint delta accumulates along the path. This is true for
LN-Penalty as well as eltoo. eltoo's requirement to settle before the
HTLCs touch the blockchain adds a stage in which need to start on-chain
settlement to ensure the HTLC hits the chain before its CLTV
expires. We can imagine this as a separate timewindow, that does not
accumulate across multiple hops (settlement ordering is not an issue,
CLTV resolution is).

My hope is that indeed with the simpler watch-towers we can reduce both
the CLTV deltas as well as the settlement timeouts for eltoo, so that
they become negligible.

> As a side effect of the way the symmetric state changes the strategy
> around breach attempts, we may see more breach attempts (and therefore
> update transactions) on the chain since attempting to cheat w/ vanilla
> symmetric state is now "costless" (worst case we just use the latest
> state, best case I can commit the state better for me. This is in
> stark contrast to punishment/slashing based approaches where a failed
> breach attempt results in the cheating party losing all their funds.

Not exactly costless, since the breaching party will have to pay the
on-chain fees, and we may be able to reintroduce the reserve in order to
add an additional punishment on top of the simple update mechanism
(selectively introducing asymmetry).

> However, with a commitment protocol that uses symmetric state. The
> 2-stage HTLC scheme doesn't actually apply. Observe that with
> Lighting's current asymmetric state commitment protocol, the "clock"
> starts ticking as soon as the commitment hits the chain, and we follow
> the "if an output pays to me, it must be delayed as I may be
> attempting a breach". With symmetric state this no longer applies, the
> clock instead starts "officially" ticking after the latest update
> transaction has hit the chain, and there are no further challenges. As
> a result of this, the commitment transaction itself doesn't need to
> have any CSV delays within the Script branches of the outputs it
> creates. Instead, each of those outputs can be immediately be spent as
> the challenge period has already elapsed, and from the PoV of the
> chain, this is now the "correct" commitment. Due to this, the HTLC
> outputs would now be symmetric themselves, and look very much like an
> HTLC output that one would use in a vanilla on-chain cross-chain
> atomic swap.

In addition to this it is worth pointing out that the old/replaced HTLCs
have no way of ever touching the blockchain, so we can throw away a
whole heap of data about these HTLCs, that we would have to carry around
indefinitely if this were not the case. The same reason the HTLCs start
ticking when a settlement touches the chain in LN-penalty is also the
reason we need to carry all that data around. eltoo can be said to
contain the two stage HTLC commit we added on top of LN-penalty.

Cheers,
Christian

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

[ZmnSCPxj]

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

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

[Christian Decker]

ZmnSCPxj <ZmnSCPxj@protonmail.com> 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.

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

[Rusty Russell]

"David A. Harding" <dave@dtrt.org> writes:
> On Tue, Jun 19, 2018 at 02:02:51PM -0400, David A. Harding wrote:
>> Anyone can rewrite a SIGHASH_NOINPUT input's outpoint, but the actual
>> transaction containing the settlement is expected to have (at least) two
>> inputs, with the second one originating the fees.  That second input's
>> signature is (I assume) using SIGHASH_ALL to commit to all outpoints in
>> the transaction, so it can't be arbitrarily rewritten by a third-party
>> to apply to a different state outpoint
>
> I realized that the fee-paying input could possibly be signed with
> SIGHASH_ALL|SIGHASH_ANYONECANPAY to allow anyone to arbitrarily
> rewrite the other input signed with SIGHASH_NOINPUT.  However, this
> reminded me of the well-known DoS against transactions signed with
> SIGHASH_ANYONECANPAY[1], which seems to apply generally against
> SIGHASH_NOINPUT as well and may allow theft from HTLCs.

Yes, RBF Rule #3 again :( It makes RBF unusable in adversarial
conditions, and it's not miner incentive-compatible.

The only mitigations I have been able to come up with are:

1. Reduce the RBF grouping depth to 2, not 10.  This doesn't help
   here though, since you can still have ~infinite fan-out of txs
   (create 1000 outputs, spend each with a 400ksipa tx).

2. Revert #3 to a simple "greater feerate" rule, but delay propagation
   proportional to tx weight, say 60 seconds (fuzzed) for a 400 ksipa
   tx.  That reduces your ability to spam the network (you can always
   connect directly to nodes and waste their time and bandwidth, but you
   can do that pretty much today).

Frankly, I'd also like a similar mechanism to not reject low-fee txs
(above 250 satoshi per ksipa) but simply not propagate them.  Drop them
after 60 seconds if there's no CPFP to increase their effective feerate.
That would allow us to use CPFP on lightning commitment txs today,
without having to guess what fees will be sometime in the future.

Cheers,
Rusty.

> ## DoS against Eltoo settlements
>
> Alice and Mallory have a channel with some state updates.  Alice tries
> to initiate a cooperate close, but Mallory stalls and instead broadcasts
> the trigger transaction and the first state (state 0).  Notably, the
> first state is bundled into a very large vsize transaction with a low
> feerate.  State 1 is added to another very large low-feerate
> transaction, as are states 2 through 9. 
>
> Alice could in theory RBF the state 0 transaction, but per BIP125 rule
> #3, she needs to pay an absolute fee greater than all the transactions
> being replaced (not just a higher feerate).  That could cost a lot.
> Alice could also create a transaction that binds the final state to the
> state 9 transaction and attempt CPFP, but increasing the feerate for the
> transaction ancestor group to a satisfactory degree would cost the same
> amount as RBF.
>
> So Alice is stuck waiting for states 0-9 to confirm before the final
> state can be confirmed.  During recent periods of full mempools on
> default nodes, the waiting time for 10 nBTC/vbyte transactions has been
> more than two weeks.
>
> ## HTLC theft
>
> If Mallory is able to introduce significant settlement delays, HTLC
> security is compromised.  For example, imagine this route:
>
>     Mallory <-> Alice <-> Bob
>
> Mallory orders a widget from Bob and pays via LN by sending 1 BTC to
> Alice hashlocked and timelocked, which Alice forwards to Bob also
> hashlocked and timelocked.  Mallory releases the preimage to Bob, who
> claims the funds from Alice and ships the widget, giving Alice the
> preimage.
>
> At this point, Mallory broadcasts the transactions described in the
> preceding section.
>
> If the low feerate of states 0-9 prevent them from confirming before the
> timeout, Mallory can create a transaction containing a dishonest final
> state that executes the refund branch.  Like before, she can bury this
> in an ancestor transaction chain that would be cost prohibitive for Alice
> to RBF.
>
> Considered independently, this is a very expensive attack for Mallory,
> and so perhaps impractical.  But Mallory can join forces with someone
> already creating large low-feerate consolidation transactions.  Better
> yet, from Mallory's perspective, she can execute the attack against
> hundreds of channels at once (creating long chains of ancestor
> transactions that are large in aggregate rather than individually
> large), using the aggregate size of all the victims' channels against
> each of the individual victims.
>
> Thanks,
>
> -Dave
>
> [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-August/006438.html
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev