Re: [Lightning-dev] Comments on BOLT#11
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
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
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] General question on routing difficulties
Thanks for filling in some gaps in my knowledge of the internal workings of Ripple. I see now my mental model of the system and how it compares to what's being proposed in SpeedyMurmurs wasn't quite correct. > In my opinion, it is interesting to look at tradeoffs and the > necessary/sufficient guarantees for the routing algorithm in a > decentralized payment network such as the LN before we stick to a solution. Agreed, and there can be many such solutions depending on particular use cases. When switching to new routing algorithms, most of the existing code dealing with the interaction in the link itself (how channel updates are done, funding channels, resolving multi-hop HTLC's, how disputes are settled on-chain, etc) can be completely reused. > For what I understand, what you are asking/proposing is a mixture of the > routing layer (route from sender to receiver) + onion layer (using > “adapted”/”optimized” sphinx)+ payment layer (HTLCs). Not exactly, I was more asking how w/o onion routing (as we do now), the sender is able to construct an outgoing HTLC that satisfies the time lock and fee preferences of all participants in the final route. Currently the sender completely orchestrates the route so it can select the total amount and time locks such that all participants have the preferences upheld. > Another proposal might consist on a payment operation that does not assume > source-routing to start with. There are many possibilities to investigate > and think about. Indeed. I haven't yet found a satisfactory solution to HTLC parameter selection at the sender w/o a degree of source routing. The extreme naive versions lead to an excessive total time lock value in the route, or senders losing out more money to fees as the routes are no longer as precise. > What you describe here is indeed a problem inherent to the original > landmark routing mechanism. However, it is no longer an issue in > SpeedyMurmurs. In particular, any node could be a landmark or two users > could have a different view of what set of nodes constitute the set of > landmarks. Ah! I missed this aspect the first time around in my read through. Thanks for resolving a major misunderstanding on my end (along with the usage of shortcuts). > All in all, it seems that there might be some misconceptions and/or > aspects in the current draft of the paper that might need clarifications > so that the approach is well understood. We are more than happy to > further talk about it and answer questions, doubts or concerns that > might arise. Thanks for clearing up my initial misunderstandings of the protocol! I'll give the paper (along with the works it derives from) a close read and follow back up with any further questions. Based on your response to my initial comments, it seems I mischaracterized the routing algorithm as being an incremental advancement compared to the original landmark protocol. Instead, it has gone far beyond that. > I, however, do not agree that we should choose one routing > approach or another based on how unbalanced channels are handled. I didn't mean to entail that an approach should be *chosen* based on how unbalanced channels are handled. Instead, I was highlighting how they're handled using a source routed protocol, to start a discussion on if passive rebalancing can be applied to others. As you stated earlier in our conversation, we should examine the desirable properties of a routing proposal so we can navigate the various trade offs. > My point is that I think we should not stick to one routing algorithm > depending on how another algorithm/functionality at another layer is > handled, at least not before we explore and fully understand the > tradeoffs, benefits and impossibilities that we will have to face here. Agreed. The intent of my initial response was to highlight how we handle certain functionalities with the current algorithm so we can then begin to investigate it those features are possible/applicable to other algorithms such as SpeedyMurmurs. I don't think any of us see the current algorithm as the one and only algorithm we'll be sticking to for the lifetime of the system. Instead, it's a stepping stone of something with a degree of privacy built-in by default that was simple enough to get the ball rolling as far as deployment. > I also believe that we might have more than just HTLC-based payments in > the LN, but this is the topic for another long email :) Definitely! HTLC's are just the start... -- Laolu On Thu, Nov 30, 2017 at 8:59 AM Pedro Moreno Sanchez wrote: > Hi Laolu, > Thanks for your detailed and interesting reply. Please see below some > points I would like to make in some of your comments and the answers to > your questions in the last email. And of course, I would be happy to > further discuss with you. > > > On 11/25/17 2:16 PM, Olaoluwa Osuntokun wrote: > > (final try as the prior mail hit the size limit, sorry for the spam!) > > > > Hi Pedro, > > > > I came across this pape
Re: [Lightning-dev] Every node must be aware of all other nodes - scalability problem?
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
For one thing having a single connection means that the peer you're connecting to can see all your payment amounts and their timings, and they can be sure that they are from you since you don't have any other channel. Opening more channels gives you plausible deniability. Also it'd make your single peer a single point of failure, meaning that if it goes down you're dead in the water. And then on the other end, we have no interest in running a large hub in the first place. They're expensive to run, since we'd have to allocate enough funds to cover the sum of payments you might receive over time (which is already hard to know, so we'd have to over-provision). That'd also make the hub an attractive target for an attack, since it'd have a lot of funds sitting in hot wallets. Furthermore the utility the hub gets from the funds it allocates to the channels going to endpoints, such as your node, is very minimal, since it can only earn fees on payments that are either initiated by you or received by you, meaning the funds mostly sit idle. Compare that to a channel that is very active because it bridges two large clusters in the network. The low utilization of the funds in the channel also means that hubs will have to charge large fees for the few times the channels are actually used, which again is an incentive for you to create bypasses. I think these arguments alone are probably sufficient to discourage the formation of large hubs, and should incentivize even end-users to create at least 2 channels. Remember that this is all taken care of in the background by the client, users don't actually have to think about opening/closing/maintaining channels, or how to allocate funds to the channels. Our goal in the end is to create clients that show a single balance, allow users to make both off-chain or on-chain payments from that balance, and not require people to ever think about the details in the background. I appreciate your trust in Blockstream, but as our informal motto says "don't trust, verify!" :-) Cheers, Christian Stan Kladko writes: > 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
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
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
