Re: [Lightning-dev] Comments on BOLT#11

[Jameson Lopp]

HTLC.me is run by Alex Bosworth; I'll ping him.

On Fri, Dec 15, 2017 at 6:44 PM, Jonathan Underwood <
junderw...@bitcoinbank.co.jp> wrote:

> iirc they are using the description as a way to join the user data and the
> payment hash on their end.
>
> htlc me is one node but separates its balance into user accounts that
> exist outside lightning. I think the identifier is used so when their
> backend checks the payment request status, the user info is right there in
> their local lnd RPC response rather than having to store their own database
> separately.
>
> 2017年12月16日(土) 8:31 Rusty Russell :
>
>> Jonathan Underwood  writes:
>> > Additional comment: we should make a requirement to hide text in the
>> > description under certain conditions.
>> >
>> > ie. "A reader MUST hide information surrounded by curly brackets {}
>> > including
>> > the brackets themselves from the UI, and only make the information
>> avaiable
>> > internally."
>> >
>> > I think a lot of people will want to include extra data in their payment
>> > requests' description.
>> >
>> > I think HTLC.ME uses it and maybe bitrefill? (correct me if I'm wrong.)
>>
>> OK, HTLC.ME (cool site!) uses a description of:
>>
>> {"generic_id":"ada00363-50b6-4281-82dd-d274393439f1"}
>>
>> Which I really don't understand.  This field is literally only to
>> display to the user, for them to validate it's what they wanted.  The
>> recipient never gets it back.
>>
>> If I knew who ran HTLC.ME, I'd ask them to fix it: they should have a
>> description entry field in their "Request Payment" form.  It could
>> default to "Test payment ada00363-50b6-4281-82dd-d274393439f1", but
>> they're in spec violation at the moment.
>>
>> > Perhaps adding an "extra data" tag?
>>
>> Easy to do, if I knew why they wanted it.
>>
>> Thanks!
>> Rusty.
>>
> --
> -
> Jonathan Underwood
> ビットバンク社 チーフビットコインオフィサー
> -
>
> 暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。
>
> 指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
>
> ___
> 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

Re: [Lightning-dev] Comments on BOLT#11

[Jonathan Underwood]

iirc they are using the description as a way to join the user data and the
payment hash on their end.

htlc me is one node but separates its balance into user accounts that exist
outside lightning. I think the identifier is used so when their backend
checks the payment request status, the user info is right there in their
local lnd RPC response rather than having to store their own database
separately.

2017年12月16日(土) 8:31 Rusty Russell :

> Jonathan Underwood  writes:
> > Additional comment: we should make a requirement to hide text in the
> > description under certain conditions.
> >
> > ie. "A reader MUST hide information surrounded by curly brackets {}
> > including
> > the brackets themselves from the UI, and only make the information
> avaiable
> > internally."
> >
> > I think a lot of people will want to include extra data in their payment
> > requests' description.
> >
> > I think HTLC.ME uses it and maybe bitrefill? (correct me if I'm wrong.)
>
> OK, HTLC.ME (cool site!) uses a description of:
>
> {"generic_id":"ada00363-50b6-4281-82dd-d274393439f1"}
>
> Which I really don't understand.  This field is literally only to
> display to the user, for them to validate it's what they wanted.  The
> recipient never gets it back.
>
> If I knew who ran HTLC.ME, I'd ask them to fix it: they should have a
> description entry field in their "Request Payment" form.  It could
> default to "Test payment ada00363-50b6-4281-82dd-d274393439f1", but
> they're in spec violation at the moment.
>
> > Perhaps adding an "extra data" tag?
>
> Easy to do, if I knew why they wanted it.
>
> Thanks!
> Rusty.
>
-- 
-
Jonathan Underwood
ビットバンク社 チーフビットコインオフィサー
-

暗号化したメッセージをお送りの方は下記の公開鍵をご利用下さい。

指紋: 0xCE5EA9476DE7D3E45EBC3FDAD998682F3590FEA3
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Comments on BOLT#11

[Rusty Russell]

Jonathan Underwood  writes:
> Additional comment: we should make a requirement to hide text in the
> description under certain conditions.
>
> ie. "A reader MUST hide information surrounded by curly brackets {}
> including
> the brackets themselves from the UI, and only make the information avaiable
> internally."
>
> I think a lot of people will want to include extra data in their payment
> requests' description.
>
> I think HTLC.ME uses it and maybe bitrefill? (correct me if I'm wrong.)

OK, HTLC.ME (cool site!) uses a description of:

{"generic_id":"ada00363-50b6-4281-82dd-d274393439f1"}

Which I really don't understand.  This field is literally only to
display to the user, for them to validate it's what they wanted.  The
recipient never gets it back.

If I knew who ran HTLC.ME, I'd ask them to fix it: they should have a
description entry field in their "Request Payment" form.  It could
default to "Test payment ada00363-50b6-4281-82dd-d274393439f1", but
they're in spec violation at the moment.

> Perhaps adding an "extra data" tag?

Easy to do, if I knew why they wanted it.

Thanks!
Rusty.
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Every node must be aware of all other nodes - scalability problem?

[Christian Decker]

Welcome to the mailing list Oliver :-)

> It seems to me by reading BOLT #7 that every node in the lightning network
> must be aware of every other. That is necessary to choose a complete route
> to send a transaction for example.

Yes, Bolt 7 is a purposefully simplistic gossiping protocol that does
not scale infinitely. It's simple because we need something to get
started and it is not intended to work forever, just long enough for us
to come up with something better.

> If the lightning network grows large, one could imagine multiple network
> nodes per person, so say 7e10 nodes. For a fully connected graph, there
> must also be 7e10 channels, and likely many more.
>
> That means each node, upon joining the network, must download, keep in
> local storage, and keep updates on at least 35TB of data to be able to send
> payments elsewhere on the network.

I should note that you will absolutely need more than n-1 channels if you
have n nodes, otherwise you're just creating a line-graph, that would
not be very useful :-)

Rusty had some back-of-the-envelope calculations about the raw size of
the data that a node has to handle for 1 million nodes [1], and they
come to about 120 MB, without updates. And yes the initial sync is also
very simplistic, but we are already starting to think about better, more
fine-grained sync protocols to reduce that upfront download when
joining, and you can disable the initial sync already.

> Surely there needs to be some kind of method whereby a peer can keep track
> of only the nearby nodes, and have some kind of routing table for groups of
> more distant nodes, which need not individually be known. A DHT is an
> example of that. Designing such a system where no intermediate node knows
> both sender and receiver sounds hard, but possible...
>
> Why aren't we doing that?

We are also thinking about more advanced path finding algorithms that
reduce the need for the complete information on the node (some of them
also mentioned in that blog post). There's just a lot to implement
generally for Lightning, so we punted on the routing problem a bit,
since it is a luxury problem: before we hit that wall we first have to
have a network that is successful enough to need a better solution.

Cheers,
Christian

[1] 
https://medium.com/@rusty_lightning/lightning-routing-rough-background-dbac930abbad
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Peer Selection

[Stan Kladko]

Hi Cristian,

If there is such a great company, BlockStream. and Blockstream runs a
fantastic high quality node, then as a user why should I connect to
any node other than Blockstream?
In this case I dont need to be online all the time and dont need to
monitor the blockchain for anything. I will just believe that
Blockstream will do no bad to me.

Why do I need to drink unnamed cola if there is Pepsi?))  People used
to run emails servers, it is all Gmail now, much more secure and
reliable!




