Re: [Lightning-dev] Potential vulnerability in Lightning backends: BOLT-11 "payment hash" does not commit to payment!
On Thu, Jul 13, 2023 at 3:47 AM David A. Harding wrote: > My question is whether you think it would be worthwhile to ask > developers of the underlying LN node implementations you use to support > self-payment of their own invoices (if they don't already). As far as I know no Lightning node has this ability, which is very unfortunate. If possible this should definitely be implemented. It would be the biggest feature for custodial Lightning service providers of all kinds since always. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Payment sender authentication
Hi Joost, On Mon, Dec 20, 2021 at 5:02 AM Joost Jager wrote: > Hi fiatjaf and peter, > > On Sat, Dec 18, 2021 at 2:08 PM fiatjaf wrote: > >> As a temporary solution, I suggest taking a look at >> https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that >> you can either provide >> - a lone pubkey (to be used for manually identifying the payer later if >> necessary); >> - a domain-specific pubkey along with a signature of a challenge >> provided by the receiver; or >> - an unauthenticated name or email (for light things like donations for >> which one may not care very much about cryptographic authentication). >> And then you commit these things, whatever they are, inside the BOLT11 >> payment request using the 'h' tag. >> > > Interesting read. I see it uses a signature, but is that a good idea? It > could allow the receiver to prove to a 3rd party that the payment was made. > I guess it depends on the application if that is desired or not. The more > privacy conscious users would probably try to avoid committing to data via > a signature. > Just to clarify: For the lone pubkey method there are no privacy implications I think, since it's just a random pubkey and can be used later only if needed in some custom way. For the signature method the privacy implications are close to none (unless I'm missing something) because the key used to sign is (supposed to be) generated by a method that makes it specific to the DNS domain of the service being paid. Since this assumes an LNURL request that has a domain, the key will be generated with something like `HMAC(domain, seed_key)` (the specifics don't matter) so it will not be possible for anyone to relate that signature to anyone. Only the receiver service will be able to relate it to other payments (or logins) to that same exact service -- which can prove quite handy in many cases. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Payment sender authentication
Good morning, Joost. As a temporary solution, I suggest taking a look at https://github.com/fiatjaf/lnurl-rfc/blob/luds/18.md. The idea is that you can either provide - a lone pubkey (to be used for manually identifying the payer later if necessary); - a domain-specific pubkey along with a signature of a challenge provided by the receiver; or - an unauthenticated name or email (for light things like donations for which one may not care very much about cryptographic authentication). And then you commit these things, whatever they are, inside the BOLT11 payment request using the 'h' tag. fiatjaf On Fri, Dec 17, 2021 at 7:37 AM Joost Jager wrote: > Hello list, > > In Lightning we have a great scheme to protect the identity of the sender > of a payment. This is awesome, but there are also use cases where opt-in > sender authentication is desired. > > An example of such a use case is chat over lightning. If you receive a > text message, you generally want to know whom it originates from. For > whatsat [1], I added a custom record containing an ECDSA signature over > `sender | recipient | timestamp | msg`. I believe other chat protocols on > lightning use a similar construction. > > For regular payments however, sender authentication can be useful too. A > donation for example doesn't always need to be anonymous. A donor may want > to reveal themselves. In other cases, sender authentication can add a layer > of protection against payments getting lost. It provides the receiver with > another field that they can use to retrieve lost payment information. > > On the receiver side, sender authentication also creates new > possibilities. A receiver could for example create an invoice that is > locked to a specific source node. > > Also wanted to note that the sender identity doesn't need to be the actual > node identity. It can also be an unrelated key that could for example be > specific to the service that is being paid to. For example, one registers > the public part of a dedicated key pair with an exchange and the exchange > then only accepts deposits authenticated with that key. > > The reason for bringing this up on the list is that I wanted to see what > people think is the best way to do it technically. The whatsat approach > with an ECDSA signature doesn't look ideal to me because of the > non-repudiation property. Also care needs to be taken that whatever data > the sender includes, cannot be reused. > > Another option that I can think of is to derive a shared secret using ECDH > with the sender and receiver node keys and then attach a custom record to > the payment containing the sender node key and an HMAC of the payment hash > using the shared secret as a key. > > I am sure there people better versed in cryptography than me who have an > opinion on this. Thoughts? > > Joost > > [1] https://github.com/joostjager/whatsat > ___ > 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] Stateless invoices with proof-of-payment
Indeed, sorry, I misunderstood it because I read AMP/keysend and assumed you were talking about payer-generated preimage. It doesn't help that "payer" and "payee" are so similar words. So yes, I agree very much. I also think the part about including the order details inside the TLV would be very good to have. I would say, however, that these are two separate proposals: 1. implementations should expose a "stateless invoice" API for receiving using the payment_secret; 2. when sending, implementations should attach a TLV record with encoded order details. Of these, 1 is very simple to do and do not require anyone to cooperate, it just works. 2 requires full network compatibility, so it's harder. But 2 is also very much needed otherwise the payee has to keep track of all the invoice ids related to the orders they refer to, right? But I think just having 1 already improves the situation a lot, and there are application-specific workarounds that can be applied for 2 (having a fixed, hardcoded set of possible orders, encoding the order very minimally in the payment secret or route hint, storing order details on redis for only 3 minutes and using lnurlpay to reduce the delay between invoice issuance and user confirmation to zero, and so on). On Tue, Sep 21, 2021 at 9:41 AM Joost Jager wrote: > On Tue, Sep 21, 2021 at 2:05 PM fiatjaf wrote: > >> What if instead of the payer generating the preimage the payee could >> generate stateless invoices? Basically just use some secret to compute the >> preimage upon receiving the HTLC, for example: >> > > Maybe my explanation wasn't clear enough, but this is exactly what I am > proposing. The payee generates a stateless invoice and gives it to the > payer. > > >> 1. Payer requests an invoice. >> 2. Payee computes hash = sha256(hmac(local_secret, >> arbitrary_invoice_id)), then encodes arbitrary_invoice_id into the invoice >> somehow. >> 3. Payer sends payment with arbitrary_invoice_id as tlv_record_a. >> 4. Upon receiving the HTLC, payee computes preimage = hmac(local_secret, >> tlv_record_a) and resolves it. >> > > One way to do this that I tried to describe in the initial post is via the > payment_secret. This is already an arbitrary invoice id that is already > sent as a tlv record. > > >> I've implemented such a scheme on @lntxbot, but it required low level >> code in a c-lightning plugin and a hack with route hints: since TLV >> payloads were not an option (as payers wouldn't know how to send them) I've >> used a "shadow" route hint to a private channel that didn't exist, so >> preimage was generated on the payee using preimage = hmac(local_secret, >> next_channel_scid). >> > > Clever workaround. > > Joost > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Stateless invoices with proof-of-payment
What if instead of the payer generating the preimage the payee could generate stateless invoices? Basically just use some secret to compute the preimage upon receiving the HTLC, for example: 1. Payer requests an invoice. 2. Payee computes hash = sha256(hmac(local_secret, arbitrary_invoice_id)), then encodes arbitrary_invoice_id into the invoice somehow. 3. Payer sends payment with arbitrary_invoice_id as tlv_record_a. 4. Upon receiving the HTLC, payee computes preimage = hmac(local_secret, tlv_record_a) and resolves it. I've implemented such a scheme on @lntxbot, but it required low level code in a c-lightning plugin and a hack with route hints: since TLV payloads were not an option (as payers wouldn't know how to send them) I've used a "shadow" route hint to a private channel that didn't exist, so preimage was generated on the payee using preimage = hmac(local_secret, next_channel_scid). If however node implementations could provide such a thing it would reduce database requirements and improve the lives of application developers very much. On Tue, Sep 21, 2021 at 7:09 AM Joost Jager wrote: > Problem > > One of the qualities of lightning is that it can provide light-weight, > no-login payments with minimal friction. Games, paywalls, podcasts, etc can > immediately present a QR code that is ready for scan and pay. > > Optimistically presenting payment requests does lead to many of those > payment requests going unused. A user visits a news site and decides not to > buy the article. The conventional approach is to create a lightning invoice > on a node and store the invoice together with order details in a database. > If the order then goes unfulfilled, cleaning processes remove the data from > the node and database again. > > The problem with this setup is that it needs protection against unbounded > generation of payment requests. There are solutions for that such as rate > limiting, but wouldn't it be nice if invoices can be generated without the > need to keep any state at all? > > Stateless invoices > > What would happen if a lightning invoice is only generated and stored > nowhere on the recipient side? To the user, it won't make a difference. > They would still scan and pay the invoice. When the payment arrives at the > recipient though, two problems arise: > > 1. Recipient doesn't know whom or what the payment is for. > > This can be solved by attaching additional custom tlv records to the htlc. > On the wire, this is all arranged for. The only missing piece is the > ability to specify additional data for that custom tlv record in a bolt11 > invoice. One way would be to define a new tagged field for this in which > the recipient can encode the order details. > > An alternative is to use the existing invoice description field and simply > always pass that along with the htlc as a custom tlv record. > > A second alternative that already works today is to use part (for example > 16 out of 32 bytes) of the payment_secret (aka payment address) to encode > the order details in. This assumes that the secret is still secret enough > with reduced entropy. Also there may not be enough space for every > application. > > 2. Recipient doesn't know the preimage that is needed to settle the > htlc(s). > > One option is to use a keysend payment or AMP payment. In that case, the > sender includes the preimage with the htlc. Unfortunately this doesn't > provide the sender with a proof of payment that they'd get with a regular > lightning payment. > > An alternative solution is to use a deterministic preimage based on a > (recipient node key-derived) secret, the payment secret and other relevant > properties. This allows the recipient to derive the same preimage twice: > Once when the lightning invoice is generated and again when a payment > arrives. > > It could be something like this: > > payment_secret = random > preimage = H(node_secret | payment_secret | payment_amount | > encoded_order_details) > invoice_hash = H(preimage) > > The sender sends an htlc locked to invoice_hash for payment_amount and > passes along payment_secret and encoded_order_details in a custom tlv > record. > > When the recipient receives the htlc, they reconstruct the preimage > according to the formula above. At this point, all data is available to do > so. When H(preimage) indeed matches the htlc hash, they can settle the > payment knowing that this is an order that they committed to earlier. > Settling could be implemented as a just-in-time inserted invoice to keep > the diff small. > > The preimage is returned to the sender and serves as a proof of payment. > > Resilience > > To me it seems that stateless invoices can be a relatively simple way to > improve the resiliency of systems that deal with lightning invoices. > Unlimited amounts of invoices can be generated without worrying about > storage or memory, no matter if the requests are due to popularity of a > service or a deliberate dos attack. > > Interested to hear your though
Re: [Lightning-dev] DNS records for LN nodes
I think this is a good idea. A very simple change that can improve usability. Anyone can already do this today if they want, by just shoving data into DNS records and telling people to confirm from there, but it would be nice if it was standardized in a bLIP[0] just so everybody does it in the same way. Additionally there could be the reverse link in which nodes publish their domain names as their alias and that is confirmed with the DNS record. Then we'll finally be able to identify and trust the payee pubkeys in invoices! [0]: https://github.com/lightningnetwork/lightning-rfc/pull/884 On Sun, Sep 12, 2021 at 8:02 PM Andy Schroder wrote: > Hello, > > We have the @host format for defining a connection to a LN node. > > I'm wondering if it makes any sense to create DNS records that apply to LN > nodes to serve this same information? For example: > >- example.com. IN LN ln.example.com. > - Allows assigning an alternate host name for the ln node for a > domain, like an mail server has an MX record > - example.com. IN TXT "LNpubkey=ybRK9h6OYmB3I4VroZBQogIadciFTw" > - Allows storing the pubkey for the LN node in a DNS record > > > If one didn't know the LN node for example.com, they could query the LN > and TXT records and then find the information and make a connection using > the familiar ybrk9h6oymb3i4vrozbqogiadci...@ln.example.com format. This > may be of interest because if someone wants to open a channel in advance to > a company's LN node because they know they will be receiving an invoice > from them in the future, and they want open a channel directly in order to > ensure a good route (and they want the channel to be fully confirmed/opened > by the time they receive the invoice). This could be particularly useful > when dealing with machines in the physical world where you want an easy way > to make a connection and channel to with a human readable string that is > printed on the machine, but don't even want to deal with QR codes or NFC > (for example, your desktop computer likely doesn't have either of those > capabilities). > > Right now, the host names associated with LN nodes that are found using > the peer to peer gossip are more on the honor system as I understand it. If > these records existed, one could also validate the information found using > the peer to peer gossip protocol. > > I do realize that the DNS root servers are governed by a centralized > entity, so this approach has it's flaws, but we could consider it sort of > complimentary to the peer to peer gossip protocol. DNS does have a nice > scaling property in that it is hierarchically distributed, so it may be > more efficient long term than every user having a full view of the LN via > the gossip protocol in order to find the information needed, especially > when we can replace the DNS root servers with something that is under > decentralized control. > > lnurl-rfc seems to be doing a good job at creating workflows for payers > and payees. However, I'm not sure if a definition like I've suggested above > fits better in lnurl-rfc or as part of a BOLT. > > > Let me know of your thoughts, > > -- > Andy Schroder > > ___ > 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
[Lightning-dev] No more closed channels because of fake HTLCs
Good morning, I think we must stop closing channels to redeem trimmed HTLCs. It makes no sense at all. It's bad for everybody, there is not a single upside to closing a channel to redeem a trimmed HTLC. (Please let me know if you don't agree with the above and what are the things I'm missing.) Now I understand this is not trivial, because if we just decide to stop closing, what do we do? It's not obvious -- and actually it may not even be possible to come up with a decent course of action. I've written two or more blog posts trying to explain the issue (mostly to myself)(see https://fiatjaf.com/401367e9.html and links), but skipping the problem and going to the solutions directly, I see three possible approaches (and they can all be implemented, in sequence, gradually): 0. Never have stalled HTLCs again (just kidding, this will never happen). 1. Just don't close. The channel keeps working. It's bad but at least you don't have to close and open again (this is probably not safe against evil people, but Lightning itself isn't anyway, right?). 2. Try to negotiate: if a peer knows it is at fault (for having been offline while the HTLC expired, for example) it can eat the costs of that HTLC just so the other side doesn't close the channel, and vice-versa (this will probably not work in most situations, but may work in some, I don't know enough to say). 3. Use an arbiter (this is my favorite): the two peers can agree on an arbiter when creating the channel. The arbiter can act as a proxy for when peers can't establish connection with each other; revoke/fulfill messages can be sent to the arbiter if the other peer is unresponsive; the arbiter has authority to say who sent each message at each time and therefore who must get the sats in that HTLC. If a peer doesn't obey the arbiter's decision the other must blacklist it forever. The arbiter can be anything: another Lightning node, a set of Lightning nodes, Twitter or any established internet service that allows arbitrary content to be published in public, this mailing list etc. (The arbiter idea may be sounding silly to you, but anything is better than what we have now. In all the suggestions above, the fallback, worst case scenario, is closing the channel. Today we live in the worst case scenario.) Thank you for reading. --- fiatjaf ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Removing the Dust Limit
For the Lightning point, even if the dust limit was removed Lightning would still be trimming any HTLCs below the amount they cost to redeem in fees, so that wouldn't make any difference. Nonetheless I think reason 1 should be enough. 2021-08-08 11:52 (GMT-07:00), Jeremy said: > We should remove the dust limit from Bitcoin. Five reasons: > 1) it's not our business what outputs people want to create > 2) dust outputs can be used in various authentication/delegation smart > contracts > 3) dust sized htlcs in lightning ( > https://bitcoin.stackexchange.com/questions/46730/can-you-send-amounts-that-would-typically-be-considered-dust-through-the-light > ) force channels to operate in a semi-trusted mode which has implications > (AFAIU) for the regulatory classification of channels in various > jurisdictions; > agnostic treatment of fund transfers would simplify this (like getting a 0.01 > cent dividend check in the mail) > 4) thinly divisible colored coin protocols might make use of sats as value > markers for transactions. > 5) should we ever do confidential transactions we can't prevent it without > compromising privacy / allowed transfers > The main reasons I'm aware of not allow dust creation is that: > 1) dust is spam > 2) dust fingerprinting attacks > 1 is (IMO) not valid given the 5 reasons above, and 2 is preventable by well > behaved wallets to not redeem outputs that cost more in fees than they are > worth. > cheers, > jeremy > -- > @JeremyRubin___ > 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] bLIPs: A proposal for community-driven app layer and protocol extension stand
If the BIPs can allow very small standards related to a small niche of Lightning usage, then I think they are the place for everything indeed. I'm convinced. Thinking about proposing the LNURL specs as BIPs now, but then I don't know if it will be weird for them to exist alone there, without the basis of the lightning technology to support them. I hope the BOLT authors investigate moving them there too so the other Lightning BIPs can add the BOLT BIPs as "Required". The only question to me is this: should each BOLT be a BIP? Or all BOLTs be mashed together as a single BIP? Then what happens when Taproot-based channels, PTLCs or Eltoo-based channels get implemented? They are added as new BIPs that inherit and modify the previous? I also went through https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist and to me they seem to be all good proposals (specially the list of projects/services implementing the BIP). Except BIP versioning. I like that BIPs have meaningless numbers, just add another BIP and refer to it by a number. For that reason I also don't like prepending an "L" to Lightning-related BIPs (more so because some of these may be reused later in non-Lightning contexts, who knows?). Anyway I'm fine with anything. On Fri, Jul 2, 2021 at 4:32 PM Luke Dashjr wrote: > Yes, many systems doesn't really make sense. We can add editors and revise > the > BIP process as needed (BOLTs might prefer to use markdown?). Even aside > from > Lightning BIPs, there are several improvements that can be made, so it > makes > sense to address everything at once. > > https://github.com/bitcoin/bips/wiki/BIP-Process-wishlist > > The BIP 2xx range has been set aside for Lightning years ago, and we can > do > similar things to help keep things organized within BIPs. Kalle suggested > maybe it'd be better to do BIP "L###" instead, and perhaps that would work > better if there's likely to be several sub-namespaces. > > Luke > > > On Friday 02 July 2021 12:02:28 Dan Gershony wrote: > > Hi, > > There will be many layer 2 (and probably layer 3) protocols (BOLT, RGB, > > Volts etc...) does it really make sense to merge them all into the BIPs > > system? > > > > > > On Fri, Jul 2, 2021 at 10:03 AM nathanael via Lightning-dev < > > > > lightning-dev@lists.linuxfoundation.org> wrote: > > > Michael Folkson wrote: > > > > > Adding a third BIP editor more involved with Lightning sounds like > a > > > > > > good idea. > > > > > > > Or alternatively if BOLTs were subsumed into BIPs I think Bastien > > > > would be a great additional BIP editor to cover Lightning related > BIPs > > > > > > > > :) I think BOLTs being subsumed into BIPs would be nice but I'm > > > > > > > > pessimistic it will happen. Like legislation and regulation in the > > > > legacy financial system alphabet soups only expand they never get > > > > simplified. Let's at least resist alphabet soup expansion here. > > > > > > arent lightning improvements in the end bitcoin improvements too? > > > i am thinking of bips like the rfcs of the internet > > > > > > -- > > > nathanael > > > ___ > > > 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 > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization
Here's another feature which just appeared and would benefit from a bLIP for compatibility: https://twitter.com/SimpleBtcWallet/status/1410506889545359365 Atomic splitting of bills. A very small thing, but also very cool. I can't imagine it fitting in the BOLTs at all. 2021-06-30 09:10 (GMT-05:00), Ryan Gentry via Lightning-dev said: > 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@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] bLIPs: A proposal for community-driven app layer and protocol extension standardization
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" 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 pro
Re: [Lightning-dev] Doubt regarding payment channel capacity
Hello, What happens between two peers is no business of others. They can do what you said if they're cooperating, and many other dirty tricks. And that's not a problem at all for other nodes. The only thing they can't do for not is advertise a channel without telling others where it was funded on the chain, but that's just for antispam reasons (as other nodes must keep track of all announced channels) as far as I know. On Thursday, November 14, 2019, Subhra Mazumdar < subhra.mazumdar1...@gmail.com> wrote: > Hello everyone, >My doubt might be silly and apologies for the same. Suppose in a payment channel network say 2 parties B and C are malicious, controlled by same adversary. They had initially opened a channel of 1 BTC. But suppose they get 3 transaction request will flow value of 0.4 BTC each. After 1st 2 transaction, B and C has capacity of 0.2 BTC. But what if BC reports an incorrect residual balance thereby accepting the 3rd transaction. Who will keep track of this capacity violation since no one is keeping track of this residual value ? If this case is true, then parties might resort to such a strategy opening a low value channel but still accepting multiple transactions where the total payment value of all transaction exceeds channel capacity. Please correct me if I am wrong. > > -- > Yours sincerely, > Subhra Mazumdar. > > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
Re: [Lightning-dev] Trampoline Routing
Ok, here's another question/probably-bad-idea: how feasible is it for these trampoline nodes to return the route they've calculated somehow to the original caller so it can cache the route and use it without trampolines the next time? I don't know if caching routes is a good way improve routing overall in larger networks, but it seems to be working well for BLW[1] currently and overall it does make sense: in day-to-day payments we tend to pay the same people and stores over and over, rarely paying someone else (but of course these rare cases are still very common to be ignored). Anyway, I don't enough even to ask the question, but I guess it's theoretically possible for some information to be returned along with the preimage in the payment route, right? There remains a question of if and why the trampoline nodes would be or not interested in cheating Alice, sending back a bad route that favors them, or not returning any route at all as that would undermine their profits as trampolines. [1]: https://lightning-wallet.com/what-does-olympus-server-do On Friday, August 2, 2019, Bastien TEINTURIER wrote: > Good morning list, > > I realized that trampoline routing has only been briefly described to this > list (credits to cdecker and pm47 for laying > out the foundations). I just published an updated PR [1] and want to take > this opportunity to present the high level > view here and the parts that need a concept ACK and more feedback. > > Trampoline routing is conceptually quite simple. Alice wants to send a > payment to Bob, but she doesn't know a > route to get there because Alice only keeps a small area of the routing > table locally (Alice has a crappy phone, > damn it Alice sell some satoshis and buy a real phone). However, Alice has > a few trampoline nodes in her > friends-of-friends and knows some trampoline nodes outside of her local > area (but she doesn't know how to reach > them). Alice would like to send a payment to a trampoline node she can > reach and defer calculation of the rest of > the route to that node. > > The onion routing part is very simple now that we have variable-length > onion payloads (thanks again cdecker!). > Just like russian dolls, we simply put a small onion inside a big onion. > And the HTLC management forwards very > naturally. > > It's always simpler with an example. Let's imagine that Alice can reach > three trampoline nodes: T1, T2 and T3. > She also knows the details of many remote trampoline nodes that she cannot > reach: RT1, RT2, RT3 and RT4. > Alice selects T1 and RT2 to use as trampoline hops. She builds a small > onion that describes the following route: > > *Alice -> T1 -> RT2 -> Bob* > > She finds a route to T1 and builds a normal onion to send a payment to T1: > > *Alice -> N1 -> N2 -> T1* > > In the payload for T1, Alice puts the small trampoline onion. > When T1 receives the payment, he is able to peel one layer of the > trampoline onion and discover that he must > forward the payment to RT2. T1 finds a route to RT2 and builds a normal > onion to send a payment to RT2: > > *T1 -> N3 -> RT2* > > In the payload for RT2, T1 puts the peeled small trampoline onion. > When RT2 receives the payment, he is able to peel one layer of the > trampoline onion and discover that he must > forward the payment to Bob. RT2 finds a route to Bob and builds a normal > onion to send a payment: > > *RT2 -> N4 -> N5 -> Bob* > > In the payload for Bob, RT2 puts the peeled small trampoline onion. > When Bob receives the payment, he is able to peel the last layer of the > trampoline onion and discover that he is > the final recipient, and fulfills the payment. > > Alice has successfully sent a payment to Bob deferring route calculation > to some chosen trampoline nodes. > That part was simple and (hopefully) not controversial, but it left out > some important details: > >1. How do trampoline nodes specify their fees and cltv requirements? >2. How does Alice sync the fees and cltv requirements for her remote >trampoline nodes? > > To answer 1., trampoline nodes needs to estimate a fee and cltv that > allows them to route to (almost) any other > trampoline node. This is likely going to increase the fees paid by > end-users, but they can't eat their cake and > have it too: by not syncing the whole network, users are trading fees for > ease of use and payment reliability. > > To answer 2., we can re-use the existing gossip infrastructure to exchange > a new *node_update *message that > contains the trampoline fees and cltv. However Alice doesn't want to > receive every network update because she > doesn't have the bandwidth to support it (damn it again Alice, upgrade > your mobile plan). My suggestion is to > create a filter system (similiar to BIP37) where Alice sends gossip > filters to her peers, and peers only forward to > Alice updates that match these filters. This doesn't have the issues BIP37 > has for Bitcoin because it has a cost > for Alice: she has to open a ch
Re: [Lightning-dev] Trampoline Routing
Thank you very much. These were very clarifying answers and ramblings. On Monday, August 5, 2019, ZmnSCPxj wrote: > Good morning fiatjaf, > >> No. My question was more like why does Alice decide to build a route that for through T1 and RT2 and not only through one trampoline router she knows. > > If Alice only always used one trampoline node, then the trampoline node can assume the next hop is always the payee, and thus record who the payee is (eroding privacy). > If Alice uses two, then a trampoline node would have a 50/50 chance of knowing who the final payee is, reducing the privacy erosion. > > Similarly, onion routing over Tor typically passes through 3 "trampoline" nodes before going to the actual site being accessed. > >> >> That makes sense you me in the context of ZmnSCPxj's virtual space idea, but not necessarily in the current network conditions. You also said we're going to need some hierarchy, but what it's that? Is it required? > > I believe in the future we will see a public network that is too large to fit on most devices available to most people. > We may or may not want to have such an enormous network, but the cost of advertising a public channel is the same as the cost of creating a non-public channel, thus there is no incentive for random end-user nodes to *not* publish their channels, and incentive to publish (there is a tiny but non-zero chance of being routed through, especially as local-area specializations like JIT-Routing get implemented). > > Thus, I believe it is eventually required that we hierarchicalize how we store information, with a "myopic" detailed channel map and a "rough" global map with just trampoline-payee association mappings. > I think it is best for each payer to define its own hierarchy or split, preferentially with some random component. > > One might consider, however, that my ramblings are too indefinite and it would be better to see the network as it evolves. > > Regards, > ZmnSCPxj > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
[Lightning-dev] Fwd: Trampoline Routing
No. My question was more like why does Alice decide to build a route that for through T1 and RT2 and not only through one trampoline router she knows. That makes sense you me in the context of ZmnSCPxj's virtual space idea, but not necessarily in the current network conditions. You also said we're going to need some hierarchy, but what it's that? Is it required? Anyway, I'm probably missing something, but another way of putting my question would be: why does your example use 2 trampolines instead of 1? On Monday, August 5, 2019, Bastien TEINTURIER wrote: > Good morning fiatjaf, > This is a good question, I'm glad you asked. > As:m ZmnSCPxj points out, Alice doesn't know. By not syncing the full network graph, Alice has to accept > "being in the dark" for some decisions. She is merely hoping that RT2 can find a route to Bob. Note that > it's quite easy to help Alice make informed decision by proving routing hints in the invoice and in gossip > messages (which we already do for "normal" routing). > The graph today is strongly connected, so it's quite a reasonable assumption (and Alice can easily retry > with another choice of trampoline node if the first one fails - just like we do today with normal payments). > I fully agree with ZmnSCPxj though that in the future this might not be true anymore. When/if the network > becomes too large we will likely lose its strongly connected nature. When that happens, the Lightning > Network will need some kind of hierarchical / packet switched routing architecture and we won't require > trampoline nodes to know the whole network graph and be able to route to mostly anyone. > I argue that trampoline routing is a first step towards enabling that. It's a good engineering trade-off between > ease of implementation and deployment, fixing a problem we have today and enabling future scaling for > problems we'll have tomorrow. It's somewhat easy once we have trampoline payments to evolve that to a > system closer to the internet's packet switching infrastructure, so we'll deal with that once the need for it > becomes obvious. > Does that answer your question? > Cheers, > Bastien > Le sam. 3 août 2019 à 05:48, ZmnSCPxj a écrit : >> >> Good morning fiatjaf, >> >> I proposed before that we could institute a rule where nodes are mapped to some virtual space, and nodes should preferably retain the part of the network graph that connects itself to those nodes near to it in this virtual space (and possibly prefer to channel to those nodes). >> >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-April/001959.html >> >> Thus Alice might **not** know that some route exists between T1 and T2. >> >> T1 itself might not know of a route from itself to T2. >> But if T1 knows a route to T1.5, and it knows that T1.5 is nearer to T2 than to itself in the virtual space, it can **try** to route through T1.5 in the hope T1.5 knows a route from itself to T2. >> This can be done if T1 can remove itself from the trampoline route and replace itself with T1.5, offerring in exchange some of the fee to T1.5. >> >> Other ways of knowing some distillation of the public network without remembering the channel level details are also possible. >> My recent pointlessly long spam email for example has a section on Hierarchical Maps. >> >> https://lists.linuxfoundation.org/pipermail/lightning-dev/2019-August/002095.html >> >> Regards, >> ZmnSCPxj >> >> >> Sent with ProtonMail Secure Email. >> >> ‐‐‐ Original Message ‐‐‐ >> On Saturday, August 3, 2019 12:29 AM, fiatjaf wrote: >> >> > Ok, since you seem to imply each question is valuable, here's mine: how does Alice know RT2 has a route to Bob? If she knows that, can she also know T1 has a route to Bob? In any case, why can't she just build her small onion with Alice -> T1 -> Bob? I would expect that to be the most common case, am I right? >> > >> > On Friday, August 2, 2019, Bastien TEINTURIER wrote: >> > >> > > Good morning list, >> > > >> > > I realized that trampoline routing has only been briefly described to this list (credits to cdecker and pm47 for laying >> > > out the foundations). I just published an updated PR [1] and want to take this opportunity to present the high level >> > > view here and the parts that need a concept ACK and more feedback. >> > > >> > > Trampoline routing is conceptually quite simple. Alice wants to send a payment to Bob, but she doesn't know a >> > > route to get there because Alice only keeps a small area of the routing table locally (Alic
Re: [Lightning-dev] Trampoline Routing
Ok, since you seem to imply each question is valuable, here's mine: how does Alice know RT2 has a route to Bob? If she knows that, can she also know T1 has a route to Bob? In any case, why can't she just build her small onion with Alice -> T1 -> Bob? I would expect that to be the most common case, am I right? On Friday, August 2, 2019, Bastien TEINTURIER wrote: > Good morning list, > > I realized that trampoline routing has only been briefly described to this > list (credits to cdecker and pm47 for laying > out the foundations). I just published an updated PR [1] and want to take > this opportunity to present the high level > view here and the parts that need a concept ACK and more feedback. > > Trampoline routing is conceptually quite simple. Alice wants to send a > payment to Bob, but she doesn't know a > route to get there because Alice only keeps a small area of the routing > table locally (Alice has a crappy phone, > damn it Alice sell some satoshis and buy a real phone). However, Alice has > a few trampoline nodes in her > friends-of-friends and knows some trampoline nodes outside of her local > area (but she doesn't know how to reach > them). Alice would like to send a payment to a trampoline node she can > reach and defer calculation of the rest of > the route to that node. > > The onion routing part is very simple now that we have variable-length > onion payloads (thanks again cdecker!). > Just like russian dolls, we simply put a small onion inside a big onion. > And the HTLC management forwards very > naturally. > > It's always simpler with an example. Let's imagine that Alice can reach > three trampoline nodes: T1, T2 and T3. > She also knows the details of many remote trampoline nodes that she cannot > reach: RT1, RT2, RT3 and RT4. > Alice selects T1 and RT2 to use as trampoline hops. She builds a small > onion that describes the following route: > > *Alice -> T1 -> RT2 -> Bob* > > She finds a route to T1 and builds a normal onion to send a payment to T1: > > *Alice -> N1 -> N2 -> T1* > > In the payload for T1, Alice puts the small trampoline onion. > When T1 receives the payment, he is able to peel one layer of the > trampoline onion and discover that he must > forward the payment to RT2. T1 finds a route to RT2 and builds a normal > onion to send a payment to RT2: > > *T1 -> N3 -> RT2* > > In the payload for RT2, T1 puts the peeled small trampoline onion. > When RT2 receives the payment, he is able to peel one layer of the > trampoline onion and discover that he must > forward the payment to Bob. RT2 finds a route to Bob and builds a normal > onion to send a payment: > > *RT2 -> N4 -> N5 -> Bob* > > In the payload for Bob, RT2 puts the peeled small trampoline onion. > When Bob receives the payment, he is able to peel the last layer of the > trampoline onion and discover that he is > the final recipient, and fulfills the payment. > > Alice has successfully sent a payment to Bob deferring route calculation > to some chosen trampoline nodes. > That part was simple and (hopefully) not controversial, but it left out > some important details: > >1. How do trampoline nodes specify their fees and cltv requirements? >2. How does Alice sync the fees and cltv requirements for her remote >trampoline nodes? > > To answer 1., trampoline nodes needs to estimate a fee and cltv that > allows them to route to (almost) any other > trampoline node. This is likely going to increase the fees paid by > end-users, but they can't eat their cake and > have it too: by not syncing the whole network, users are trading fees for > ease of use and payment reliability. > > To answer 2., we can re-use the existing gossip infrastructure to exchange > a new *node_update *message that > contains the trampoline fees and cltv. However Alice doesn't want to > receive every network update because she > doesn't have the bandwidth to support it (damn it again Alice, upgrade > your mobile plan). My suggestion is to > create a filter system (similiar to BIP37) where Alice sends gossip > filters to her peers, and peers only forward to > Alice updates that match these filters. This doesn't have the issues BIP37 > has for Bitcoin because it has a cost > for Alice: she has to open a channel (and thus lock funds) to get a > connection to a peer. Peers can refuse to serve > filters if they are too expensive to compute, but the filters I propose in > the PR are very cheap (a simple xor or a > node distance comparison). > > If you're interested in the technical details, head over to [1]. > I would really like to get feedback from this list on the concept itself, > and especially on the gossip and fee estimation > parts. If you made it that far, I'm sure you have many questions and > suggestions ;). > > Cheers, > Bastien > > [1] https://github.com/lightningnetwork/lightning-rfc/pull/654 > ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation
