Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

[ZmnSCPxj via Lightning-dev]

Good morning Tyler,

> This is not the intention.  This BOLT _does not_ replace bootstrapping seed 
> functionality, now or ever.  A client can supplement her view of the network 
> by getting the graph from well-known nodes if she wishes, but no more.  To do 
> otherwise _would_ centralize the network to an uncomfortable degree.  I used 
> "autoconnect" because that's the terminology in the mobile wallet, but it is 
> misleading.

Ah, I see.  Should have been "autochannel" I suppose.

>> I am not sure how the risk gets managed if the public and private nodes are 
>> owned by the same economic entity.
>
> If the public facing node gets hacked, it cannot draw funds from the private 
> node, only send them out to the attacker on the network, or close the 
> channels and send the funds + wallet balance to an on-chain address.  The 
> "warm" funds in your example sit on the C side of the B -> C channel.

Let us break this down.

Suppose we start with this state:

A 2 <-> 0 B 2 <-> 0 C

Now, again, suppose the situation is that B and C are owned by the same 
economic entity, Tyler & Rompert Enterprises.

Suppose A pays 1 BTC to C:

A 1 <-> 1 B 1 <-> 1 C

Now suppose public node B is hacked.  This means B can close the channels and 
move the funds onchain to the hacker onchain address.  In that case, a total of 
2 BTC can be stolen from node B.

Now suppose Tyler & Rompert Enterprises decides not to actually have a private 
node C.  We start with this state:

A 2 <-> 0 B

Suppose A pays 1 BTC to B:

A 1 <-> 1 B

Now suppose public node B is hacked. This means B can close the channels and 
move the funds onchain to the hacker onchain address. In that case, a total of 
1 BTC can be stolen from node B.  Compare this to the previous situation, where 
2 BTC can be stolen from node B, *precisely because of the existence of B<->C*.

So it is strictly better it seems, from a risk perspective, to just use a 
public node directly, than running a public node and one or more private nodes. 
 You lose less this way than also funding a channel from your public to your 
private node.

Either that, or you contract to an external party who takes on the risk of 
running a public node, most likely in exchange for much higher feerates to your 
private node.

Regards,
ZmnSCPxj___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

[Tyler H]

> Connect is not the same as make a channel with.  Connect simply lets you
access gossip information.  So the hard-coded node is not privileged: it
simply relays gossip information to the wallet, equivalent to getting an
entire map of the network as visible from that node.  The plan is that you
connect (but NOT make a channel with) a known fixed node with known high
uptime, then the autopilot downloads the entire network map, then connects
and creates channels to nodes from the map.

This is outside of the spec, isn't it? All implementations should use a
seed service to bootstrap themselves to the network.

> The plan is that you connect (but NOT make a channel with) a known fixed
node with known high uptime, then the autopilot downloads the entire
network map, then connects and creates channels to nodes from the map.

This is not the intention.  This BOLT _does not_ replace bootstrapping seed
functionality, now or ever.  A client can supplement her view of the
network by getting the graph from well-known nodes if she wishes, but no
more.  To do otherwise _would_ centralize the network to an uncomfortable
degree.  I used "autoconnect" because that's the terminology in the mobile
wallet, but it is misleading.

I hope the additional text I've added in the RFC makes this clear, and I
regret any confusion.  Most of the functionality enabled by this proposed
BOLT would be in giving users the ability to more easily open channels to
the node they intend to, by giving node operators a way to advertise their
nodes. I do think perhaps the proposed RFC could be further improved by
adding a stipulation that autopilot functionality MUST NOT rely on domains
advertising nodes, and a user MUST choose to open a channel to a node based
on the domain.

> I am not sure how the risk gets managed if the public and private nodes
are owned by the same economic entity.

If the public facing node gets hacked, it cannot draw funds from the
private node, only send them out to the attacker on the network, or close
the channels and send the funds + wallet balance to an on-chain address.
The "warm" funds in your example sit on the C side of the B -> C channel.

Regarding "hubs", I think that while the barrier to entry into running
multiple nodes isn't zero, it's low enough that even singular moderately
technical node operators might operate with their channels in such a
configuration as this to better reduce their external risk.  A user with a
laptop and Docker could run multiple nodes with channels between them, for
instance, and the containers could be insulated from each other except for
Lightning protocol traffic.

Best,
Tyler

On Mon, Apr 9, 2018 at 7:31 PM ZmnSCPxj  wrote:

