What's the Question?
пн, 25 июн. 2018 г. в 1:41, flop py via Lightning-dev
<lightning-dev@lists.linuxfoundation.org>:
>
>
>
>
> 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
_______________________________________________
Lightning-dev mailing list
Lightning-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
