Hi Tyler,
Hi Robert,
first of all, welcome to the mailing list, always good to have more
people looking and improving the spec. I quickly read through the spec
and it is very well written, and it looks good.
On a conceptual level, I do however have some issues with the
proposal. I don't think that the kind of selective attachment to the
node of a merchant is beneficial to neither the node that is opening the
channel, nor for the network as a whole:
- For the node opening a channel at the time of a payment is too late,
it basically means that for the first payment you'd have to wait for
an on-chain confirmation, even if we use `push_msat` to perform the
initial payment. This is bad for the user experience. Channels should
be opened ahead of time so that, when the customer enters a shop,
everything is already set up. Special cases are always hard to
communicate ("you have to wait, but only this time, then in future
all will be nice and quick")
- It also causes all future payments to go through that merchant, which
can now collate your shopping activity with all of your other
payments, and create a profile. It's basically the hub-and-spoke
threat with the added problem of the hub also knowing your identity.
- The merchant can cripple future payments that he might suspect are
going to a competitor (Starbucks may attempt to block payments for
amounts that look like coffee payments and go to their
competitor). Think net neutrality for Lightning.
- For the network as a whole this creates a network of large hubs that
are only weakly interconnected, or not connected at all, unless the
merchants are "generous" enough to maintain connections among each
other.
But it's not all bad, I really like the possibility to look up a
merchant's node ID through DNS, so that my wallet can check (indirect)
connectivity to that node and try to optimize their connectivity.
I think we should encourage people, and implement the clients, to open
random connections, biased towards strenghtening the overall
connectivity. With the gossip protocol we already disseminate enough
information to allow nodes to identify bottlenecks and provide
additional capacity to bridge them.
Sorry for being so pessimistic, but I think it's important we move away
from people attempting to open targeted channels directly to the
merchants. I still regret publishing the IP address of SLEEPYARK.
Regards,
Christian
Tyler H <tyz...@gmail.com> writes:
> Greetings,
>
> A challenge end-users face is connecting to nodes with enough liquidity to
> pay every merchant, and failing that, finding the merchant node in a
> reasonably sane way to open a channel to them for payments.
>
> As it is now, people find nodes in other people's visualizers, and pass
> node aliases around via word of mouth which is very prone to inaccuracy and
> MITM attacks. A current alternative is attempting to make a payment,
> decoding the payment request, finding the node on your graph and attempting
> to open a channel to the merchant. This is only possible if the
> destination is advertising addresses.
>
> We (Robert Olsson and I) propose an additional BOLT, tentatively scheduled
> to be BOLT 12, to allow for operators of domain names to create SRV records
> for their nodes. This is separate from BOLT 10's seed functionality as the
> desired outcome is to get only the nodes associated with a particular
> domain. This would allow, as an example, users to say to each other
> "connect to a Blockstream.com node" and the user can independently look up
> that domain, find advertised nodes and connect/open channels.
>
> This also improves security from the perspective of nodes masquerading as
> other nodes, as anyone with a domain can authoritatively list their nodes.
>
> In addition, domain operators could provide subdomains for their node
> addresses to distinguish between nodes intended for a specific purpose,
> from a human perspective.
>
> Robert Olsson (rompert) and I have created
> https://github.com/lightningnetwork/lightning-rfc/pull/406 as a draft of
> what the RFC could look like.
>
> Feedback is much appreciated.
>
> Best regards,
> Tyler (tyzbit)
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
