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 > Lightningfirstname.lastname@example.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev _______________________________________________ Lightning-dev mailing list Lightningemail@example.com https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev