đź“… Original date posted:2020-02-17
đź“ť Original message:
Exactly what Matt said.
I would also add that libp2p aims to be a kind of swiss-army knife for p2p
networking: that's nice for many use-cases, but when security is your main
focus, it's not.
Look at TLS: most attacks are downgrade attacks because the protocol offers
way too many options.
Protocols like Wireguard have perfectly understood this. No options, not
many configuration hooks -> small, auditable codebase.
For lightning it's the same: we prefer a very simple transport that has no
options whatsoever.
Simple to implement, simple to test, and works great in practice.
Bastien
Le lun. 17 févr. 2020 à 18:00, Matt Corallo <lf-lists at mattcorallo.com> a
Ă©crit :
> Because writing connection logic and peer management is really not that
> complicated compared to HTLC state machines and the rest of lightning. For
> crypto, lighting does use the noise framework, though the resulting code is
> so simple (in a good way) that its super easy to just write it yourself
> instead of fighting with a dependency.
>
> Lastly, for self-respecting cryptocurrency developers,
> not-carefully-audited dependencies are security vulnerabilities that will
> expose your users’ funds. By pulling simple connection logic into a
> lighting implementation, it’s easier to test/fuzz/etc with the rest of a
> project.
>
> Matt
>
> On Feb 17, 2020, at 06:12, Alexandr Burdiyan <burdiyan at gmail.com> wrote:
>
> 
> Hi everyone!
>
> Since I recently started digging into all-things-peer-to-peer, I found
> that there’s a lot of fragmentation between many different projects that
> seemingly have a lot of things in common, like networking, encoding
> standards, and etc. I suppose there’re lots of historical reasons for that.
>
> More concretely for Lightning, I wonder why it couldn’t use some existing
> open source technologies and standards, like libp2p [1] for communication,
> or various multiformats [2] standards for addresses, hashes and encodings?
>
> I do think that building and evolving common toolkits and standards for
> decentralized system like libp2p, or multiformats, or IPLD [3] could be
> something very useful for the whole community. Currently, it feels like
> everyone wants to go so fast, so there’s no time for coordination and
> consensus to build these kinds of specs. That is understandable. But I
> wonder if Lightning community ever looked at projects like libp2p and
> multiformats, or maybe is considering to implement them in lightning. Or
> maybe there was a decision of not using them for some reason that I might
> be missing.
>
> [1]: https://libp2p.io
> [2]: https://multiformats.io
> [3]: https://ipld.io
>
> Thanks!
>
> Alexandr Burdiyan
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200217/3f44b0fb/attachment.html>;
Bastien TEINTURIER [ARCHIVE] /
npub17f…ntr0s
2023-06-09 12:58:55
in reply to nevent1q…tger
Author Public Key
npub17fjkngg0s0mfx4uhhz6n4puhflwvrhn2h5c78vdr5xda4mvqx89swntr0sPublished at
2023-06-09 12:58:55Event JSON
{
"id": "68e08469abd1c37201ac09aad5561bae54fe30a908927875bc1e5627282b4552",
"pubkey": "f26569a10f83f6935797b8b53a87974fdcc1de6abd31e3b1a3a19bdaed8031cb",
"created_at": 1686315535,
"kind": 1,
"tags": [
[
"e",
"a7ae10fc55b4d320d5dc0b0592e32b2db619c8a47c005e0f6f825597739c1029",
"",
"root"
],
[
"e",
"2780a3a1e757e9065269b0bbe754733032f1f42bfedf2eb40f5596c25319fd74",
"",
"reply"
],
[
"p",
"cd753aa8fbc112e14ffe9fe09d3630f0eff76ca68e376e004b8e77b687adddba"
]
],
"content": "📅 Original date posted:2020-02-17\n📝 Original message:\nExactly what Matt said.\n\nI would also add that libp2p aims to be a kind of swiss-army knife for p2p\nnetworking: that's nice for many use-cases, but when security is your main\nfocus, it's not.\nLook at TLS: most attacks are downgrade attacks because the protocol offers\nway too many options.\nProtocols like Wireguard have perfectly understood this. No options, not\nmany configuration hooks -\u003e small, auditable codebase.\n\nFor lightning it's the same: we prefer a very simple transport that has no\noptions whatsoever.\nSimple to implement, simple to test, and works great in practice.\n\nBastien\n\nLe lun. 17 févr. 2020 à 18:00, Matt Corallo \u003clf-lists at mattcorallo.com\u003e a\nécrit :\n\n\u003e Because writing connection logic and peer management is really not that\n\u003e complicated compared to HTLC state machines and the rest of lightning. For\n\u003e crypto, lighting does use the noise framework, though the resulting code is\n\u003e so simple (in a good way) that its super easy to just write it yourself\n\u003e instead of fighting with a dependency.\n\u003e\n\u003e Lastly, for self-respecting cryptocurrency developers,\n\u003e not-carefully-audited dependencies are security vulnerabilities that will\n\u003e expose your users’ funds. By pulling simple connection logic into a\n\u003e lighting implementation, it’s easier to test/fuzz/etc with the rest of a\n\u003e project.\n\u003e\n\u003e Matt\n\u003e\n\u003e On Feb 17, 2020, at 06:12, Alexandr Burdiyan \u003cburdiyan at gmail.com\u003e wrote:\n\u003e\n\u003e \n\u003e Hi everyone!\n\u003e\n\u003e Since I recently started digging into all-things-peer-to-peer, I found\n\u003e that there’s a lot of fragmentation between many different projects that\n\u003e seemingly have a lot of things in common, like networking, encoding\n\u003e standards, and etc. I suppose there’re lots of historical reasons for that.\n\u003e\n\u003e More concretely for Lightning, I wonder why it couldn’t use some existing\n\u003e open source technologies and standards, like libp2p [1] for communication,\n\u003e or various multiformats [2] standards for addresses, hashes and encodings?\n\u003e\n\u003e I do think that building and evolving common toolkits and standards for\n\u003e decentralized system like libp2p, or multiformats, or IPLD [3] could be\n\u003e something very useful for the whole community. Currently, it feels like\n\u003e everyone wants to go so fast, so there’s no time for coordination and\n\u003e consensus to build these kinds of specs. That is understandable. But I\n\u003e wonder if Lightning community ever looked at projects like libp2p and\n\u003e multiformats, or maybe is considering to implement them in lightning. Or\n\u003e maybe there was a decision of not using them for some reason that I might\n\u003e be missing.\n\u003e\n\u003e [1]: https://libp2p.io\n\u003e [2]: https://multiformats.io\n\u003e [3]: https://ipld.io\n\u003e\n\u003e Thanks!\n\u003e\n\u003e Alexandr Burdiyan\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n\u003e _______________________________________________\n\u003e Lightning-dev mailing list\n\u003e Lightning-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20200217/3f44b0fb/attachment.html\u003e",
"sig": "d6bccdcaa2c653b993107301e1b3636a76b49b188617154f9879ae4b3a4cecc76b8b43a3b24ea20f3b24a70561d9047b3841ad46e0a30962bb1607b2da950354"
}