Pierre [ARCHIVE] on Nostr: 📅 Original date posted:2015-09-16 📝 Original message: > Both these indicate ...

📅 Original date posted:2015-09-16
📝 Original message:
> Both these indicate each wallet (end-user) is connected to just one node;
> I'd expect the usual case to be two or three so you can more easily deal
> with downtime by a node.
Yes, I skipped that.

> If I'm an end-user with a wallet with two channels; and I switch my
> software to being a full lightning node with the same two channels, I'd
> end up in this state. Likewise if I was a new node trying to establish
> myself on the network.
I understand the idea and advantages of everybody running a node, to
be honest I implicitely discarded this possibility in favor of a
limited (10s ? 100s ?) number of specialized supernodes. I feel like
having a lot of small nodes that constantly appear and disappear is
somewhat incompatible with a reliable and low latency (<1s ?) payment
network, but I admit I am probably too pessimistic !

> Also, if there's a lot of traffic from node A to node B, their channel
> will become lopsided (B will own all the coins), if it turns out that
> C has channels with both A and B, a circular transaction A -> C -> B ->
> A would allow those channels to rebalance (and x->A->C->B->y would allow
> x and y to continue to transact despite A->B being full). If that happens
> a lot, it might be profitable for everyone concerned if "C" sets up a
> node that only does that, and doesn't deal with end-users directly.
This makes sense, although if I am not mistaken it can only be done
once, because then C will own all the coins in the channel A-C, and if
A-B becomes lopsided again A will need to find yet another circular
route. I would think in that case B would be more likely to cash out
as mentioned here :
http://lists.linuxfoundation.org/pipermail/lightning-dev/2015-September/000185.html.
In fact, I think that members of the lightning network will be
"strongly typed": overall they will either mainly send or mainly
receive money.

> That's optimal for efficiency, but probably pessimal for privacy. If
> lightning is fast and cheap enough, delaying things slightly for a
> significant increase in privacy would be worthwhile.
Agreed.

> Setting up channels isn't free, though -- it costs a blockchain
> transaction, and locks up bitcoins for no value if the channel's idle --
> so you also want to minimise the number of channels, not just the number
> of hops for a transaction.
This actually leads me to the "supernode" conclusion. End user would
only have a handful of channels set up with a few of those large,
well-connected nodes.
Just one remark on the fact that funds would be locked in a channel:
if lightning is widely successful and becomes the primary way of doing
payments, don't you think that this would change our perception of
which funds (in a wallet or in an open channel) are actually more
usable ?

>> Then we just agree on a standard port and that's it !
>> Isn't it how the internet works already ? Why do we need an
>> application-level routing on top of the IP routing ?
>
> 1) It'd be expensive to join the lightning network (if I wanted to be
> able to send up to $5 to anyone, and there were 100 nodes on the
> network, I'd need to commit $500 to lightning channels up front).
In my view you would just be connected to a few nodes which would
handle the rest.

> 2) It'd be easy to block payments (USA bans anyone from setting up
> channels with anyone in Cuba; Cubans can't run nodes)
Good point...

> 3) If there's a communications blockage, there's no ability to route
> around it.
True, but this is mitigated by the fact that every participant of the
network would be connected to a few nodes, so we can imagine that a
merchant would require to be paid at id1 at node1 or id2 at node2 ?

Cheers,

Pierre