Tyler H [ARCHIVE] on Nostr: 📅 Original date posted:2018-04-08 📝 Original message: Christian, I think your ...
📅 Original date posted:2018-04-08
📝 Original message:
Christian,
I think your points are all valid. I believe the challenge with something
like this will be in it's general use and implementation, which is why the
RFC doesn't make mention of intended usage past mentioning different nodes
for "clothing" or "ebooks" a domain could advertise.
--Regarding looking up nodes at the time of payments:
In the future, nodes could negotiate a channel open with a push amount and
provide the TXID or payment hash as proof of their payment of the invoice.
This wouldn't even require the channel to be usable, and merchants could
decide to accept 1 (or even 0) confirmations of this transaction based on
their acceptable level of risk, considering the properties of the channel
(capacity, local balance etc). So in that use case, this would be a rough
process of the interaction:
User tries to pay lightning invoice, and it fails. The user's wallet
offers to pay via channel opening. The user accepts. The wallet reads the
invoice for a "domain" field, or perhaps if the wallet happens to be a
browser, it does a SRV lookup against the current domain serving the
invoice. The wallet looks up the domain records, and verifies the
destination node is present. If so, the wallet picks the correct node
based on the records present, and opens a channel with a push amount to
it. The destination node sees this and via as some yet undetermined
method, associates it to that payment invoice and chooses to mark it as
"paid" or "pending X confirmations" according to whatever criteria the node
operator wishes to use.
In a simple example, you could list all of your nodes but prefer clients
open channels to a single one, similar to ACINQ's setup with "endurance"
and "starblocks" on testnet. This example would simply require setting
"endurance" to have the highest priority. This also allows domain operators
to have one or more public nodes, but many private ones with channels open
to their public nodes to better manage their risk. For example, the private
nodes could be behind a firewall.
The result of this is that the user experience is improved, and a side
benefit is being able to safely associate a given payment request, and by
extension node, with a domain. Another nontrivial benefit is there will be
more channels opened with value on the other side, allowing for receiving
funds back from Lightning.
There are some possible open questions regarding ensuring a payment request
hasn't been spoofed, but if you present the domain to the user, he/she can
verify that the wallet is about to open a channel to the domain they
expect. Other issues with this are with DNS hijacking, which to be frank
is not an unlikely scenario. Caution would be necessary, and perhaps
cryptographic means of associating nodes and their associated domains would
be a requirement for something like this to exist, but the proposed BOLT
lays the groundwork for that to happen.
--Future payments going through the merchant:
This is probably the biggest wrinkle. The merchant _does_ have the ability
to know when a payment transits the channel, thus reducing privacy. I
think the proposed BOLT should only be used to improve user experience, not
as a replacement for the decentralized nature of Lightning. For example,
node operators will use autopilot-like functionality for opening channels,
BUT they will be able to augment that with looking up common stores and
merchant's domain records and open their own channels to them to provide
alternate routes to popular anticipated destinations for payments, thus
making their own node more valuable and increasing the decentralization of
the network. For example, if you know people are going to be paying
Starbucks, you can issue a DNS request of your own, get their current
preferred node and connect, and then any node you have channels with will
be able to pay Starbucks through you, without having to open a channel of
their own.
--Merchant crippling payments:
With the convention I described above, using channel opens as proof of
payment, if Starbucks wants to deny a customer the ability to pay McDonalds
(or simply doesn't have the appropriate channels to do so), the user's
wallet will simply fall back, look up mcdonalds.com, find the appropriate
node and pay the invoice via channel opening. This also partly addresses
point 2, as if a merchant wants to spy on its customers, it must provide
routes to its competitors. It can either spy or deny routes, but not
both. In addition, the onion-like nature of payments means the merchant
can't be sure a user paid a competitor, or a node behind them, though some
configurations of channels and nodes can definitely reduce privacy quite a
bit (example: a tiny etsy shop only has a couple of connections, Evil
Starbucks being one of them with the largest channel. A user paying an
amount above the second largest channel to this shop would have to use the
merchant's channel, and the merchant would be sure that the payment didn't
travel any further from there.)
--Network of large hubs:
I disagree. Again, leaning on the ability to open channels with push
amounts that have some minor assurances (authority of DNS records) that
you're getting the node you intend, I expect routing node operators to
preemptively open channels to merchants they expect to receive payments,
and they could advertise their own node to do so, along with allowing
customers to connect directly to merchants. The minimum requirement to use
this BOLT are the same as running a Lightning node full time, plus
ownership of a domain.
With that said, I agree regarding the value of random connections in
strengthening the network. Nodes are well-equipped to find inefficiencies
and correct them. The intention of the BOLT is really to improve the
on-boarding experience, along with providing an additional means to
advertise "official" nodes to ease clients, especially mobile ones, onto
the network.
Your pessimism is warranted and invited.
Apologies for the lengthy reply,
Tyler
On Sun, Apr 8, 2018 at 4:47 PM Christian Decker <decker.christian at gmail.com>
wrote:
> 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 <tyzbit at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180408/7ec182b6/attachment-0001.html>;
📝 Original message:
Christian,
I think your points are all valid. I believe the challenge with something
like this will be in it's general use and implementation, which is why the
RFC doesn't make mention of intended usage past mentioning different nodes
for "clothing" or "ebooks" a domain could advertise.
--Regarding looking up nodes at the time of payments:
In the future, nodes could negotiate a channel open with a push amount and
provide the TXID or payment hash as proof of their payment of the invoice.
This wouldn't even require the channel to be usable, and merchants could
decide to accept 1 (or even 0) confirmations of this transaction based on
their acceptable level of risk, considering the properties of the channel
(capacity, local balance etc). So in that use case, this would be a rough
process of the interaction:
User tries to pay lightning invoice, and it fails. The user's wallet
offers to pay via channel opening. The user accepts. The wallet reads the
invoice for a "domain" field, or perhaps if the wallet happens to be a
browser, it does a SRV lookup against the current domain serving the
invoice. The wallet looks up the domain records, and verifies the
destination node is present. If so, the wallet picks the correct node
based on the records present, and opens a channel with a push amount to
it. The destination node sees this and via as some yet undetermined
method, associates it to that payment invoice and chooses to mark it as
"paid" or "pending X confirmations" according to whatever criteria the node
operator wishes to use.
In a simple example, you could list all of your nodes but prefer clients
open channels to a single one, similar to ACINQ's setup with "endurance"
and "starblocks" on testnet. This example would simply require setting
"endurance" to have the highest priority. This also allows domain operators
to have one or more public nodes, but many private ones with channels open
to their public nodes to better manage their risk. For example, the private
nodes could be behind a firewall.
The result of this is that the user experience is improved, and a side
benefit is being able to safely associate a given payment request, and by
extension node, with a domain. Another nontrivial benefit is there will be
more channels opened with value on the other side, allowing for receiving
funds back from Lightning.
There are some possible open questions regarding ensuring a payment request
hasn't been spoofed, but if you present the domain to the user, he/she can
verify that the wallet is about to open a channel to the domain they
expect. Other issues with this are with DNS hijacking, which to be frank
is not an unlikely scenario. Caution would be necessary, and perhaps
cryptographic means of associating nodes and their associated domains would
be a requirement for something like this to exist, but the proposed BOLT
lays the groundwork for that to happen.
--Future payments going through the merchant:
This is probably the biggest wrinkle. The merchant _does_ have the ability
to know when a payment transits the channel, thus reducing privacy. I
think the proposed BOLT should only be used to improve user experience, not
as a replacement for the decentralized nature of Lightning. For example,
node operators will use autopilot-like functionality for opening channels,
BUT they will be able to augment that with looking up common stores and
merchant's domain records and open their own channels to them to provide
alternate routes to popular anticipated destinations for payments, thus
making their own node more valuable and increasing the decentralization of
the network. For example, if you know people are going to be paying
Starbucks, you can issue a DNS request of your own, get their current
preferred node and connect, and then any node you have channels with will
be able to pay Starbucks through you, without having to open a channel of
their own.
--Merchant crippling payments:
With the convention I described above, using channel opens as proof of
payment, if Starbucks wants to deny a customer the ability to pay McDonalds
(or simply doesn't have the appropriate channels to do so), the user's
wallet will simply fall back, look up mcdonalds.com, find the appropriate
node and pay the invoice via channel opening. This also partly addresses
point 2, as if a merchant wants to spy on its customers, it must provide
routes to its competitors. It can either spy or deny routes, but not
both. In addition, the onion-like nature of payments means the merchant
can't be sure a user paid a competitor, or a node behind them, though some
configurations of channels and nodes can definitely reduce privacy quite a
bit (example: a tiny etsy shop only has a couple of connections, Evil
Starbucks being one of them with the largest channel. A user paying an
amount above the second largest channel to this shop would have to use the
merchant's channel, and the merchant would be sure that the payment didn't
travel any further from there.)
--Network of large hubs:
I disagree. Again, leaning on the ability to open channels with push
amounts that have some minor assurances (authority of DNS records) that
you're getting the node you intend, I expect routing node operators to
preemptively open channels to merchants they expect to receive payments,
and they could advertise their own node to do so, along with allowing
customers to connect directly to merchants. The minimum requirement to use
this BOLT are the same as running a Lightning node full time, plus
ownership of a domain.
With that said, I agree regarding the value of random connections in
strengthening the network. Nodes are well-equipped to find inefficiencies
and correct them. The intention of the BOLT is really to improve the
on-boarding experience, along with providing an additional means to
advertise "official" nodes to ease clients, especially mobile ones, onto
the network.
Your pessimism is warranted and invited.
Apologies for the lengthy reply,
Tyler
On Sun, Apr 8, 2018 at 4:47 PM Christian Decker <decker.christian at gmail.com>
wrote:
> 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 <tyzbit at 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 at lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180408/7ec182b6/attachment-0001.html>;