On Fri, Dec 15, 2017 at 9:06 PM, Christian Decker
 wrote:
> Let me add some more color to the discussion.
>
> If you do not announce the existence of the channel to the wider network
> you can still receive incoming payments, by simply telling the payment
> sender about the channel. This is what is being done in the payment
> request by adding the `r` parameter to the request. You are selectively
> informing the sender about the channel, which can then use that
> information to construct the route (and onion packet) and initiate the
> payment.
>
> Even though you have only one channel, and announce it, people might
> still want to route through you, by using the channel twice: once to
> route to you and then back out from you. While this may seem wasteful,
> it may be useful to hide the real origin/destination of the
> payment. Another scenario for which this is useful is that you are an
> auditor that witnesses the payment while it is being processed, for book
> keeping or similar cases. This would also work for unannounced channels.
>
> So the decision whether to announce a channel is exactly what you're
> looking for. It allows you to do bidirectional payments, and does not
> allow random people to route through you. Implementations might
> eventually add an "endpoint mode" that rejects any HTLC for which the
> node is not the origin or the destination, which would further enforce
> this.
>
> Cheers,
> Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

Re: [Lightning-dev] Peer Selection

[Christian Decker]

Let me add some more color to the discussion.

If you do not announce the existence of the channel to the wider network
you can still receive incoming payments, by simply telling the payment
sender about the channel. This is what is being done in the payment
request by adding the `r` parameter to the request. You are selectively
informing the sender about the channel, which can then use that
information to construct the route (and onion packet) and initiate the
payment.

Even though you have only one channel, and announce it, people might
still want to route through you, by using the channel twice: once to
route to you and then back out from you. While this may seem wasteful,
it may be useful to hide the real origin/destination of the
payment. Another scenario for which this is useful is that you are an
auditor that witnesses the payment while it is being processed, for book
keeping or similar cases. This would also work for unannounced channels.

So the decision whether to announce a channel is exactly what you're
looking for. It allows you to do bidirectional payments, and does not
allow random people to route through you. Implementations might
eventually add an "endpoint mode" that rejects any HTLC for which the
node is not the origin or the destination, which would further enforce
this.

Cheers,
Christian
___
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev