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.
> 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.
> 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:
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/