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

[Christian Decker via bitcoin-dev]

Olaoluwa Osuntokun via bitcoin-dev
 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jim Posen via bitcoin-dev]

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.christ...@gmail.com> wrote:

> Jim Posen  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

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

[Jim Posen via bitcoin-dev]

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  wrote:

> Jim Posen  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.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christian Decker via bitcoin-dev]

Jim Posen  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

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

[Christian Decker via bitcoin-dev]

Jim Posen  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.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jim Posen via bitcoin-dev]

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 
wrote:

> Jim Posen  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) :-)
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Christian Decker via bitcoin-dev]

Jim Posen  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) :-)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[ZmnSCPxj via bitcoin-dev]

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___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Jim Posen via bitcoin-dev]

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]