
Eltoo: A Simplified Update Mechanism for Lightning and Off-Chain Contracts - tlrobinson
https://blockstream.com/2018/04/30/eltoo-next-lightning.html
======
woah
This is an interesting case study in why it’s so hard to program on Bitcoin.

This proposal involves a small change to the payment channel incentive
structure to make it so that a node submitting old state (in an attempt to
cheat, or possibly by accident) is not punished.

However, this is be implemented by a series of hacks so convoluted that the
hacks must be described in their own research paper. One of the most puzzling
things about this type of blogging about bitcoin programming is that they
never make much of a distinction between the hacks and the simple underlying
concepts that the hacks implement.

For reference, here’s a description of payment channels without any
implementation details: [http://altheamesh.com/blog/universal-payment-
channels/](http://altheamesh.com/blog/universal-payment-channels/)

------
ddtaylor
> One such multiparty off-chain contract is the channel factories presented by
> Burchert et al. as a scalable way to fund any number of payment channels on
> top of a single on-chain transaction and to rebalance or reallocate them
> dynamically without ever touching the blockchain.

Is this their solution to "the routing problem" of Lightning?

> Before we can implement eltoo, we need a minor change to Bitcoin: the
> introduction of the SIGHASH_NOINPUT flag for signatures.

Some argue it's "not bitcoin" to create a blockchain without signatures since
the original whitepaper described a "Bitcoin" as a chain of digital
signatures.

~~~
xwvvvvwx
> Is this their solution to "the routing problem" of Lightning?

No. This is a mechanism for updating the balances in payment channels.

Participants in a payment channel lock up a shared balance in an on-chain
2-of-2 multisig output. They then exchange transactions off-chain that update
the share of ownership of the funds locked by the on-chain output. When the
participants want to close the channel they both sign a final update
transaction and submit it to the blockchain.

Eltoo has a few nice UX advantages over the existing state update mechanism:

1\. No more “toxic waste”. The existing mechanism is designed in such a way
that if I submit an old update transaction to the blockchain (e.g. one where I
had a larger share of funds than the current balance) the other participant in
the channel can take all the money in the channel (including my share of the
funds). While this provides security, there is also some risk, e.g. if my
lightning node crashes and I have to restore from backup I may have outdated
information and broadcasting that information to the chain would result in me
losing money. As the security of eltoo is not based on punishment, this issue
is resolved.

2\. No need to decide on fees ahead of time. The existing mechanism requires
users to set the fees for the closing transaction at the time that they open
the channel. As the fees required to submit a transaction to the blockchain
are quite unpredictable, and payment channels are long lived, this can result
in significant fee overpayment “just in case”

> Some argue it's "not bitcoin" to create a blockchain without signatures
> since the original whitepaper described a "Bitcoin" as a chain of digital
> signatures.

The transactions still have signatures, this flag just modified which parts of
the transaction are signed. Bitcoin already has many such flags:

[https://bitcoin.org/en/developer-guide#signature-hash-
types](https://bitcoin.org/en/developer-guide#signature-hash-types)

