Re: [Lightning-dev] A Note on Public Communication
Perhaps we need another moderator or two for the lightning-dev mailing list? There are already a lot of emails on the bitcoin-dev mailing list and so despite my views on the trend of Bitcoin and Lightning discussion becoming increasingly intertwined it probably makes sense to keep both bitcoin-dev and lightning-dev lists and just bump the number of moderators on lightning-dev. Thanks Michael -- Michael Folkson Email: michaelfolkson at protonmail.com GPG: A2CF5D71603C92010659818D2A75D601B23FEE0F Learn about Bitcoin: https://www.youtube.com/@portofbitcoin --- Original Message --- On Monday, May 8th, 2023 at 22:07, Vincenzo Palazzo wrote: > > Is there a better place to have public communication? Unfortunately since > > one off topic email was sent here, it's been a ghost town. It appears that > > there's many emails being held and only one moderator that checks them once > > a week. > > > > Would hate to see this list die but wondering if there's a better place for > > discussions? > > > I think currently the list is the most accessible way that we have. > > I am not aware of any other tools that are as accessible as the list archive > to search for some history, and also to allow people in 10 years from now to > implement some of the ideas proposed these days. > > But I would agree to change communication tools if we do not lose these > two properties. > > Cheers. > > Vincent. > ___ > 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
Re: [Lightning-dev] A Note on Public Communication
> Is there a better place to have public communication? Unfortunately since one > off topic email was sent here, it's been a ghost town. It appears that > there's many emails being held and only one moderator that checks them once a > week. > > Would hate to see this list die but wondering if there's a better place for > discussions? I think currently the list is the most accessible way that we have. I am not aware of any other tools that are as accessible as the list archive to search for some history, and also to allow people in 10 years from now to implement some of the ideas proposed these days. But I would agree to change communication tools if we do not lose these two properties. Cheers. Vincent. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] A Note on Public Communication
Well, you could always send to bitcoin-...@lists.linuxfoundation.org -- we are usually pretty fast with email modqueue. On Mon, May 8, 2023 at 3:26 PM Tony Giorgio via Lightning-dev < lightning-dev@lists.linuxfoundation.org> wrote: > Is there a better place to have public communication? Unfortunately since > one off topic email was sent here, it's been a ghost town. It appears that > there's many emails being held and only one moderator that checks them once > a week. > > Would hate to see this list die but wondering if there's a better place > for discussions? > > Tony > > > > > > > Original Message > On Apr 29, 2023, 9:57 PM, niftynei < nifty...@gmail.com> wrote: > > > Hi all, > > When I joined the lightning community a few years ago, I was relatively > new to open source software and specification work. Rusty really impressed > on me on the importance of holding conversations, as much as possible in > public. > > Practically speaking, this encompasses IRC, this mailing list, and github > issues/PRs. > > The reason for this is twofold. It helps document the range of options > considered for technical decisions and it provides an interface point for > new participants to contribute to the discussion. > > Given some recent mails that were posted to this list, now seems like a > good time to reiterate the importance and preference of public > communication whenever possible, especially for specification or technical > discussions. > > > ~ nifty > > ___ > Lightning-dev mailing list > Lightning-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev > > -- - Bryan https://twitter.com/kanzure ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi, I think the HTLC endorsement scheme as proposed is still suffering from a > vulnerability as local reputation can be built up during periods of low > routing fees, endorsement gained and then abused during periods of high > routing fees. Therefore, it sounds to me this scheme should aim for some > reputational transitivity between incoming traffic and outgoing traffic. > Namely, the acquisition cost of the local reputation should be equal to the > max timevalue damage that one can inflict on a routing node channel > accessible from its local counterparty granting this high-level of > reputation. > This is the reason we have a moving window for the calculation. Note that if there is a channel between Alice and Bob, then the reputation of Alice from Bob's point of view is a function of Bob's total revenue in the latest time period. If Bob experiences a spike in routing fees, nodes might lose their reputation, but it would not work the other way around. That is, one cannot gain reputation during low fee times and use it when fees are high. See further details in this email [0] Best, Clara [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-February/003857.html ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs
Good morning t-bast, and list, Dual-funded 0-conf can be made safe in the following case: * If the initiator uses swap-in-potentiam addresses (with initiator as Alice, acceptor as Bob). If the initiator stalls, then the acceptor can retaliate by refusing to sign the swap-in-potentiam UTXOs forever after that, thus also locking their funds until the swap-in-potentiam times out, thus preventing this liquidity griefing from being cost-free. The expected use-case is that a user expects onchain operations to be slow and take multiple confirmations to receive. Once there is deep confirmation that a swap-in-potentiam address has been funded, then it can be transferred immediately to a 0-conf Lightning channel. The initiator still needs to trust that the acceptor does not double-spend out from under the initiator, but see LSPS3 Promise To Unconditionally Fund 0-conf. Also, it looks like you are allowing for the initiator to trust the acceptor in that case, as I believe you are taking the point of view of the acceptor of the dual-funding flow. Regards, ZmnSCPxj ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Call For Review - LSPSpec LSPS1 LSPS2
Good morning list, I would like to point out that one of the main issues with LSPs is that most of them are designed to lock in their customers to their platform. Hopefully, with a common open specification like this, it becomes significantly more feasible for Lightning end-user clients to be able to switch across different LSPs. In particular, I have always pointed out that unpublished channels leak information about your sends and receives to the published node end of the channel. Thus, if you are locked to a particular single LSP, your data belongs to them. You might trust your LSP today to not leak your data. But you might not want to trust your LSP tomorrow. LSPs can be bought out, their operators can change their minds, their servers can be hacked and your data stolen, many things can be done to take your data. And if one end is published while the other end is completely unpublished, an unpublished channel will always leak the sends and receives of the unpublished end, and not even PTLCs can hide that information. If you, as a client, are capable of using multiple LSPs simultaneously (which would be greatly assisted if multiple LSPs implemented this common specification) then you are able to spread out your information across multiple LSPs. That way, only part of your data is at risk of being leaked if one LSP goes rogue and sells your data. Wallet clients might also want to use different node IDs for each LSP (if you have your privkey always online --- which is likely since Lightning really wants online signing --- you can use an HMAC of the LSP node ID with your privkey to generate your per-LSP node ID) to further improve their privacy across LSPs. Thus, I strongly suggest that wallet implementors in particular look at the LSPS specifications and start planning to implement the client-side interfaces. The best Lightning Network, if we must have any unpublished channels at all (in my opinion, unpublished channels delenda est), is one where every published node is an LSP. -- I observe that there have been many new innovations in Lightning, such as "Lightning addresses", which are not even vaguely alluded to in lightning-dev. Thus, I would like to point out this post once again: https://lists.linuxfoundation.org/pipermail/lightning-dev/2023-April/003915.html I would like to continue this post with a short discussion of the so-called "LSPS0", which underlies the LSPS1 and LSPS2 we are asking review for. LSPS0 describes how a client makes requests to an LSP. In brief, it uses a single BOLT8 message ID, 37913, for all LSPS client and LSP intercommnications. The rationale for this is: * Every client needs to somehow talk the BOLT8 protocol to an LSP just to do normal channel opens, HTLC sends, HTLC receives, etc.; using the BOLT8 protocol means you do not have to add more dependencies just to be LSPS-compliant. * Using a single BOLT8 message ID, 37913, makes it more likely that new protocols will not conflict with LSPS. The message ID space is a common public good, and it is best to reduce its use as much as possible. All LSPS specification, no matter how many there will be in the future (and I have a fair number lined up after LSPS2), will only use exactly this single BOLT8 message ID. Further, inside the LSPS0 37913 message is a JSON object. This use of JSON inside a BOLT8 message has been described as "disgusting" by at least one engineer, and has been controversial even among LSPS participants. The rationale for this requires a bit of philosophical information theory. In principle, a binary encoding is "just" a compressed encoding of some human-readable format. For example, if we assign some offset within the message as `minimum_depth`, we could consider that the offset is actually a magic number, and that magic number is really inside a compression dictionary, with that magic number expanding to the human-readable text `minimum_depth`. Now compressed encodings like this are fairly fine for computers to process, but humans trying to actually implement LSPS specifications would benefit more from the human-readable text. Thus, I argued that it is better to use a JSON encoding, as any binary encoding would just be equivalent to expanding to an equivalent JSON encoding where the offset of a particular binary-formatted field is really just a compression dictionary entry, mapping out to the text `"minimum_depth": `, and that the "real" uncompressed text would be a JSON encoding. This remains true even if you consider TLVs, as the type number is, again, just a magic number that is mapped, in a static compression dictionary (usually written down in some BOLT spec), to some human-readable label. Now compression is useful if you are doing something like designing a payment onion format. You want to fit a single onion with multiple hops into as few lower-level MTUs as you can, ideally fitting an entire multi-hop onion into a single 150
Re: [Lightning-dev] A new Bitcoin implementation integrated with Core Lightning
Hi Michael,While I don’t think forks of Core with an intent to drive consensus rule changes (or lack thereof) benefits the bitcoin system as the Bitcoin Core project stands today, if you want to build a nice full node wallet with lightning based on a fork of Core, there was code written to do this some years ago.https://github.com/bitcoin/bitcoin/pull/18179It never went anywhere as lightning (and especially LDK!) were far from ready to be a first class feature in bitcoin core at the time (and I’d argue still today), but as a separate project it could be interesting, at least if maintenance burden were kept to a sustainable level.MattOn Jan 14, 2023, at 13:03, Michael Folkson via Lightning-dev wrote:I tweeted this [0] back in November 2022."With the btcd bugs and the analysis paralysis on a RBF policy option in Core increasingly thinking @BitcoinKnots and consensus compatible forks of Core are the future. Gonna chalk that one up to another thing @LukeDashjr was right about all along."A new bare bones Knots style Bitcoin implementation (in C++/C) integrated with Core Lightning was a long term idea I had (and presumably many others have had) but the dysfunction on the Bitcoin Core project this week (if anything it has been getting worse over time, not better) has made me start to take the idea more seriously. It is clear to me that the current way the Bitcoin Core project is being managed is not how I would like an open source project to be managed. Very little discussion is public anymore and decisions seem to be increasingly made behind closed doors or in private IRC channels (to the extent that decisions are made at all). Core Lightning seems to have the opposite problem. It is managed effectively in the open (admittedly with fewer contributors) but doesn't have the eyeballs or the usage that Bitcoin Core does. Regardless, selfishly I at some point would like a bare bones Bitcoin and Lightning implementation integrated in one codebase. The Bitcoin Core codebase has collected a lot of cruft over time and the ultra conservatism that is needed when treating (potential) consensus code seems to permeate into parts of the codebase that no one is using, definitely isn't consensus code and should probably just be removed.The libbitcoinkernel project was (is?) an attempt to extract the consensus engine out of Core but it seems like it won't achieve that as consensus is just too slippery a concept and Knots style consensus compatible codebase forks of Bitcoin Core seem to still the model. To what extent you can safely chop off this cruft and effectively maintain this less crufty fork of Bitcoin Core also isn't clear to me yet.Then there is the question of whether it makes sense to mix C and C++ code that people have different views on. C++ is obviously a superset of C but assuming this merging of Bitcoin Core and Core Lightning is/was the optimal final destination it surely would have been better if Core Lightning was written in the same language (i.e. with classes) as Bitcoin Core.I'm just floating the idea to (hopefully) hear from people who are much more familiar with the entirety of the Bitcoin Core and Core Lightning codebases. It would be an ambitious long term project but it would be nice to focus on some ambitious project(s) (even if just conceptually) for a while given (thankfully) there seems to be a lull in soft fork activation chaos.ThanksMichael[0]: https://twitter.com/michaelfolkson/status/1589220155006910464?s=20&t=GbPm7w5BqS7rS3kiVFTNcw --Michael FolksonEmail: michaelfolkson at protonmail.com Keybase: michaelfolksonPGP: 43ED C999 9F85 1D40 EAF4 9835 92D6 0159 214C FEE3 ___Lightning-dev mailing listLightning-dev@lists.linuxfoundation.orghttps://lists.linuxfoundation.org/mailman/listinfo/lightning___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] HTLC Endorsement for Jamming Mitigation
Hi *, > Our suggestion is to start simple with a binary endorsement field. As > we learn more, we will be better equipped to understand whether a > more expressive value is required. I think the HTLC endorsement scheme as proposed is still suffering from a vulnerability as local reputation can be built up during periods of low routing fees, endorsement gained and then abused during periods of high routing fees. Therefore, it sounds to me this scheme should aim for some reputational transitivity between incoming traffic and outgoing traffic. Namely, the acquisition cost of the local reputation should be equal to the max timevalue damage that one can inflict on a routing node channel accessible from its local counterparty granting this high-level of reputation. I don't know if this can be fixed by ensuring permanent link-level "gossip" where counterparties along a payment path expose their reputation heuristics to guarantee this transitivity, or it's a fundamental issue with a point-to-point approach like HTLC endorsement. Opened an issue on the repository to converge on a threat model: https://github.com/ClaraShk/LNJamming/pull/13 I still think building data gathering infrastructure for Lightning is valuable as ultimately any jamming mitigation will have to adapt its upfront fees or reputation acquisition cost in function of HTLC traffic and market forces. Looking forward to giving an update on Staking Credentials [0], an end-to-end approach to mitigate channel jamming. Best, Antoine [0] https://lists.linuxfoundation.org/pipermail/lightning-dev/2022-November/003754.html Le dim. 30 avr. 2023 à 03:57, Carla Kirk-Cohen a écrit : > Hi list, > > Some updates on channel jamming! > > # Next Call > - Monday 01 May @ 15:00 UTC > - https://meet.jit.si/UnjammingLN > - Agenda: https://github.com/ClaraShk/LNJamming/issues/12 > > # Data Gathering > During these weekly calls, we've come to agreement that we would like > to gather data about the use of HTLC endorsement and local reputation > tracking for jamming mitigation. A reminder of the full scheme is > included at the end of this email, and covered more verbosely in [1]. > > We have a few goals in mind: > - Observe the effect of endorsement in the steady state with > logging-only implementation. > - Gather real-world data for use in future simulation work. > - Experiment with different algorithms for tracking local reputation. > > The minimal changes required to add HTLC endorsement are outlined in [2]. > Our suggestion is to start simple with a binary endorsement field. As > we learn more, we will be better equipped to understand whether a > more expressive value is required. > > With this infrastructure in place, we can start to experiment with > various local reputation schemes and data gathering, possibly even > externally to LN implementations in projects like circuitbreaker [3]. > We'd be interested to hear whether there's any appetite to deploy using > an experimental TLV value? > > # Reputation Scheme > - Each node locally tracks the reputation of its direct neighbors. > - Each node allocates, per its risk tolerance: > - A number of slots reserved for endorsed HTLCs from high reputation > peers. > - A portion of liquidity reserved for endorsed HTLCs from high > reputation peers. > - Forwarding of HTLCs: > - If a HTLC is endorsed by a high reputation peer, it is forwarded > as usual with endorsed = 1. > - Otherwise, it is forwarded with endorsed = 0 if there are slots and > liquidity available for unknown HTLCs. > > Endorsement and reputation are proposed as the first step in a two part > scheme for mitigating channel jamming: > - Reputation for slow jams which are easily detected as misbehavior. > - Unconditional fees for quick jams that are difficult to detect, as > they can always fall under a target threshold. > > Looking forward to discussing further in the upcoming call! > > Best, > Carla and Clara > > [1] https://gist.github.com/carlaKC/be820bb638624253f3ae7b39dbd0e343 > [2] https://github.com/lightning/bolts/pull/1071 > [3] https://github.com/lightningequipment/circuitbreaker > ___ > 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
Re: [Lightning-dev] A Note on Public Communication
Is there a better place to have public communication? Unfortunately since one off topic email was sent here, it's been a ghost town. It appears that there's many emails being held and only one moderator that checks them once a week. Would hate to see this list die but wondering if there's a better place for discussions? Tony Original Message On Apr 29, 2023, 9:57 PM, niftynei wrote: > Hi all, > > When I joined the lightning community a few years ago, I was relatively new > to open source software and specification work. Rusty really impressed on me > on the importance of holding conversations, as much as possible in public. > > Practically speaking, this encompasses IRC, this mailing list, and github > issues/PRs. > > The reason for this is twofold. It helps document the range of options > considered for technical decisions and it provides an interface point for new > participants to contribute to the discussion. > > Given some recent mails that were posted to this list, now seems like a good > time to reiterate the importance and preference of public communication > whenever possible, especially for specification or technical discussions. > > ~ nifty___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
