Rusty Russell [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-07 📝 Original message: CJP <cjp at ...
📅 Original date posted:2015-07-07
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
> The routing design has important implications for privacy, but also for
> the enforcement of regulations on the Lightning network.
Hi CJP! I was hoping you'd weigh in here, thanks!
> Imagine, for instance, that a couple of large nodes start requiring
> their neighbors to provide identity information (KYC-style regulation),
> and then require them to recursively provide identity information for
> all their neighbors' neighbors, and so on. If it is visible to
> intermediate nodes which other nodes participate in a transaction, this
> would cause the Lightning network to split into a regulated and a
> non-regulated part: nobody would dare to interface between the two,
> since that would prove to the regulated side that they illegally provide
> connectivity on the non-regulated side.
>
> So, I don't want nodes to explicitly know the shape of the entire
> network. Based on how Wikipedia explains source routing to me, I think
> it is incompatible with what I want. Please also note that IP almost
> never uses source routing.
Total agreement. The network must be robust against
censorship/partition for good technical reasons as well as malice.
People will also rightfully expect a caching layer for bitcoin to have
the same open-membership properties that bitcoin has.
> Also, as a counter-measure against censorship (or persecution) based on
> destination address, I think the function of "destination address of a
> route" should be de-coupled from the function of "payer endpoint" or
> "payee endpoint" of a route. In many cases, the "payer endpoint" or
> especially the "payee endpoint" will also fulfill the role of
> "destination address", but they may also choose a neutral "meeting
> point" node in the middle, and both route towards its address. This will
> allow nodes to secretly interface between regulated and non-regulated
> parts of the network, for transactions going in both directions.
OK, so this is why I proposed an onion routing system.
Basically: each node sees the next hop, the R hash, the amount, the
timeout, the fee being offered. It doesn't see the source, nor the
final destination.
This, however, requires source routing.
> The time-out value is a bit of a problem in this concept, since it is an
> indication of the number of hops from the payee endpoint. However, if
> nodes are free to choose the time-out increment for themselves, they
> could choose to make that increment smaller, to be able to route through
> a node that provides an interface to the regulated part.
>
> An additional advantage of separating destination addresses from the
> payment endpoints is that routing tables can be much smaller. Most
> consumers, and a lot of small shops can choose not to have their own
> destination address, but instead route through the destination address
> of their Lightning provider (a bit like a NAT router's IP address).
This was close to my original mental model: several thousand hubs, most
people as clients. But this risks becoming centralized, which directly
leads to the problem of censorship. You would simply blacklist certain
providers, or whitelist the ones you approve of.
So Joseph pushed my thinkoing in a radically more decentralized
direction, but routing becomes a *much* harder problem.
Anyway, I think it makes sense to support this in the protocol by adding
an opaque destination token. This could distinguish separate payments
or separate clients. Some nodes may well support transparent forwarding
of these to other nodes.
> In my view, routing tables are a sort of a heuristic, that tells you how
> likely a payment (of a certain amount!) to/from a certain destination
> address is to succeed on one of your interfaces. It is an optimization
> over the dumb algorithm of simply trying out all your interfaces one by
> one(*). It is TBD how to determine these heuristics, and how to exchange
> them between nodes.
>
> This is probably quite different from how routing on the Internet works,
> and I'm not sure how it will scale and how it can be defended against
> DoS attacks, but it sort of follows automatically from the desire to
> keep the network free.
Yep, spray-and-pray is always a good starting point! But it definitely
won't scale, so I'd like to make sure we don't paint ourselves into a
corner (even if that's our first cut).
Fees are a real issue. Without source routing the client is guessing
how much fees will be, and there'll be a lot of gaming to decide how
much of the pie to take (take too much, you get none as payment fails to
route). I think you'll end up asking your provider how you should to
pay, and that's a pretty horrible model for privacy.
With source routing and onion it's a little better; you can explicitly
state what each hop gets. Of course, if your route/payment information
is out of date you lose, too.
In summary:
1) Each-hop routing:
- Final destination hub is revealed to all nodes.
- May be forwarded, though.
- Source may be revealed to all nodes?
- Fees are tricky.
- Too low will fail
- How to estimate?
- Adaptable to changing network conditions
- Intermediary nodes can reroute.
- End clients need not know anything.
2) Source routing:
- Neither final source nor dest revealed to intermediary nodes.
- Fees are known in advance.
- Requires retransmission from source if routes change.
- End clients need routing/fee information.
- Allows selection of nodes from source
- May let you avoid bad/tracking/unreliable nodes?
Is there anything I missed?
Cheers,
Rusty.
📝 Original message:
CJP <cjp at ultimatestunts.nl> writes:
> The routing design has important implications for privacy, but also for
> the enforcement of regulations on the Lightning network.
Hi CJP! I was hoping you'd weigh in here, thanks!
> Imagine, for instance, that a couple of large nodes start requiring
> their neighbors to provide identity information (KYC-style regulation),
> and then require them to recursively provide identity information for
> all their neighbors' neighbors, and so on. If it is visible to
> intermediate nodes which other nodes participate in a transaction, this
> would cause the Lightning network to split into a regulated and a
> non-regulated part: nobody would dare to interface between the two,
> since that would prove to the regulated side that they illegally provide
> connectivity on the non-regulated side.
>
> So, I don't want nodes to explicitly know the shape of the entire
> network. Based on how Wikipedia explains source routing to me, I think
> it is incompatible with what I want. Please also note that IP almost
> never uses source routing.
Total agreement. The network must be robust against
censorship/partition for good technical reasons as well as malice.
People will also rightfully expect a caching layer for bitcoin to have
the same open-membership properties that bitcoin has.
> Also, as a counter-measure against censorship (or persecution) based on
> destination address, I think the function of "destination address of a
> route" should be de-coupled from the function of "payer endpoint" or
> "payee endpoint" of a route. In many cases, the "payer endpoint" or
> especially the "payee endpoint" will also fulfill the role of
> "destination address", but they may also choose a neutral "meeting
> point" node in the middle, and both route towards its address. This will
> allow nodes to secretly interface between regulated and non-regulated
> parts of the network, for transactions going in both directions.
OK, so this is why I proposed an onion routing system.
Basically: each node sees the next hop, the R hash, the amount, the
timeout, the fee being offered. It doesn't see the source, nor the
final destination.
This, however, requires source routing.
> The time-out value is a bit of a problem in this concept, since it is an
> indication of the number of hops from the payee endpoint. However, if
> nodes are free to choose the time-out increment for themselves, they
> could choose to make that increment smaller, to be able to route through
> a node that provides an interface to the regulated part.
>
> An additional advantage of separating destination addresses from the
> payment endpoints is that routing tables can be much smaller. Most
> consumers, and a lot of small shops can choose not to have their own
> destination address, but instead route through the destination address
> of their Lightning provider (a bit like a NAT router's IP address).
This was close to my original mental model: several thousand hubs, most
people as clients. But this risks becoming centralized, which directly
leads to the problem of censorship. You would simply blacklist certain
providers, or whitelist the ones you approve of.
So Joseph pushed my thinkoing in a radically more decentralized
direction, but routing becomes a *much* harder problem.
Anyway, I think it makes sense to support this in the protocol by adding
an opaque destination token. This could distinguish separate payments
or separate clients. Some nodes may well support transparent forwarding
of these to other nodes.
> In my view, routing tables are a sort of a heuristic, that tells you how
> likely a payment (of a certain amount!) to/from a certain destination
> address is to succeed on one of your interfaces. It is an optimization
> over the dumb algorithm of simply trying out all your interfaces one by
> one(*). It is TBD how to determine these heuristics, and how to exchange
> them between nodes.
>
> This is probably quite different from how routing on the Internet works,
> and I'm not sure how it will scale and how it can be defended against
> DoS attacks, but it sort of follows automatically from the desire to
> keep the network free.
Yep, spray-and-pray is always a good starting point! But it definitely
won't scale, so I'd like to make sure we don't paint ourselves into a
corner (even if that's our first cut).
Fees are a real issue. Without source routing the client is guessing
how much fees will be, and there'll be a lot of gaming to decide how
much of the pie to take (take too much, you get none as payment fails to
route). I think you'll end up asking your provider how you should to
pay, and that's a pretty horrible model for privacy.
With source routing and onion it's a little better; you can explicitly
state what each hop gets. Of course, if your route/payment information
is out of date you lose, too.
In summary:
1) Each-hop routing:
- Final destination hub is revealed to all nodes.
- May be forwarded, though.
- Source may be revealed to all nodes?
- Fees are tricky.
- Too low will fail
- How to estimate?
- Adaptable to changing network conditions
- Intermediary nodes can reroute.
- End clients need not know anything.
2) Source routing:
- Neither final source nor dest revealed to intermediary nodes.
- Fees are known in advance.
- Requires retransmission from source if routes change.
- End clients need routing/fee information.
- Allows selection of nodes from source
- May let you avoid bad/tracking/unreliable nodes?
Is there anything I missed?
Cheers,
Rusty.