[Lightning-dev] help

Sun Jun 24 21:50:17 UTC 2018



>Saturday, June 23, 2018 3:01 PM +03:00 from lightning-dev-request at lists.linuxfoundation.org:
>
>Send Lightning-dev mailing list submissions to
>lightning-dev at lists.linuxfoundation.org
>
>To subscribe or unsubscribe via the World Wide Web, visit
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>or, via email, send a message with subject or body 'help' to
>lightning-dev-request at lists.linuxfoundation.org
>
>You can reach the person managing the list at
>lightning-dev-owner at lists.linuxfoundation.org
>
>When replying, please edit your Subject line so it is more specific
>than "Re: Contents of Lightning-dev digest..."
>
>
>Today's Topics:
>
>   1. Second Level Protocols - Lightning - Patents (Praveen Baratam)
>   2. Re: Second Level Protocols - Lightning - Patents (Tim Blokdijk)
>   3. Re: Mesh network problem (Oleg Sadov)
>   4. Re: Mesh network problem (ZmnSCPxj)
>
>
>----------------------------------------------------------------------
>
>Message: 1
>Date: Fri, 22 Jun 2018 20:51:28 +0530
>From: Praveen Baratam < praveen.baratam at gmail.com >
>To: Lightning-dev < lightning-dev at lists.linuxfoundation.org >
>Subject: [Lightning-dev] Second Level Protocols - Lightning - Patents
>Message-ID:
>< CAAQs3wsGuCyb6OEpvtAtuThtGnE74vQmOQ24O5VLYBG8Kk2GTw at mail.gmail.com >
>Content-Type: text/plain; charset="utf-8"
>
> Hello everybody,
>
>I just heard from a friend that Second Level Protocols such as Lightening
>Network can be patented if the author/inventor chooses to!
>
>Is it possible? Am I missing something?
>
>Best,
>
>Praveen Baratam
>
>about.me < http://about.me/praveen.baratam >
>?
>-------------- next part --------------
>An HTML attachment was scrubbed...
>URL: < http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180622/1607c88e/attachment-0001.html >
>
>------------------------------
>
>Message: 2
>Date: Fri, 22 Jun 2018 17:35:07 +0200
>From: Tim Blokdijk < tim at timblokdijk.nl >
>To:  lightning-dev at lists.linuxfoundation.org
>Subject: Re: [Lightning-dev] Second Level Protocols - Lightning -
>Patents
>Message-ID: < 07859b75-9c76-0e1d-e565-8e82402e7423 at timblokdijk.nl >
>Content-Type: text/plain; charset="utf-8"; Format="flowed"
>
>Probably not in the EU. Both 'mathematical methods' and 'programs for 
>computers' are excluded from being patented.
>
>
>Op 22-06-18 om 17:21 schreef Praveen Baratam:
>> Hello everybody,
>>
>> I just heard from a friend that Second Level Protocols such as 
>> Lightening Network can be patented if the author/inventor chooses to!
>>
>> Is it possible? Am I missing something?
>>
>> Best,
>>
>> Praveen Baratam
>>
>> about.me < http://about.me/praveen.baratam >
>> ?
>>
>>
>> _______________________________________________
>> 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/20180622/e8c61140/attachment-0001.html >
>
>------------------------------
>
>Message: 3
>Date: Fri, 22 Jun 2018 22:59:09 +0300
>From: Oleg Sadov < oleg.sadov at gmail.com >
>To:  Lightning-dev at lists.linuxfoundation.org
>Subject: Re: [Lightning-dev] Mesh network problem
>Message-ID:
>< CAGpBVFvHrp3A=4heisxba7MsfG9FLdK-RiOQDf=DRsryLWEP8w at mail.gmail.com >
>Content-Type: text/plain; charset="UTF-8"
>
>May be it would be reasonable to think about using of SDN
>technologies, such as OpenFlow. This specification is supported by
>many SW and HW NW switches. This allows you to create a NW
>configuration managed by the L7 OSI application layer with NW packet
>routing and transparent transformation for the sender/receiver pair.
>We use this technology for building of SDN-enabled Blockchain
>modelling NW environments (for ex. NWs with Quantum Cryptography) for
>R&D projects of our students:
>
>http://balchemylab.gitlab.io/
>
>??, 20 ???. 2018 ?. ? 22:07, Andy Schroder < info at andyschroder.com >:
>>
>> Who do you think controls the routing table for the internet? Is the internet not a mesh network?
>>
>> --
>> Andy Schroder
>>
>> On June 20, 2018 2:15:19 PM EDT, Joseph Hoane via Lightning-dev < lightning-dev at lists.linuxfoundation.org > wrote:
>>>
>>> I root for the Lightening Network?s success, but it seems to have an inherent weakness. Since routing tables are not part of the architecture how can the sender chose the next recipient so as to effect an efficient path to the ultimate receiver? With no routing table available the next receiver's connection to the remote ultimate receiver or to the ultimate receiver?s proximate connections is unknown. Even a powerful bridge node will not know an efficient subsequent path and could send the message on in exactly the most inefficient direction. How does choosing an efficient next intermediate receiver not remain a guess, a shot in the dark?
>>> I don?t think any solution to the mesh network routing problem has been found. What am I missing here?  Thanks.
>>>
>>>
>>> ________________________________
>>>
>>> Lightning-dev mailing list
>>>  Lightning-dev at lists.linuxfoundation.org
>>>  https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>>
>> _______________________________________________
>> Lightning-dev mailing list
>>  Lightning-dev at lists.linuxfoundation.org
>>  https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>------------------------------
>
>Message: 4
>Date: Fri, 22 Jun 2018 22:06:15 -0400
>From: ZmnSCPxj < ZmnSCPxj at protonmail.com >
>To: "lightning-dev\\@lists.linuxfoundation.org"
>< lightning-dev at lists.linuxfoundation.org >
>Subject: Re: [Lightning-dev] Mesh network problem
>Message-ID:
>< m0W7J5znQ0u9rUzIE6skSPKX50sWp3kqjz_FEsT_gdhcAGQ_r-RtTcGf7w0Ogxr3opxoBTofgMxY_LOLDy0qPtf4z7gYzARjSXJrZcTUmkc=@protonmail.com >
>
>Content-Type: text/plain; charset=UTF-8
>
>Good morning Joseph,
>
>> I root for the Lightening Network?s success, but it seems to have an inherent weakness. Since routing tables are not part of the architecture how can the sender chose the next recipient so as to effect an efficient path to the ultimate receiver? With no routing table available the next receiver's connection to the remote ultimate receiver or to the ultimate receiver?s proximate connections is unknown. Even a powerful bridge node will not know an efficient subsequent path and could send the message on in exactly the most inefficient direction. How does choosing an efficient next intermediate receiver not remain a guess, a shot in the dark?
>> 
>> I don?t think any solution to the mesh network routing problem has been found. What am I missing here? Thanks.
>
>
>The current spec has each participant share their views of the entire graph with each other.  The payer uses its own local view of the entire network to create a route from payer to payee.  None of the intermediate nodes need to make any decisions or keep routing tables: the entire route has been found by the payer in the first place.  No guesswork is necessary: either you know of a route and can provide it entirely (so intermediate nodes never have to guess) or you know of no route and are unable to pay.
>
>The existence of channels has a simple proof: every channel is backed by a 2-of-2 multisig UTXO.  When sharing views of network graph, each channel in the view includes a reference to the UTXO backing it.  To show that the channels are indeed Lightning channels, a signature matching the 2-of-2 multisig is required.  The proof-of-channel-existence is thus the reference to the UTXO, plus a signature signing that reference.  If a node receives a supposed channel from a peer, but the UTXO does not exist or is already spent, then the node ignores that channel and does not add it to its local network view..  It is thus not possible to fake a channel (to spam the network views of Lightning peers) without actually committing money into some UTXO, which deters spam.
>
>The solution currently in use is simple and direct, at the cost that each node has to keep a view of the entire network.  The so-called "Lightning Network scaling problem" is largely a problem of these local network views becoming too large for low-end devices to keep; perhaps the Eclair developers should chime in at this point, since they target mobile devices and may be able to give a perspective on whether the network map is too large for mobile devices already.
>
>--
>
>The mesh network routing problem in general can be solved by self-addressing packets (like IP (the Internet) uses).
>
>When a node receives a packet that is not addressed to it, it looks up the destination address in its routing table. If it does not exist in the routing table, then the node simply throws it to some other peer, which at least is progress.
>
>Similarly, a "payment packet" can offer a forwarding fee and the payment.  When a node receives it, it could deduct some part of the fee for itself and attempt to forward it to one of its other peers.  The more accurately it can forward the payment, the more likely it can earn from the forwarding fees (if the payment fails to reach the destination then the node cannot earn fee).  Even a simple "try all your peers" approach would in aggregate result in a breadth-first search of the network graph, so if it is reachable then the payment will indeed get forwarded.  The drawback is that it reveals the destination of the payment, which is why Lightning went with onion routing.
>
>Regards,
>ZmnSCPxj
>
>
>------------------------------
>
>_______________________________________________
>Lightning-dev mailing list
>Lightning-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
>
>End of Lightning-dev Digest, Vol 34, Issue 13
>*********************************************


mailto:floppynet at mail.ru
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180625/111d370f/attachment-0001.html>