> Good morning Tyler,
>
> > A side effect of this BOLT would be, as an example, the mobile Eclair
> wallet could be updated to accept a domain parameter to specify an initial
> node to open a user's first channel to rather than only the option to
> "autoconnect" to their hard-coded node, and the wallet could handle
> resolving and picking a node transparently, thus increasing
> decentralization of "fringe" users such as mobile users and SPV nodes.
>
> Connect is not the same as make a channel with.  Connect simply lets you
> access gossip information.  So the hard-coded node is not privileged: it
> simply relays gossip information to the wallet, equivalent to getting an
> entire map of the network as visible from that node.  The plan is that you
> connect (but NOT make a channel with) a known fixed node with known high
> uptime, then the autopilot downloads the entire network map, then connects
> and creates channels to nodes from the map.
>
> While certainly getting a node other than the hardcoded one might let you
> avoid censorship of nodes by free software developers of the wallet, I am
> uncertain if getting gossip from a known merchant node is *better* than
> that.  Certainly you can be sure that the free software developers have at
> least some nominal checks and balances (and publicly-visible codebase) to
> prevent censorship, which might not be the case for purely commercial
> enterprises.
>
> > 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.
>
> I am not sure how the risk gets managed if the public and private nodes
> are owned by the same economic entity.
>
> Suppose I am a single economic entity, and I have a public node B and a
> private node C.  You are the customer A who pays me.
>
> A -> B -> C
>
> Now the channel B->C contains money I own.  Any transfers between B and C
> are simply money juggling around between two accounts I own.  Thus my
> earnings are never in the B->C channel, but in the (public!) A->B channel.
> So attacking B will still allow hackers to take my earnings, because B->C
> only contains savings.  Indeed I probably take *more* 

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

[Tyler H]

Christian,

I hope the additional clarification in the RFC makes clear that BOLT 10
takes precedence for bootstrapping and autopilot functionality.  To
summarize the intention of this BOLT: Lightning is authoritative, but DNS
can be used to assist in on-boarding (with all of its usefulness AND
inherent flaws.)

>we can just do the domain -> nodeid binding without encouraging
> users to actually open a direct connection :-)

Right - the intention is to provide fallback mechanisms and user-friendly
ways of finding the right nodes.  If a user wants to open a channel to
Starbucks before they leave their house, then can and then let the
confirmation process start on the way there.

> The risk is that
> if we spec and implement this right now, it'll become the normal mode of
> operation and we'll end up with a very poor network.

I agree, and I am in no rush to get this BOLT part of the spec before every
implementation has an autopilot function in a state they're comfortable
with.  If we want to kick it out for some months or even longer to allow
time for the network to bootstrap itself in a decentralized way, I'm fine
with that. I do think the pros of being able to associate a given
merchant/user with their incoming node in a way familiar to users will help
to ease the pain of opening channels that are useful to the user.

> Well, the fallback solution is not exactly free either, it takes time to
confirm the channel, so the merchant can indeed force a degraded user
experience

Ah, good point. I would exercise caution against implementing my exact
proposal regarding channel opens as payments as it was an example of
functionality that would be enabled by the BOLT that needs careful thought
and design to address concerns.  I think the ability to find nodes operated
by the owners of domains and subdomains could open up other useful
possibilities as well, including giving mobile users the option of where to
open their first channel to.

With your feedback, perhaps a good idea would be to decide on and
explicitly defined allowable uses for information gleaned from DNS records
such as the line already added about disallowing bootstrapping from a
non-seed domain.

Perhaps the first approved use-case could be invoices that include a domain
in the extra fields, clients can do a lookup on the domain and ensure the
node they're paying is listed, and if not provide a warning notification to
the user, or simply display the domain and the result of the lookup.

This would provide some protection against invoice tampering, as a
malicious actor with the ability to modify the invoice displayed to the
user would have to also display a domain other than the one the one
associated with the website the user intended to pay.

Thanks,
Tyler

On Mon, Apr 9, 2018 at 12:26 PM Christian Decker 
wrote:

> Tyler,
>
> thanks for the detailed feedback, I'll try to address some of the issues
> inline:
>
> Tyler H  writes:
> > --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:
>
> There is very little difference between pushing with the channel
> creation and just doing an immediate update even though the channel
> isn't confirmed yet. To be honest I think the `push_msat` feature is the
> classical case of optimizing too early.
>
> But the end result is still that the merchant either takes a hit in the
> trustworthiness of the incoming payment, or the buyer is going to have a
> bad time waiting at the checkout until the channel confirms.
>
> > 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.
>
> I was going to comment that, since we already have an invoice detailing
> the destination, the indirection through the DNS system to find the
> desired connection point was useless, 

Re: [Lightning-dev] Proposal for Advertising Lightning nodes via DNS records.

[Christian Decker]

Tyler,

thanks for the detailed feedback, I'll try to address some of the issues
inline:

Tyler H  writes:
> --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:

There is very little difference between pushing with the channel
creation and just doing an immediate update even though the channel
isn't confirmed yet. To be honest I think the `push_msat` feature is the
classical case of optimizing too early.

But the end result is still that the merchant either takes a hit in the
trustworthiness of the incoming payment, or the buyer is going to have a
bad time waiting at the checkout until the channel confirms. 

> 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.

