📅 Original date posted:2021-06-30
📝 Original message:
hello René,
I think the idea of having separate standards is good because we can
keep the core spec mandatory and other things optional.
Since the core spec, defined by the BOLTs, is mandatory, it's better
if it's as small as possible, basically barely enough to allow peers
to talk to each other and open a channel, then define what an HTLC is
and the basic payment flow.
All the rest is optional. The BOLTs themselves encourage
experimentation by having TLVs, rules for optional and experimental
message type numbers and so on.
And then it doesn't make sense to put optional things in the BOLTs
otherwise no one will be spec-compliant anymore and it will cause
confusion.
Some things, like splicing and dual-funded channels could be created
as blips and after everybody had implemented them moved to the BOLTs,
other things, like the podcast tipping protocol, cannot.
Still, it is better to have a spec for the podcast tipping protocol
than to not have, or to have it hidden somewhere. It makes it more
open and easier for everyone.
Ultimately I think dual-funded channels, trampoline routing and other
lower level things should still be kept out of the BOLTs as long as
they are optional. While things like splicing and blinded paths seem
to be more like things that should enforced. This is my opinion, but I
think it's good to have this clear distinction.
Finally, a list of other things that deserve a spec so they are made
standard and interoperable across wallets and services:
1. keysend
2. AMP
3. hosted channels
4. trampoline routing v1
5. trampoline routing v2
6. turbo channels
7. podcast tipping protocol
8. dual-funding
9. on-demand channels
10. sphinx chat messaging thing
11. private routing as done by immortan
12. alternative graph for unannounced channels as done by immortan
13. lnurl-withdraw
14. lnurl-pay
15. lnurl-channel
16. bitcoin-liquid lightning bridge
17. I thought I had more but apparently I forgot
So we have to hunt these people down and make them submit specs.
---
fiatjaf
2021-06-30 16:35 (GMT+02:00), "René Pickhardt via Lightning-dev"
<lightning-dev at lists.linuxfoundation.org> said:
> Hey everyone,
> just for reference when I was new here (and did not understand the processes
> well enough) I proposed a similar idea (called LIP) in 2018 c.f.:
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html
> I wonder what exactly has changed in the reasoning by roasbeef which I will
> repeat here:
> We already have the equiv of improvement proposals: BOLTs. Historically new
> standardization documents are proposed initially as issues or PR's when
> ultimately accepted. Why do we need another repo?
> As far as I can tell there was always some form of (invisible?) barrier to
> participate in the BOLTs but there are also new BOLTs being offered:
> * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798
> * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780
> and topics to be included like:
> * dual funding
> * splicing
> * the examples given by Ryan
> I don't see how a new repo would reduce that barrier - Actually I think it
> would even create more confusion as I for example would not know where
> something belongs. That being said I think all the points that are addressed in
> Ryan's mail could very well be formalized into BOLTs but maybe we just need to
> rethink the current process of the BOLTs to make it more accessible for new
> ideas to find their way into the BOLTs? One thing that I can say from answering
> lightning-network questions on stackexchange is that it would certainly help if
> the BOLTs where referenced on lightning.network web page and in the whitepaper
> as the place to be if one wants to learn about the Lightning Network
> with kind regards Rene
> On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev wrote:
>
>
>
> Hi all,
>
>
>
>
> The recent thread around zero-conf channels [1] provides an opportunity to
> discuss how the BOLT process handles features and best practices that
> arise in the wild vs. originating within the process itself. Zero-conf
> channels are one of many LN innovations on the app layer that have
> struggled to make their way into the spec. John Carvalho and Bitrefill
> launched Turbo channels in April 2019 [2], Breez posted their solution to
> the mailing list for feedback in August 2020 [3], and we know at least
> ACINQ and Muun (amongst others) have their own implementations. In an
> ideal world there would be a descriptive design document that the app
> layer implementers had collaborated on over the years that the spec group
> could then pick up and merge into the BOLTs now that the feature is deemed
> spec-worthy.
>
>
>
>
> Over the last couple of months, we have discussed the idea of adding a
> BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various
> members of the community, and have received positive feedback from both
> app layer and protocol devs. This would not affect the existing BOLT
> process at all, but simply add a place for app layer best practices to be
> succinctly described and organized, especially those that require
> coordination. These features are being built outside of the BOLT process
> today anyways, so ideally a bLIP process would bring them into the fold
> instead of leaving them buried in old ML posts or not documented at all.
>
>
>
>
> Some potential bLIP ideas that people have mentioned include: each lnurl
> variant, on-the-fly channel opens, AMP, dynamic commitments, podcast
> payment metadata, p2p messaging formats, new pathfinding heuristics,
> remote node connection standards, etc.
>
>
>
>
> If the community is interested in moving forward, we've started a branch
> [5] describing such a process. It's based on BIP-0002, so not trying to
> reinvent any wheels. It would be great to have developers from various
> implementations and from the broader app layer ecosystem volunteer to be
> listed as editors (basically the same role as in the BIPs).
>
>
>
>
> Looking forward to hearing your thoughts!
>
>
>
>
> Best,
> Ryan
>
>
>
>
> [1]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html
>
>
>
>
> [2]
> https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster
>
>
>
>
> [3]
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html
>
>
>
>
> [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =
> Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)
>
>
>
>
> [5]
> https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki
>
>
>
> _______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
> --
> https://www.rene-pickhardt.de_______________________________________________
> Lightning-dev mailing list
> Lightning-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>
fiatjaf [ARCHIVE] /
npub1v2…pmakl
2023-06-09 12:40:23
in reply to nevent1q…k3wk
Author Public Key
npub1v2xa40strmvauf2gr5gjj5c3yqlytar7p3v64nfg0ke6e0vkvvkqxpmaklPublished at
2023-06-09 12:40:23Event JSON
{
"id": "f2613721f263ef65c2b3bcb0b5ad7de09d9cdb431c4c37c4c7ccc11d81947b6d",
"pubkey": "628ddabe0b1ed9de25481d11295311203e45f47e0c59aacd287db3acbd96632c",
"created_at": 1686314423,
"kind": 1,
"tags": [
[
"e",
"6767e7c179b1cfb4b52cf2b3560e3ffc1d7984014864bc4d8018df160af49eb8",
"",
"root"
],
[
"e",
"e7783d655c45c40a43b92448dc709e7cb15f99b4f4a4a612d066afe320ac00ec",
"",
"reply"
],
[
"p",
"959eb280edea3dd6860e6c11fd06e4d3e30bf714829217fc2673b61df57613bb"
]
],
"content": "📅 Original date posted:2021-06-30\n📝 Original message:\nhello René,\n\nI think the idea of having separate standards is good because we can\nkeep the core spec mandatory and other things optional.\n\nSince the core spec, defined by the BOLTs, is mandatory, it's better\nif it's as small as possible, basically barely enough to allow peers\nto talk to each other and open a channel, then define what an HTLC is\nand the basic payment flow.\n\nAll the rest is optional. The BOLTs themselves encourage\nexperimentation by having TLVs, rules for optional and experimental\nmessage type numbers and so on.\n\nAnd then it doesn't make sense to put optional things in the BOLTs\notherwise no one will be spec-compliant anymore and it will cause\nconfusion.\n\nSome things, like splicing and dual-funded channels could be created\nas blips and after everybody had implemented them moved to the BOLTs,\nother things, like the podcast tipping protocol, cannot.\n\nStill, it is better to have a spec for the podcast tipping protocol\nthan to not have, or to have it hidden somewhere. It makes it more\nopen and easier for everyone.\n\nUltimately I think dual-funded channels, trampoline routing and other\nlower level things should still be kept out of the BOLTs as long as\nthey are optional. While things like splicing and blinded paths seem\nto be more like things that should enforced. This is my opinion, but I\nthink it's good to have this clear distinction.\n\nFinally, a list of other things that deserve a spec so they are made\nstandard and interoperable across wallets and services:\n\n1. keysend\n2. AMP\n3. hosted channels\n4. trampoline routing v1\n5. trampoline routing v2\n6. turbo channels\n7. podcast tipping protocol\n8. dual-funding\n9. on-demand channels\n10. sphinx chat messaging thing\n11. private routing as done by immortan\n12. alternative graph for unannounced channels as done by immortan\n13. lnurl-withdraw\n14. lnurl-pay\n15. lnurl-channel\n16. bitcoin-liquid lightning bridge\n17. I thought I had more but apparently I forgot\n\nSo we have to hunt these people down and make them submit specs.\n\n---\nfiatjaf\n\n2021-06-30 16:35 (GMT+02:00), \"René Pickhardt via Lightning-dev\"\n\u003clightning-dev at lists.linuxfoundation.org\u003e said:\n\u003e Hey everyone,\n\u003e just for reference when I was new here (and did not understand the processes\n\u003e well enough) I proposed a similar idea (called LIP) in 2018 c.f.:\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-July/001367.html\n\u003e I wonder what exactly has changed in the reasoning by roasbeef which I will\n\u003e repeat here:\n\u003e We already have the equiv of improvement proposals: BOLTs. Historically new\n\u003e standardization documents are proposed initially as issues or PR's when\n\u003e ultimately accepted. Why do we need another repo?\n\u003e As far as I can tell there was always some form of (invisible?) barrier to\n\u003e participate in the BOLTs but there are also new BOLTs being offered:\n\u003e * BOLT 12: https://github.com/lightningnetwork/lightning-rfc/pull/798\n\u003e * BOLT 14: https://github.com/lightningnetwork/lightning-rfc/pull/780\n\u003e and topics to be included like:\n\u003e * dual funding\n\u003e * splicing\n\u003e * the examples given by Ryan\n\u003e I don't see how a new repo would reduce that barrier - Actually I think it\n\u003e would even create more confusion as I for example would not know where\n\u003e something belongs. That being said I think all the points that are addressed in\n\u003e Ryan's mail could very well be formalized into BOLTs but maybe we just need to\n\u003e rethink the current process of the BOLTs to make it more accessible for new\n\u003e ideas to find their way into the BOLTs? One thing that I can say from answering\n\u003e lightning-network questions on stackexchange is that it would certainly help if\n\u003e the BOLTs where referenced on lightning.network web page and in the whitepaper\n\u003e as the place to be if one wants to learn about the Lightning Network\n\u003e with kind regards Rene\n\u003e On Wed, Jun 30, 2021 at 4:10 PM Ryan Gentry via Lightning-dev wrote:\n\u003e\n\u003e\n\u003e\n\u003e Hi all,\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e The recent thread around zero-conf channels [1] provides an opportunity to\n\u003e discuss how the BOLT process handles features and best practices that\n\u003e arise in the wild vs. originating within the process itself. Zero-conf\n\u003e channels are one of many LN innovations on the app layer that have\n\u003e struggled to make their way into the spec. John Carvalho and Bitrefill\n\u003e launched Turbo channels in April 2019 [2], Breez posted their solution to\n\u003e the mailing list for feedback in August 2020 [3], and we know at least\n\u003e ACINQ and Muun (amongst others) have their own implementations. In an\n\u003e ideal world there would be a descriptive design document that the app\n\u003e layer implementers had collaborated on over the years that the spec group\n\u003e could then pick up and merge into the BOLTs now that the feature is deemed\n\u003e spec-worthy.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Over the last couple of months, we have discussed the idea of adding a\n\u003e BIP-style process (bLIPs? SPARKs? [4]) on top of the BOLTs with various\n\u003e members of the community, and have received positive feedback from both\n\u003e app layer and protocol devs. This would not affect the existing BOLT\n\u003e process at all, but simply add a place for app layer best practices to be\n\u003e succinctly described and organized, especially those that require\n\u003e coordination. These features are being built outside of the BOLT process\n\u003e today anyways, so ideally a bLIP process would bring them into the fold\n\u003e instead of leaving them buried in old ML posts or not documented at all.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Some potential bLIP ideas that people have mentioned include: each lnurl\n\u003e variant, on-the-fly channel opens, AMP, dynamic commitments, podcast\n\u003e payment metadata, p2p messaging formats, new pathfinding heuristics,\n\u003e remote node connection standards, etc.\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e If the community is interested in moving forward, we've started a branch\n\u003e [5] describing such a process. It's based on BIP-0002, so not trying to\n\u003e reinvent any wheels. It would be great to have developers from various\n\u003e implementations and from the broader app layer ecosystem volunteer to be\n\u003e listed as editors (basically the same role as in the BIPs).\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Looking forward to hearing your thoughts!\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e Best,\n\u003e Ryan\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e [1]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-June/003074.html\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e [2]\n\u003e https://www.coindesk.com/bitrefills-thor-turbo-lets-you-get-started-with-bitcoins-lightning-faster\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e [3]\n\u003e https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-August/002780.html\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e [4] bLIP = Bitcoin Lightning Improvement Proposal and SPARK =\n\u003e Standardization of Protocols at the Request of the Kommunity (h/t fiatjaf)\n\u003e\n\u003e\n\u003e\n\u003e\n\u003e [5]\n\u003e https://github.com/ryanthegentry/lightning-rfc/blob/blip-0001/blips/blip-0001.mediawiki\n\u003e\n\u003e\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\u003e --\n\u003e https://www.rene-pickhardt.de_______________________________________________\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",
"sig": "db74f038365d86c78823911ed5f8a6067f38a407fd726589c23f80f185b94aefbf55cb418bd7570110f09da03d7a2c9ca287d38e3495edb54eaf6d662961e3c3"
}