Re: [Lightning-dev] Lightning Address in a Bolt 12 world
Bastien, For completeness, would you be willing to demonstrate what it might look like if it were bolt12 in the normal LNURL way? The concern is mostly what you brought up with relying on DNS entries instead of a typical web server. At scale, that would be much more difficult for LNURL service providers to implement for their potentially thousands to millions of users. Something like Oblivious HTTP could be promising to remove the knowledge of IP for some of the larger LNURL service providers. Tony On 11/16/23 7:51 AM, Bastien TEINTURIER wrote: > Good morning list, > > Most of you already know and love lightning addresses [1]. > I wanted to revisit that protocol, to see how we could improve it and > fix its privacy drawbacks, while preserving the nice UX improvements > that it brings. > > I have prepared a gist with three different designs that achieve those > goals [2]. I'm attaching the contents of that gist below. I'd like to > turn it into a bLIP once I collect enough feedback from the community. > > I don't think we should select and implement all three options. They > show that we have a large enough design space, but I think we should > aim for simplicity of implementation and deployment. My personal choice > would be to do options 1 and 3: clients (mobile wallets) would first > make a DNS request corresponding to option 3, and if that fails, they > would fallback to option 1. Domain owners would implement only one of > those two options, depending on their DNS capabilities. > > Curious to hear your thoughts! > > Many thanks to Rusty and Matt who reviewed early drafts of that gist. > > [1] https://lightningaddress.com/ > [2] https://gist.github.com/t-bast/78fd797a7da570d293a8663908d3339b > > # Lightning Address > > [Lightning Address]( > https://lightningaddress.com/ > ) is a very popular protocol that brings UX improvements that users love. > We'd like to provide those UX benefits without its privacy and security > drawbacks. > > ## Issues with the current lightning address protocol > > As described [here]( > https://github.com/andrerfneves/lightning-address/blob/master/README.md > ), the lightning address protocol requires payment senders to make an HTTP > request to the recipient's domain owner. > This has some inconvenient side effects: > > 1. The payment sender reveals their IP address to the recipient's domain > owner, who knows both the sender and the recipient. > 2. The domain owner can swap invoices to steal some of the payment. > 3. It introduces a dependency on DNS servers and the need for an HTTP stack > on the sender side. > > We can do better and fix or mitigate some of these issues, without > compromising on UX. > We need two somewhat distinct mechanisms: > > 1. A way to privately obtain the `node_id` associated with a given domain. > 2. A way to privately contact that domain to obtain the recipient's payment > details. > > ## User story > > Alice wants to pay ` > b...@domain.com > ` without any other prior information. > She doesn't want to reveal: > > * her identity to Bob (payment sender privacy) > * her identity to the manager of ` > domain.com > ` (payment sender privacy) > * the fact that she wants to pay ` > b...@domain.com > ` to her LSP (payment recipient privacy) > > ## Option 1: use DNS records to link domains to nodes > > A first proposal would be to use a DNS record to obtain the `node_id` > associated with a given domain. > > ### Obtain a blinded path to the node associated with a domain > > Domain owners add a DNS `TXT` record for their domain containing a blinded > path to their node. > They may include an empty path if they wish to directly reveal their > `node_id`. > > | hostname | record type | value | TTL | > ||-|-|-| > | _ > lnaddress.domain.com > . | TXT | path: | path expiry | > > Alice can then make a DNS query to obtain that blinded path. > > ```text > Alice DNS > server > | | > | dig TXT _ > lnaddress.domain.com > | > |>| > | _ > lnaddress.domain.com > . IN TXT "path:c3056fb73aa623..." | > |<| > ``` > > :question: What encoding should we use for the blinded path option? Bech32m > with the `lnp` prefix? > > :warning: Alice should query that DNS record using [DoH]( > https://datatracker.ietf.org/doc/html/rfc8484 > ) for privacy. > She should also query multiple DoH servers to protect from malicious ones. > > :warning: Alice should check the AD flag is correctly set (DNSSEC). > > ### Obtain a Bolt 12 offer from the recipient > > Now that Alice has a way to reach the node that owns Bob's domain, she needs > to contact them to
[Lightning-dev] Lightning Address in a Bolt 12 world
Good morning list, Most of you already know and love lightning addresses [1]. I wanted to revisit that protocol, to see how we could improve it and fix its privacy drawbacks, while preserving the nice UX improvements that it brings. I have prepared a gist with three different designs that achieve those goals [2]. I'm attaching the contents of that gist below. I'd like to turn it into a bLIP once I collect enough feedback from the community. I don't think we should select and implement all three options. They show that we have a large enough design space, but I think we should aim for simplicity of implementation and deployment. My personal choice would be to do options 1 and 3: clients (mobile wallets) would first make a DNS request corresponding to option 3, and if that fails, they would fallback to option 1. Domain owners would implement only one of those two options, depending on their DNS capabilities. Curious to hear your thoughts! Many thanks to Rusty and Matt who reviewed early drafts of that gist. [1] https://lightningaddress.com/ [2] https://gist.github.com/t-bast/78fd797a7da570d293a8663908d3339b # Lightning Address [Lightning Address](https://lightningaddress.com/) is a very popular protocol that brings UX improvements that users love. We'd like to provide those UX benefits without its privacy and security drawbacks. ## Issues with the current lightning address protocol As described [here](https://github.com/andrerfneves/lightning-address/blob/master/README.md), the lightning address protocol requires payment senders to make an HTTP request to the recipient's domain owner. This has some inconvenient side effects: 1. The payment sender reveals their IP address to the recipient's domain owner, who knows both the sender and the recipient. 2. The domain owner can swap invoices to steal some of the payment. 3. It introduces a dependency on DNS servers and the need for an HTTP stack on the sender side. We can do better and fix or mitigate some of these issues, without compromising on UX. We need two somewhat distinct mechanisms: 1. A way to privately obtain the `node_id` associated with a given domain. 2. A way to privately contact that domain to obtain the recipient's payment details. ## User story Alice wants to pay `b...@domain.com` without any other prior information. She doesn't want to reveal: * her identity to Bob (payment sender privacy) * her identity to the manager of `domain.com` (payment sender privacy) * the fact that she wants to pay `b...@domain.com` to her LSP (payment recipient privacy) ## Option 1: use DNS records to link domains to nodes A first proposal would be to use a DNS record to obtain the `node_id` associated with a given domain. ### Obtain a blinded path to the node associated with a domain Domain owners add a DNS `TXT` record for their domain containing a blinded path to their node. They may include an empty path if they wish to directly reveal their `node_id`. | hostname | record type | value | TTL | ||-|-|-| | _lnaddress.domain.com. | TXT | path: | path expiry | Alice can then make a DNS query to obtain that blinded path. ```text Alice DNS server | | | dig TXT _lnaddress.domain.com | |>| | _lnaddress.domain.com. IN TXT "path:c3056fb73aa623..." | |<| ``` :question: What encoding should we use for the blinded path option? Bech32m with the `lnp` prefix? :warning: Alice should query that DNS record using [DoH](https://datatracker.ietf.org/doc/html/rfc8484) for privacy. She should also query multiple DoH servers to protect from malicious ones. :warning: Alice should check the AD flag is correctly set (DNSSEC). ### Obtain a Bolt 12 offer from the recipient Now that Alice has a way to reach the node that owns Bob's domain, she needs to contact them to obtain a Bolt 12 offer from Bob. We use an `onion_message` for that, which has the following benefits: * Alice doesn't reveal her identity (IP address or `node_id`) to Bob or Bob's domain * Alice doesn't reveal Bob's identity (IP address or `node_id`) to her LSP * Alice doesn't even need to know the IP address for Bob's domain's lightning node ```text Alice Alice's LSP Bob's LSPBob | | | | | onion_message | | | |>| onion_message | | | | get_offer_from = b...@domain.com |
Re: [Lightning-dev] On solving pinning, replacement cycling and mempool issues for bitcoin second-layers
Hi all, I think any valid consensus-change based solution to the pinning and replacement cycling issues for Bitcoin L2s should respect the following properties / requirements (ideally): - non-interactive with contribution of your off-chain counterparty - minimize level of fee-bumping reserve and number of UTXO locked - block any malicious pinning or replacement cycling as long as you can compete with ongoing fee rates - do not make the security of low-value lightning payments conditional on a probabilistic state of local knowledge of historical mempool - generalize to N > 2 multi-party off-chain construction - minimize the witness size by using efficient bitcoin script semantics - do not give an edge to low-hashrate or coalition of low-hashrate miners to play fees games with Lightning / L2 nodes - be composable with a solution to massive force-closure of time-sensitive off-chain states - not make it worst things like partial or global mempool partitioning [0] I think this is already a lot. I had some intuitive solutions aiming to remove package malleability by using something like the annex and sighash_anyamount semantic, though after musing on Peter Todd's op_expire proposal, I wonder if there is not another family of solutions that can be designed using "moon math" cryptos like short-lived proofs and strictly enforced sequential time windows. I don't have any strong design at all, and in any case given the complexity it would be good to have an end-to-end implementation of any solution, at the very least see it works well for the Lightning case (chatted with Gleb out-of-band he's too busy with Erlay for now to research more on those subjects and on my side bored working more on those issues, sadly I don't know that many bitcoin, lightning and covenant researchers that understand that well those problems). I still think pinning and replacement attacks deserve more real-world mainnet experimentation, under usual ethical guidelines . Inviting everyone in the Bitcoin research community to research more on those pinning, replacement cycling and miners incentives misalignment with second-layers. Please do so, those issues are serious enough if we wish to have a reliable fee market in a post-subsidy world and a sustainable decentralized miner ecosystem in the long-term (well...dumb ordinal transactions might save the day, though open another wormhole of technical issues). Best, Antoine [0] See The Ugly scenario here https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-June/018011.html Le dim. 22 oct. 2023 à 03:27, Antoine Riard a écrit : > Hi, > > I think if Gleb Naumenko and myself allocate our research time on this > issue, we should (hopefully) be able to come with a strong sustainable fix > to the lightning network, both systematically solving pinnings and > replacement cycling attacks (and maybe other mempools issues or things > related like massive force-closure beyond available blockspace can absorb > before pre-signed transactions timelocks expiration as mentioned in the > original paper). > > I have not yet probed Gleb's mind on this, though we both studied those > cross-layer issues together as early as 2019 / 2020, and I think we have > built an intuitive understanding of the problem-space, with both practical > experience of bitcoin core and rust-lightning codebases and landmark > research in this area [0] [1]. If Gleb isn't too busy with Erlay in core, > I'm sure he'll be enthusiastic to contribute research time at his own pace > (and I might probe a bit of Elichai Turkel time to verify the maths of all > sustainable lightning fixes we might propose and the risks models). All > soft commitments and assuming the interest of the bitcoin community. > > One good advantage of long-term sustainable fixes, it should > (optimistically yet to be demonstrated) lower the fee-bumping reserve value > and number of UTXOs lightning users (and maybe bandwidth) have to lock > continuously to use this worldwide 24 / 7 payment system. > > Reopened the issue on coordinated security issues handling in the LN > ecosystem: > https://github.com/lightning/bolts/pull/772 > > While I'll stay focused on solving the above problems at the base-layer > where they're best solved, at least I'll stay around for a few months > making transitions with the younger generation of LN devs. > > For transparency, I don't have any strong solution design yet at all, > neither code, conceptual draft or paper ready, and game-theory and nodes > network processing resources changes will have to be weighted very > carefully, all under the bitcoin open and responsible process we currently > have. Overall, this will take reasonable time (e.g package relay design > discussions have been started in 2018 and we're only now at the hard > implementation and review phase) to carry on forward. > > Looking forward to hearing thoughts of the Bitcoin and Lightning > development protocols community. > > [0] > https://lists.linuxfoundation.org
Re: [Lightning-dev] Scaling Lightning With Simple Covenants
Hi aj, A few more thoughts on this trust/safety vs. capital efficiency tradeoff: > Optimising that formula by making LA [the channel's active lifetime] as large > as possible doesn't > necessarily work -- if a casual user spends all their funds and > disappears prior to the active lifetime running out, then those > funds can't be easily spent by B until the total lifetime runs out, > so depending on how persistent your casual users are, I think that's > another way of ending up with your capital locked up unproductively. The risk of the casual user spending all of their funds can be addressed by having the casual user prepay the cost-of-capital fees for the dedicated user's funds for the entire lifetime of the channel. Then, whenever the dedicated user's funds increase or decrease (due to a send or receive by the casual user), a corresponding prepayment adjustment is included in the new balances defined by the send or receive HTLC. With prepayments, the dedicated user can safely agree to a long active lifetime for the channel. In the paper, I assumed an active lifetime of 110,000 blocks (about 2.1 years), but allowed the casual users to obtain a new channel every 10,000 blocks (about 2.5 months) by staggering their timeout-trees ([1], Sec. 4.8 and 5). The paper includes a rollover period (which covers the casual user's unavailability for up to 2.5 months) in addition to the timeout-tree's active lifetime (25 months) and inactive lifetime (1 week for putting leaves onchain, which definitely introduces risk). Here are some rough calculations if one wants to eliminate risk by making the inactive lifetime long enough to put all leaves of all timeout-trees onchain before the timeout-trees' expiries: TIME BOUND ON NUMBER OF LEAVES: -- There are approximately 52,500 blocks / year, each with at most 4M vbytes, for a total of approximately 210B = 2.1 * 10^11 vbytes per year. If each leaf requires an average (when all leaves in a tree are put onchain) of 2,100 vbytes, then 2.1 * 10^11 / 2,100 = 10^8 = 100M leaves can be put onchain in 1 year with full block capacity devoted to leaves, and in 1/x years with a fraction of x capacity devoted to leaves. Therefore, at x = 0.5 capacity: 50M leaves can be put onchain per year 100M leaves can be put onchain in 2 years 1B leaves can be put onchain in 20 years 10B leaves can be put onchain in 200 years 100B leaves can be put onchain in 2,000 years Assuming an active lifetime of 2.1 years, adding an inactive period of 2 years may be plausible, depending on the cost of capital. Therefore, scaling to 100M or so leaves (across all timeout-trees) while maintaining the ability to put all leaves onchain may be doable. On the other hand, an inactive period of 20 years seems unreasonable. As a result, scaling to billions of leaves probably requires trading off safety vs. capital efficiency (as you noted). FEERATE BOUND ON NUMBER OF LEAVES: - If each leaf requires a maximum (when only that leaf is put onchain) of 10,500 vbytes and the feerate is at least 2 satoshis / vbyte, then each leaf must be worth at least 21,000 satoshis (or else the dedicated user may not have an incentive to be honest, as the casual user would lose funds by putting their leaf onchain). There are at most 2.1 * 10^15 satoshis in existence, so there can be at most 2.1 * 10^15 / 21,000 = 10^11 = 100B leaves. I wrote a small python3 program for analyzing scalability given the requirement that all timeout-tree leaves can be put onchain. The trickiest part was figuring out how to quantify the onchain fees caused by increasing the fraction of each block that's devoted to casual users putting their leaves onchain. I wanted a function that multiplies the base feerate by a factor of 1 when no leaves are put onchain and by a factor approaching infinity when nearly all of the block space is devoted to leaves. I started with the function Fe/(1-x), where Fe is the base feerate (without leaves put onchain) and x is the fraction of block space devoted to putting leaves onchain. This function has the desired behavior when x is near 0 or 1, and it doubles the base feerate when half the block space is devoted to leaves. In reality, the feerate probably increases faster than that, so I added an exponent to capture how quickly the feerate grows: feerate = Fe/(1-x)^Ex where Ex is an arbitrary exponent. The program has the following tunable parameters: * Ac: length (in blocks) of active lifetime of each TT (timeout-tree) * Ro: length (in blocks) of rollover period of each TT (provides for casual user's unavailability) * AS: average size (in vbytes) of transactions required to put one TT leaf onchain when all leaves in TT are put onchain * MS: maximum size (in vbytes) of transactions required to put one TT leaf onchain when only one leaf in TT is put onchain * Fe: feerate (in sats/vbyte) assuming 0% of b