I was going to comment that, since we already have an invoice detailing
the destination, the indirection through the DNS system to find the
desired connection point was useless, but your example with Starblocks
where connections are accepted by one node, and payments by another
convinced me that this is indeed a useful feature. A feature however
that could be solved just as well by including an `r` tag in the invoice
itself. In this case you can either use the gossip protocol or the BOLT
10 DNS lookup system to locate the entry point into the merchant's
network. I don't think that a direct connection to the merchant in case
of it being unreachable is a good idea, because it creates latent
hubs. But I see the slight advantage of reducing the failure probability
w.r.t. to opening a channel with a random node.

> 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.

This is definitely true, if I'm not mistaken, starblocks doesn't even
allow incoming connections, so you have to use endurance as an entry
point.

> 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.

There's some value in this, that's definitely true, however these kinds
of added security through DNS haven't quite worked out in the past. Then
again we can just do the domain -> nodeid binding without encouraging
users to actually open a direct connection :-)

> --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 

Re: [Lightning-dev] QR of node information

[Igor Cota]

Hi all,

On 9 April 2018 at 11:47, Corné Plooy via Lightning-dev <
lightning-dev@lists.linuxfoundation.org> wrote:
>
> Is this really only about reducing the size of QR codes? How many
> percent reduction do you think you can accomplish with your approach? I
> think, when it comes to reducing QR code size, it makes more sense to
> think of a better way to encode the node ID. Hexadecimal isn't exactly
> the most space-efficient encoding.
>

We'd save 33 bytes by not using hex. Makes the QR code a bit rarer
(whatever is opposite of dense).
I intend to support both approaches, if there are 33 bytes before the '@'
it's raw, 66 it's hex.

Igor



> Op 07-04-18 om 17:17 schreef Robert Olsson:
> > Hello all,
> >
> > I seem to not find a bolt regarding the QR code of node@ip:port
> >
> > It seems eclair only supports the format hex@ip:port format, and i
> > haven't tried any other mobile wallets.
> >
> > I thought there would be support for bech32 nodeid:s to keep the QR
> > small, but it doesn't seem that way.
> >
> > If it isn't standardized yet, i think we should do it soon so all
> > wallets will support it from start and we can avoid bulky QR codes.
> >
> > To fully utilize QR it should work with charset in text-mode, so i
> > would suggest a format like
> >
> > lightning:ln1bech32nodeid/ipnumber/port
> >
> > where /port is optional if port is 9735
> >
> > this is to avoid @ and confusion of : in ipv6 and :portnumber
> > (skip '[' and ']' in ipv6)
> >
> > another approach would be to encode ip and portnumber in bech32 as
> > well. my opinion is that everything coded entirely in bech32 shouldn't
> > need a protocol so the 'lightning:' part could possibly be omitted as
> > well.
> >
> > or did i just miss a bolt somewhere?
> >
> > best regards
> > Robert Olsson
> >
> >
> >
> >
> >
> >
> >
> > ___
> > 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
>



-- 
*Igor Cota*
Codex Apertus Ltd
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] QR of node information

[Corné Plooy via Lightning-dev]

Why put everything in bech32? It hurts readability. The only possible
advantage is that data inside the bech32 blob can be digitally signed in
a convenient way. If you don't need that, I'd keep your data ourside the
bech32 blob, in a (expert-)human-readable format.


Why not follow a regular URL format when host and port are involved? I
don't see the advantage of lightning:ln1bech32nodeid/ipnumber/port over
node@ip:port. In practice, I see both C-Lightning and LND also using
node@ip:port, BTW.


Is this really only about reducing the size of QR codes? How many
percent reduction do you think you can accomplish with your approach? I
think, when it comes to reducing QR code size, it makes more sense to
think of a better way to encode the node ID. Hexadecimal isn't exactly
the most space-efficient encoding.


CJP



Op 07-04-18 om 17:17 schreef Robert Olsson:
> Hello all,
>
> I seem to not find a bolt regarding the QR code of node@ip:port
>
> It seems eclair only supports the format hex@ip:port format, and i
> haven't tried any other mobile wallets.
>
> I thought there would be support for bech32 nodeid:s to keep the QR
> small, but it doesn't seem that way.
>
> If it isn't standardized yet, i think we should do it soon so all
> wallets will support it from start and we can avoid bulky QR codes.
>
> To fully utilize QR it should work with charset in text-mode, so i
> would suggest a format like
>
> lightning:ln1bech32nodeid/ipnumber/port
>
> where /port is optional if port is 9735
>
> this is to avoid @ and confusion of : in ipv6 and :portnumber
> (skip '[' and ']' in ipv6)
>
> another approach would be to encode ip and portnumber in bech32 as
> well. my opinion is that everything coded entirely in bech32 shouldn't
> need a protocol so the 'lightning:' part could possibly be omitted as
> well.
>
> or did i just miss a bolt somewhere?
>
> best regards
> Robert Olsson
>
>
>
>
>
>
>
> ___
> 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