>Saturday, June 23, 2018 3:01 PM +03:00 from >lightning-dev-requ...@lists.linuxfoundation.org: > >Send Lightning-dev mailing list submissions to >lightning-dev@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-requ...@lists.linuxfoundation.org > >You can reach the person managing the list at >lightning-dev-ow...@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.bara...@gmail.com > >To: Lightning-dev < lightning-dev@lists.linuxfoundation.org > >Subject: [Lightning-dev] Second Level Protocols - Lightning - Patents >Message-ID: >< caaqs3wsgucyb6oepvtatuthtgne74vqmoq24o5vlybg8kk2...@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 < t...@timblokdijk.nl > >To: lightning-dev@lists.linuxfoundation.org >Subject: Re: [Lightning-dev] Second Level Protocols - Lightning - >Patents >Message-ID: < 07859b75-9c76-0e1d-e565-8e82402e7...@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@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.sa...@gmail.com > >To: Lightning-dev@lists.linuxfoundation.org >Subject: Re: [Lightning-dev] Mesh network problem >Message-ID: >< CAGpBVFvHrp3A=4heisxba7MsfG9FLdK-RiOQDf=drsrylwe...@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 < i...@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@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@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 > > >------------------------------ > >Message: 4 >Date: Fri, 22 Jun 2018 22:06:15 -0400 >From: ZmnSCPxj < zmnsc...@protonmail.com > >To: "lightning-dev\\@lists.linuxfoundation.org" >< lightning-dev@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@lists.linuxfoundation.org >https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > >End of Lightning-dev Digest, Vol 34, Issue 13 >********************************************* mailto:floppy...@mail.ru
_______________________________________________ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
