Mark asks, “What is Eltoo?”
“Can you explain what the new Eltoo proposal, by
a number of Lightning Network developers, entails?”
“What does it solve? Are there trade-offs?
What are the barriers to its implementation?”
You may remember previously, in one of my answers,
I was talking about how Lightning isn’t a single protocol.
It is a whole stack of protocols which can be
interchangeable. You have some flexibility.
[You can] use different protocols at
different layers within the system.
The basic [protocol layer] is node discovery
and negotiation of capabilities between nodes.
That is the peer-to-peer network.
[Another layer] is the payment channel protocol.
It is important to understand that we already have
at least three different payment channel protocols.
The first payment channel protocol,
which is sometimes called “L2-penalty,”
is the protocol invented by [Joseph Poon and Thaddeus
Dryja] in the original Lightning Network whitepaper.
That type of [bi-directional] payment channel,
where the state is updated by enforcing a penalty…
if someone tries to cheat and close
the channel with an earlier state,
that formulation is more accurately called a Poon-Dryja
payment channel, named after the original authors.
There is another form of [bi-directional] channel [using
a “duplex” of uni-directional channels with timelocks].
[Duplex Micropayment Channels (DMCs)]
were invented by Decker and Wattenhofer [in 2015].
Christian Decker is a developer at Blockstream
who is working on the Lightning Network,
together with a few others at Blockstream.
[Roger] Wattenhofer was the other author of
the paper on [Duplex Micropayment Channels].
The most recent specification
for payment channels is Eltoo,
[spelled to be] pronounced like ‘L2,’
the acronym for “layer two” networks.
Eltoo was [proposed] by Christian Decker, Rusty Russell,
and Olaoluwa Osuntokun (also known as “roasbeef”),
the developer from Lightning Labs.
These three developers recently wrote a paper
called “eltoo: A Simple Layer2 Protocol for Bitcoin.”
These payment channels are now known as
Decker-Russell-Osuntokun payment channels.
Eltoo is a very neat improvement on Poon-Dryja
channels and [Duplex Micropayment channels]…
[such as by allowing for more participants],
which makes the network much more efficient.
By removing the need to have a penalty [branch] for
trying to cheat by transmitting intermediate states,
that would not only make the setup of payment channels
more efficient, but removes some of the complexities…
in maintaining a Lightning
Network node as an end user.
Eltoo requires a slight modification
to the Bitcoin scripting language.
You may have heard of SIGHASH,
which is a type of modifier for signatures.
When you sign a transaction in Bitcoin,
you can sign it in a number of different ways.
The most common [flag] is SIGHASH_ALL, where the
hash being signed represents all inputs and outputs.
There are a few others such as
SIGHASH_SINGLE, SIGHASH_NONE, etc.
These allow you to sign just one pair
of inputs and outputs in a transaction,
allowing multiple parties to join in
and sign a transaction collaboratively.
SIGHASH_ALL is often used in CoinJoin.
SIGHASH_NONE is where you [only sign the inputs
and allow anyone to change the outputs].
One of the [proposed changes] is called SIGHASH_NOINPUT, a way to sign a transaction…
such as to bind its outputs but not its inputs,
effectively allowing it to be a floating transaction.
It could be bound to any compatible input.
Eltoo uses SIGHASH_NOINPUT in order to create flexible
channels where you don’t need a [punishment branch].
As each new state is broadcast within the payment
channel, it invalidates the previous state…
by binding to its predecessor.
You can read that paper [with the specification] online
if you search for “Eltoo,” [linked in the video description].
[There are] quite a few different
explanations on what Eltoo does.
In summary: Eltoo is a new protocol for payment
channels, one of three to five proposals so far.
The Lightning Network runs one of the earliest
forms of payment channel [after Spillman channels],
called “L2-penalty” or Poon-Dryja channels,
but there are some new possible protocols.
In the future, these could all run in parallel.
The Lightning Network could make multiple different
types of payment channel available to nodes.
Nodes could negotiate which type of payment channel
they want to implement between themselves,
while still routing [payments] across
them in a way that is consistent.
This is a very interesting possibility, when
you have innovation within these protocols.
In order for Eltoo to be implemented, it requires
a small change to the Bitcoin scripting language.
This change can be [made] as a soft fork,
as an increment in the script version number,
which is possible [with Segregated Witness].
[Eltoo] will open the door to some very flexible
and efficient mechanisms for payment channels.
Not yet, we are still quite far away from seeing [them]
in production, [due to] needing a script change first.
A question about Lightning Network routing algorithms:
“The Lightning Network BOLT specifications leave
the choice of routing algorithms [open-ended].”
“Currently, nodes are using a very
trivial source routing algorithm.”
“Surely more interesting metrics could be used for
deciding routing, such as maximization of privacy,
minimisation of hops [or fees], etc.,
all just variations on the same theme.”
“Is there a qualitative improvement [made]
at some point, such as letting intermediate hops…
decide the route, as TCP/IP routers generally do?”
“Or are there intrinsic limitations inside the Lightning
Network that prevent such flexible approaches?”
An important consideration when building multi-layer
networks is separation of concerns between layers.
You shouldn’t try to do everything in a single layer.
If you have separation and abstraction between layers,
you can plug-and-play different algorithms at different
layers, mix-and-match them to things you want to do.
There is no reason why the Lightning Network
[should] run one routing algorithm for everyone.
In fact, like the internet, you can have
multiple different competing algorithms;
nodes can choose [from various] algorithms
in different parts of the protocol stack.
The Lightning Network isn’t just one layer; we talk of it
as “layer two,” but within there are a number of layers.
There is the peer-to-peer network that uses a gossip
protocol to propagate things like routing [data].
Above that, there is a layer for how channels are
implemented. I will talk about that in [another] answer…
for one of the subsequent questions,
because it has come up again and again.
For example, [regarding] the “L2-penalty” or
Poon-Dryja channels, used in the BOLT specification,
and some future [designs] like Eltoo
or Decker-Wattenhofer channels.
So that is [another layer]. Above that, the layer which
communicates hashed timelock contracts (HTLCs),
which are essentially the transport mechanism
for payments within the Lightning Network
Above that, you might have another layer
for various types of interesting applications…
that use metadata within the HTLCs to do other things
on Lightning, like channel factories and watchtowers.
The layer of LApps (Lightning applications).
Routing is simply one layer within a broad
protocol stack of the Lighting Network.
It is useful to have that flexibility to implement any type
of routing algorithm, independent of payment channels,
where you might [also] implement any
number of payment channel [designs],
independent of how you [handle] the peer-to-peer
negotiation of capabilities, node discovery, etc.
where you may [also] have multiple
different independent protocols.
This abstraction between layers opens up
the ability to do innovation [at the edges],
where each node can have a number of [options],
negotiate with other nodes, and evolve the network…
without it [becoming] stuck with [one] specific choice.
The [short] answer to your question is:
right now, we have source-based routing.
The reason is, it is the simplest algorithm and…
provides great privacy because only the
[sending] node knows the complete route.
At the same time, it protects the leaking of information
to intermediate [routing] nodes [through onion routing].
It works well enough for the current scale of the
Lightning Network. Why fix it, when it isn’t broken?
That is the mentality.
Engineer for what the problems are.
Today, [source routing] scales well enough
for the current scale of the Lightning Network.
It achieves the goals of privacy, route
discovery, and payment propagation.
Therefore, why fix it [now]? It works for now.
Does that mean we can’t do routing in other ways?
Absolutely not. We can do routing in other ways.
It is fairly easy to do the kind of intermediate
[route discovery] that you described, like TCP/IP.
You can use a system of “neighborhoods” and gateway
routers, such as what is used with TCP/IP, BGP.
You can use routing protocols with intermediary nodes
for even simple things like [finding] the shortest path.
“Hot potato routing” [techniques],
all of these various approaches.
For every one of these routing algorithms,
you must think of the set of trade-offs.
Maybe it is easier to discover routes,
or route [payments] more efficiently,
but what if you do that at the expense of privacy?
If intermediate [routing] nodes know where a payment is
going, they could [potentially] block certain recipients.
They could [individually] blacklist certain channels,
prevent you from [taking] certain routes [through them].
If you achieve better routing at the expense
of privacy and [censorship-resistance],
that [may not be] a good trade-off.
The question is, can you do intermediate
node routing without sacrificing privacy?
That is a question to still be resolved. There is a
lot of research. This is a rapidly evolving sphere.
I think there will be a lot more new
[developments] happening there.
But [BOLT], as a set of Lightning Network specifications,
does not prevent you from using any / multiple
routing algorithm you want for your node.
You can choose which one you
want to use for any payment.
You could mix-and-match, find routes for your [payments] with different algorithms simultaneously,
and then choose the best result.
Nothing prevents you from doing that
because of the abstraction between layers.
That is a good thing.
Johnny asks, “From when I first heard about
the Lightning Network last year, until now,
it seems to be ahead of schedule.”
“I was not expecting a live network at
this point of the year, but am I way off?”
“What is next for the Lightning Network?”
“Is there anything that non-technical but enthusiastic
users can do to support and participate [right now],
besides downloading a wallet and
buying a few [Blockstream] stickers?”
You are not wrong, Johnny. In this space,
it is really funny how people are frustrated…
with the “slow pace” of development, when we
actually have this amazing pace of development.
These technologies are rolling out [fast] and the rate
of innovation is increasing at an exponential pace.
The Lightning Network did progress
much faster [than we anticipated].
Keep in mind that this was just a whitepaper in .
To go from a paper to a full implementation of
a network within [about three years], is really fast.
In the area of cryptography,
we have never seen this before.
We started seeing [this] rate of development
in cryptography because of cryptocurrencies.
This is not an easy space in which to make [“move fast,
break things” type of] advancements and innovation,
because you have money on the table.
If you get it wrong, people lose money.
You are not the only one who is surprised to see a
live network already, at this stage of development.
Most of the developers for the Lightning Network
were surprised to see a live network [this soon].
It mostly happened against
their direct advice and wishes.
They didn’t feel that [the code] was ready for
mainstream production use [at the beginning of 2018[.
They were dragged reluctantly, kicking and
screaming, into supporting a main-net [release].
In the end, I think that was probably a good thing.
Some people are willing to take the extra risk,
knowing they could lose money by messing
up the configuration of their Lightning node…
or other inadvertent problems and bugs
which had not been discovered yet.
[They knew that] maybe they wouldn’t be able to do
anything with it, because it didn’t quite work yet.
But those people were able to push the state of the
network further and do a lot of interoperability testing.
under real-world scenarios.
So what can a new user do? Even setting up
a wallet and buying stickers is amazing right now!
It is incredibly helpful. You [may] run into problems.
When you document [those problems], you help others.
Maybe you will even submit an issue [on GitHub], which
is essentially a bug report to the software developers.
I have submitted two or three issues so far;
I’ve submitted pull-requests on LND and c-lightning,
in order to uncover small bugs and interoperability.
Why? Because I started using [Lightning] just
to buy stickers, as silly as that may sound.
I have an even sillier [use case] for you.
How about spending one satoshi to change one pixel…
on [a virtual] graffiti wall?
[It sounds like] a pointless application right now, but it is
engaging people [with development] by the hundreds.
[They] are stress-testing the system in [all kinds of ways,
including] interoperability between various clients.
They are testing the routing of payment channels,
the layout of the network and its connectivity.
In the process, they are discovering bugs
and these bugs are being fixed [early].
This is a great contribution. So yes, just
download a wallet and start trying to use it.
You will run into problems, figure out that
things are not named or displayed correctly,
which is confusing to new users.
You might find some problems with
the protocol and making payments.
Submit a bug report. Help the developers.
Make this better. Give them your fresh perspective.
You are seeing this stuff for the first time.
If you see something that is confusing,
that is [probably] because it is written by developers
who have been so deeply meshed in [building] this…
that they can’t even see it is confusing.
You telling them, “This is confusing,
I don’t understand why this is happening,”
will help them make better user interfaces and
figure out bugs that they may have not anticipated.
Trust me, the area is rich for bug reports.
There is a lot happening there.
Yes, [development] is moving very fast
and [becoming] better every day.
You can all participate to continue making it better.