Re: [Lightning-dev] Mailing List Future

Ah, there was also some concern over archiving of a discourse, which we'd hoped was trivial through "mailing list mode", but apparently that may not be the case. Further thoughts on that are welcome. Matt On 12/4/23 12:32 PM, Matt Corallo wrote: On the call the vote was split be

Re: [Lightning-dev] Mailing List Future

;ll have another discussion in two weeks about if people are happy with this as a solution/if we should host our own discourse (not sure why)/if we should go back to the mailing list plan. Those who have a view can also respond to this email and I'll raise it in the meeting. Matt On 11/26/2

[Lightning-dev] Mailing List Future

During the last meeting it came up that the mailing list here will likely shut down somewhere around the end of the year. We listed basically the following options for future discussion forums: * google groups as a mailing list hoster. One question was whether its friendly to subscribing withou

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

On 11/20/23 6:53 AM, Andy Schroder wrote: - I would omit suggesting to use DoH from the spec. DoH seems a bit centralized to me and that's up to the client to decide what to do. DNS itself is a hierarchically distributed system, so there is redundancy built into it (which has its flaw at th

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

On 11/17/23 8:28 AM, Andy Schroder wrote: #Comments ## General - I agree that option 3 and 1 should be used. However, you say "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 impleme

Re: [Lightning-dev] Lightning Address in a Bolt 12 world

On 11/17/23 9:54 AM, Tony Giorgio via Lightning-dev wrote: Bastien, Maybe I'm misunderstanding option 1 or perhaps it's not clear. Are you saying with that option, all it takes is a single DNS entry for "serviceprovider.com" to service unlimited users? The interchanging between "bob" and "do

Re: [Lightning-dev] [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On 10/20/23 7:43 PM, Peter Todd wrote: On Fri, Oct 20, 2023 at 09:55:12PM -0400, Matt Corallo wrote: Quite the contrary. Schnorr signatures are 64 bytes, so in situations like lightning where the transaction form is deterministically derived, signing 100 extra transactions requires just 6400

Re: [Lightning-dev] [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On 10/20/23 8:15 PM, Peter Todd wrote: On Fri, Oct 20, 2023 at 05:05:48PM -0400, Matt Corallo wrote: Sadly this only is really viable for pre-anchor channels. With anchor channels the attack can be performed by either side of the closure, as the HTLCs are now, at max, only signed

Re: [Lightning-dev] [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

On 10/20/23 9:25 PM, Peter Todd wrote: On Fri, Oct 20, 2023 at 09:03:49PM -0400, Matt Corallo wrote: What are anchor outputs used for other than increasing fees? Because if we've pre-signed the full fee range, there is simply no need for anchor outputs. Under any circumstance w

Re: [Lightning-dev] [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

Sadly this only is really viable for pre-anchor channels. With anchor channels the attack can be performed by either side of the closure, as the HTLCs are now, at max, only signed SIGHASH_SINGLE|ANYONECANPAY, allowing you to add more inputs and perform this attack even as the broadcaster. I do

Re: [Lightning-dev] [bitcoin-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

12:23 PM, Matt Morehouse wrote: On Wed, Oct 18, 2023 at 12:34 AM Matt Corallo via bitcoin-dev wrote: There appears to be some confusion about this issue and the mitigations. To be clear, the deployed mitigations are not expected to fix this issue, its arguable if they provide anything more t

Re: [Lightning-dev] Full Disclosure: CVE-2023-40231 / CVE-2023-40232 / CVE-2023-40233 / CVE-2023-40234 "All your mempool are belong to us"

# Timeline - 2022-12-16: Report of the finding to Suhas Daftuar, Anthony Towns, Greg Sanders and Gloria Zhao - 2022-12-16: Report to LN maintainers: Rusty Russell, Bastien Teinturier, Matt Corallo and Olaoluwa Osuntunkun - 2022-12-23: Sharing to Eugene Siegel (LND) - 2022-12-24: Sharing to James O&#x

Re: [Lightning-dev] Disclosure: Fake channel DoS vector

On 8/26/23 5:03 AM, Antoine Riard wrote: Hi Matt, > While you were aware of these fixes at the time, I'd appreciate it if you, someone who hasn't spent > much time contributing to LDK over the past two or three years, stop trying to speak on behalf of > the LDK project. While this statem

Re: [Lightning-dev] Disclosure: Fake channel DoS vector

While you were aware of these fixes at the time, I'd appreciate it if you, someone who hasn't spent much time contributing to LDK over the past two or three years, stop trying to speak on behalf of the LDK project. Thanks, Matt On 8/24/23 4:33 PM, Antoine Riard wrote: Hi Matt, Thanks for the

Re: [Lightning-dev] LN Summit 2024 Organization

ll start a summit organization Signal group and throw Matt inside as he's quite experienced about open-source events and has opinions on a lot of things. Best, Antoine Le lun. 21 août 2023 à 01:16, Matt Corallo <mailto:lf-li...@mattcorallo.com>> a écrit : While more lightning d

Re: [Lightning-dev] LN Summit 2024 Organization

While more lightning developers attending conference(s) in a more diverse set of countries, including on the african continent, sounds like a great idea, the usual LN summit is an invite-only developer meeting. Hosting it in a country with additional requirements for travel and which isn't as we

Re: [Lightning-dev] Multipath Keysend

IMO we should revisit this post-PTLCs, but in the mean time, folks should allow for classic keysend to be MPP. IIRC CLN already does, LDK added support for it not too long ago, and it'd be nice if others did too. Just like with normal lightning MPP payments - if the recipient decides to claim le

Re: [Lightning-dev] Proposal: Bundled payments

On 6/20/23 1:45 AM, Thomas Voegtlin wrote: - snip - We have not implemented BOLT-12 yet in Electrum. Would you care to describe whether bundled payments already would work with the current specification, or whether they would require changes to BOLT-12? They will not as-specified, but becau

Re: [Lightning-dev] Proposal: Bundled payments

I think the ship has probably sailed on getting any kind of new interoperable change in to BOLT-11. We already can't get amount-less BOLT-11 invoices broadly supported, rolling out yet another new incompatible version of BOLT-11 and expecting the entire ecosystem to support it doesn't seem all

[Lightning-dev] Today’s Spam

It seems moderation needs to go back on to tamp down spam for a minute. See y’all Monday. Matt ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev

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

Re: [Lightning-dev] Highly Available Lightning Channels

On 2/14/23 11:36 PM, Joost Jager wrote: But how do you decide to set it without a credit relationship? Do I measure my channel and set the bit because the channel is "usually" (at what threshold?) saturating in the inbound direction? What happens if this changes for an hour and I

Re: [Lightning-dev] Highly Available Lightning Channels

On 2/14/23 1:42 PM, Antoine Riard wrote: Hi Joost, > I think movement in this direction is important to guarantee competitiveness with centralised payment systems and their (at least theoretical) ability to > process a payment in the blink of an eye. A lightning wallet trying multiple paths

Re: [Lightning-dev] Highly Available Lightning Channels

On 2/14/23 2:34 AM, Joost Jager wrote: Hi Matt, If nodes start aggressively preferring routes through nodes that reliably route payments (which I believe lnd already does, in effect, to some large extent), they should do so by measurement, not signaling. The signaling is intend

Re: [Lightning-dev] Highly Available Lightning Channels

On 2/13/23 7:05 PM, ZmnSCPxj wrote: Good morning all, First of all let's see what types of reputation system exist (and yes, this is my very informal categorization): - First hand experience - Inferred experience - Hearsay The first two are likely the setup we all are comfortable with: we o

Re: [Lightning-dev] Highly Available Lightning Channels

f now we had to rely on a third party to aggregate and track the reliability, in order to get enough repeat interactions to build a good model of their liquidity, since we're now back in the hearsay world, and the third party can feed us wrong information to maximize their profits. Regards, C

Re: [Lightning-dev] Highly Available Lightning Channels

Hi Joost, I’m not sure I agree that lightning is “capital efficient” (or even close to it), but more generally I don’t see why this needs a signal. If nodes start aggressively preferring routes through nodes that reliably route payments (which I believe lnd already does, in effect, to some larg

Re: [Lightning-dev] Unjamming lightning (new research paper)

On 11/15/22 12:09 PM, Clara Shikhelman wrote: Matt – I don't know that I agree with "... upfront payments kinda kill the lightning UX ...". I think that upfront fees are almost essential, even outside the context of jamming. This also helps with probing, general spam, and other aspects. Furthe

Re: [Lightning-dev] Unjamming lightning (new research paper)

Thanks for committing all the time today. I’m much happier with (binary, not-so-)local reputation than I was in the past, at least as better than other reputation systems.I believe you’ve stated a few times that local reputation by itself is far from sufficient and that’s why we need upfront paymen

Re: [Lightning-dev] Dynamic Commitments Part 2: Taprooty Edition

plexity compared to the adapter approach. - Johan On Thu, Oct 27, 2022 at 4:54 PM Matt Corallo <mailto:lf-li...@mattcorallo.com>> wrote: I’m not sure I understand this - is there much reason to want taproot commitment outputs? I mean they’re cool, and witnesses are a bit

Re: [Lightning-dev] Dynamic Commitments Part 2: Taprooty Edition

I’m not sure I understand this - is there much reason to want taproot commitment outputs? I mean they’re cool, and witnesses are a bit smaller, which is nice I guess, but they’re not providing materially new features, AFAIU. Taproot funding, on the other hand, provides a Bitcoin-wide privacy improv

Re: [Lightning-dev] `htlc_maximum_msat` as a valve for flow control on the Lightning Network

Two questions - a) How much gossip overhead do you expect this type of protocol to generate/is there a useful outcome for this type of update even if you limit gossip updates to once/twice/thrice per day? b) What are the privacy implications of the naive "update on drained channel", and have you

Re: [Lightning-dev] Onion messages rate-limiting

On 7/10/22 4:43 AM, Joost Jager wrote: It can also be considered a bad thing that DoS ability is not based on a number of messages. It means that for the one time cost of channel open/close, the attacker can generate spam forever if they stay right below the rate limit. I don't see why this

Re: [Lightning-dev] Onion messages rate-limiting

On 7/1/22 8:48 PM, Olaoluwa Osuntokun wrote: Hi Val, > Another huge win of backpressure is that it only needs to happen in DoS > situations, meaning it doesn’t have to impact users in the normal case. I agree, I think the same would apply to prepayments as well (0 or 1 msat in calm times).

Re: [Lightning-dev] Onion messages rate-limiting

On 7/1/22 9:09 PM, Olaoluwa Osuntokun wrote: Hi Matt, > Ultimately, paying suffers from the standard PoW-for-spam issue - you > cannot assign a reasonable cost that an attacker cares about without > impacting the system's usability due to said cost. Applying this statement to related a ar

Re: [Lightning-dev] Onion messages rate-limiting

One further note, I don’t think it makes sense to specify exactly what the rate-limiting behavior is here - if a node wants to do something other than the general “keep track of last forwarded message source and rate limit them” logic they should be free to, there’s no reason that needs to be no

Re: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary

> On Jun 28, 2022, at 19:11, Peter Todd wrote: > > Idle question: would it be worthwhile to allow people to opt-in to their > payments happening more slowly for privacy? At the very least it'd be fine if > payments done by automation for rebalancing, etc. happened slowly. Yea, actually, I thin

Re: [Lightning-dev] Onion messages rate-limiting

Thanks Bastien for writing this up! This is a pretty trivial and straightforward way to rate-limit onion messages in a way that allows legitimate users to continue using the system in spite of some bad actors trying (and failing, due to being rate-limited) to DoS the network. I do think any spe

Re: [Lightning-dev] LN Summit 2022 Notes & Summary/Commentary

On 6/28/22 9:05 AM, Christian Decker wrote: It is worth mentioning here that the LN protocol is generally not very latency sensitive, and from my experience can easily handle very slow signers (3-5 seconds delay) without causing too many issues, aside from slower forwards in case we are talkin

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

On 5/26/22 8:59 PM, Alex Myers wrote: Ah, this is an additional proposal on top, and requires a gossip "hard fork", which means your new protocol would only work for taproot channels, and any old/unupgraded channels will have to be propagated via the old mechanism. I'd kinda prefer to be abl

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

On 5/26/22 1:25 PM, Rusty Russell wrote: Matt Corallo writes: I agree there should be *some* rough consensus, but rate-limits are a locally-enforced thing, not a global one. There will always be races and updates you reject that your peers dont, no matter the rate-limit, and while I agree

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

Oops, sorry, I don't really monitor the dev lists but once every few months so this fell off my plate :/ On 4/28/22 6:11 PM, Rusty Russell wrote: Matt Corallo writes: OK, let's step back. Unlike Bitcoin, we can use a single sketch for *all* peers. This is because we *can* enc

Re: [Lightning-dev] #PickhardtPayments implemented in lnd-manageJ

Its probably worth somewhat disentangling the concept of switching to a minimum-cost flow routing algorithm from the concept of "scoring based on channel value and estimated available liquidity". These are two largely-unrelated concepts that are being mashed into one in this description - the f

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

On 4/26/22 11:53 PM, Rusty Russell wrote: Matt Corallo writes: This same problem will occur if *anyone* does ratelimiting, unless *everyone* does. And with minisketch, there's a good reason to do so. None of this seems like a good argument for *not* taking the "send updates

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

On 4/22/22 6:40 PM, Rusty Russell wrote: Matt Corallo writes: Allowing only 1 a day, ended up with 18% of channels hitting the spam limit. We cannot fit that many channel differences inside a set! Perhaps Alex should post his more detailed results, but it's pretty clear that we can&#

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

On 4/21/22 7:20 PM, Rusty Russell wrote: Matt Corallo writes: Sure, if you’re rejecting a large % of channel updates in total you’re gonna end up hitting degenerate cases, but we can consider tuning the sync frequency if that becomes an issue. Let's be clear: it's a problem. All

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

On 4/22/22 9:15 AM, Alex Myers wrote: Hi Matt, Appreciate your responses.  Hope you'll bear with me as I'm a bit new to this. Instead of trying to make sure everyone’s gossip acceptance matches exactly, which as you point it seems like a quagmire, why not (a) do a sync on startup and

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

On 4/21/22 1:31 PM, Alex Myers wrote: Hello Bastien, Thank you for your feedback. I hope you don't mind I let it percolate for a while. Eclair doesn't do any rate-limiting. We wanted to "feel the pain" before adding anything, and to be honest we haven't really felt it yet. I unders

Re: [Lightning-dev] Gossip Propagation, Anti-spam, and Set Reconciliation

Instead of trying to make sure everyone’s gossip acceptance matches exactly, which as you point it seems like a quagmire, why not (a) do a sync on startup and (b) do syncs of the *new* things. This way you aren’t stuck staring at the same channels every time you do a sync. Sure, if you’re reject

Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

On 12/2/21 21:59, Rusty Russell wrote: Matt Corallo writes: In bolt12, we have the additional problem for the tipping case: each invoice contains an amount, so you can't preprint amountless invoices. (This plugs a hole in bolt11 for this case, where you get a receipt but no a

Re: [Lightning-dev] Route reliability<->fee trade-off control parameter

Yep, this is roughly the direction we've gone in LDK - an abstract interface that gives you some information about a channel and you return "I'm willing to pay up to X msats to avoid routing over that channel as specified". It's obviously not perfect in the sense that it won't generate the abso

Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

> On Oct 19, 2021, at 04:51, Bastien TEINTURIER wrote: > > I like this proposal, it's a net improvement compared to hodling HTLCs > at the recipient's LSP. With onion messages, we do have all the tools we > need to build this. I don't think we can do much better than that anyway > if we want to

Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

On 10/13/21 02:58, ZmnSCPxj wrote: Good morning Matt, The Obvious (tm) solution here is PTLCs - just have the sender always add some random nonce * G to the PTLC they're paying and send the recipient a random nonce in the onion. I'd generally suggest we just go ahead and do

Re: [Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

On 10/12/21 22:08, Andrés G. Aragoneses wrote: Hello Matt, can you clarify what you mean with this particular paragraph?: But for some reason those pesky users keep wanting to use lightning for tips, or at least accept payment on their phones without keeping them unlocked with the lig

[Lightning-dev] A Mobile Lightning User Goes to Pay a Mobile Lightning User...

I'm sure most of y'all are familiar with this problem by now - a lightning user on a phone trying to pay another lightning user on a phone requires some amount of coordination to ensure the sender and recipient are, roughly, online at the same time. Invoices provide this somewhat today by requi

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

On 10/12/21 12:57, Olaoluwa Osuntokun wrote: Hi Fabrice, > I believe that was a mistake: a few days ago, Arcane Research published a > fairly detailed report on the state of the Lightning Network: > https://twitter.com/ArcaneResearch/status/1445442967582302213

Re: [Lightning-dev] Removing lnd's source code from the Lightning specs repository

On 10/11/21 05:29, Bryan Bishop wrote: On Mon, Oct 11, 2021 at 12:25 AM Andrés G. Aragoneses mailto:kno...@gmail.com>> wrote: Completely agree with this. How to move this forward? Set up a vote? What would be the reasoning for not moving it? One consideration is broken links, which

Re: [Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

> On Sep 1, 2021, at 00:07, ZmnSCPxj wrote: > > Good morning Matt and all, > >> Please be careful accepting the faulty premise that the proposed algorithm >> is “optimal”. It is optimal under a specific heuristic used to approximate >> what the user wants. In reality, there are a ton of dif

Re: [Lightning-dev] Do we really want users to solve an NP-hard problem when they wish to find a cheap way of paying each other on the Lightning Network?

Please be careful accepting the faulty premise that the proposed algorithm is “optimal”. It is optimal under a specific heuristic used to approximate what the user wants. In reality, there are a ton of different things to balance, from CLTV to feed to estimated failure probability calculated fro

Re: [Lightning-dev] #zerobasefee

On 8/25/21 05:50, Anthony Towns wrote: On Tue, Aug 24, 2021 at 08:50:42PM -0700, Matt Corallo wrote: I feel like we're having two very, very different conversations here. On one hand, you're arguing that the base fee is of marginal use, and that maybe we can figure out how to aver

Re: [Lightning-dev] #zerobasefee

actly useful and end up being more about semantics than the thrust of the argument. Matt On 8/20/21 21:46, Anthony Towns wrote: On Mon, Aug 16, 2021 at 12:48:36AM -0400, Matt Corallo wrote: The base+proportional fees paid only on success roughly match the *value* of forwarding an HTLC, the

Re: [Lightning-dev] #zerobasefee

Dropped a number of replies to which the reply would otherwise be "see above". On 8/16/21 00:00, Anthony Towns wrote: On Sun, Aug 15, 2021 at 10:21:52PM -0400, Matt Corallo wrote: On 8/15/21 22:02, Anthony Towns wrote: In one particular class of applicable routing algorithms you cou

Re: [Lightning-dev] #zerobasefee

On 8/15/21 22:02, Anthony Towns wrote: In one particular class of applicable routing algorithms you could use for lightning routing having a base fee makes the algorithm intractably slow, I don't think of that as the problem, but rather as the base fee having a multiplicative effect as you s

Re: [Lightning-dev] #zerobasefee

Thanks, AJ, for kicking off the thread. I'm frankly still very confused why we're having these conversations now. In one particular class of applicable routing algorithms you could use for lightning routing having a base fee makes the algorithm intractably slow, but: a) to my knowledge, no one

Re: [Lightning-dev] [bitcoin-dev] Removing the Dust Limit

If it weren't for the implications in changing standardness here, I think we should consider increasing the dust limit instead. The size of the UTXO set is a fundamental scalability constraint of the system. In fact, with proposals like assume-utxo/background history sync it is arguably *the* f

Re: [Lightning-dev] Turbo channels spec?

Thanks! On 6/29/21 01:34, Rusty Russell wrote: Hi all! John Carvalo recently pointed out that not every implementation accepts zero-conf channels, but they are useful. Roasbeef also recently noted that they're not spec'd. How do you all do it? Here's a strawman proposal: 1. Assign

Re: [Lightning-dev] Dropping Tor v2 onion services from node_announcement

There isn’t a lot to do at the spec level to deprecate them - nodes should start ignoring the addresses bug nodes always need to know the length/parse v2 Onion addresses forever as well as store and forward them. We could amend the spec to say that nodes shouldn’t produce them but it won’t chang

Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation

On 4/27/21 17:32, Rusty Russell wrote: OK, draft is up: https://github.com/lightningnetwork/lightning-rfc/pull/867 I have to actually implement it now (though the real win comes from making it compulsory, but that's a fair way away). Notably, I added the requirement that update_fee

Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation

On 4/27/21 01:04, Rusty Russell wrote: Matt Corallo writes: On Apr 24, 2021, at 01:56, Rusty Russell wrote: Matt Corallo writes: I promise it’s much less work than it sounds like, and avoids having to debug these things based on logs, which is a huge pain :). Definitely less work than

Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs

I looked into this more closely, and as far as I understand it, the spec already states that you should not count dust HTLCs: Oops! We do the same thing, we will fix that. On 4/26/21 11:03, Eugene Siegel wrote: I would have to think more about the issue where it's not possible to lower the feer

Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation

> On Apr 24, 2021, at 01:56, Rusty Russell wrote: > > Matt Corallo writes: >> Somehow I missed this thread, but I did note in a previous meeting - these >> issues are great fodder for fuzzing. We’ve had a fuzzer which aggressively >> tests for precisely these ty

Re: [Lightning-dev] [RFC] Simplified (but less optimal) HTLC Negotiation

> On Apr 20, 2021, at 17:19, Rusty Russell wrote: > > After consideration, I prefer alternation. It fits better with the > existing implementations, and it is more optimal than reflection for > optimized implementations. > > In particular, you have a rule that says you can send updates and >

Re: [Lightning-dev] Increase channel-jamming capital requirements by not counting dust HTLCs

The update_fee message does not, as far as I recall, change the dust limit for outputs in a channel (though I’ve suggested making such a change). > On Apr 23, 2021, at 12:24, Bastien TEINTURIER wrote: > >  > Hi Eugene, > > The reason dust HTLCs count for the 483 HTLC limit is because of `upda

Re: [Lightning-dev] Proposal for skip channel confirmation.

A few notes. Given gossip messages will be rejected by many nodes if no such on-chain transaction exists, I don't think you can "re-broadcast" gossip messages at that time, instead I believe you simply need to not gossip until the funding transaction has some confirmations. Still, this shouldn'

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

Given transaction relay delays and a network topology that is rather transparent if you look closely enough, I think this is very real and very practical (double-digit % success rate, at least, with some trial and error probably 50+). That said, we all also probably know most of the people who k

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

On 4/23/20 8:46 AM, ZmnSCPxj wrote: >>> - Miners, being economically rational, accept this proposal and include >>> this in a block. >>> >>> The proposal by Matt is then: >>> >>> - The hashlock branch should instead be: >>> - B and C must agree, and show the preimage of some hash H (hashl

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

Great summary, a few notes inline. > On Apr 22, 2020, at 21:50, ZmnSCPxj wrote: > > Good morning lists et al, > > Let me try to summarize things a little: > > * Suppose we have a forwarding payment A->B->C. > * Suppose B does not want to maintain a mempool and is running in > `blocksonly` mo

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

LC value) fee just to get it unstuck, whereas the attacker never would have had to pay said fee. > -- Laolung > > > On Wed, Apr 22, 2020 at 4:20 PM Matt Corallo <mailto:lf-li...@mattcorallo.com>> wrote: > > > >> On Apr 22, 2020, at 16:13, Olaoluwa Osun

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

t but please re-read the intro email. There are a bunch of ways of doing pinning - just opting into RBF isn’t even close to enough. > [1]: https://github.com/bitcoin/bitcoin/pull/18191 > > >> On Wed, Apr 22, 2020 at 9:50 AM Matt Corallo >> wrote: >> A few replies

Re: [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

g I’d want to rely on for my own funds. Matt > On 4/22/20 2:24 PM, David A. Harding wrote: >> On Mon, Apr 20, 2020 at 10:43:14PM -0400, Matt Corallo via Lightning-dev >> wrote: >> A lightning counterparty (C, who received the HTLC from B, who >> received it from A) t

Re: [Lightning-dev] RBF Pinning with Counterparties and Competing Interest

On 4/22/20 12:12 AM, ZmnSCPxj wrote: > Good morning Matt, and list, > > > >> RBF Pinning HTLC Transactions (aka "Oh, wait, I can steal funds, how, >> now?") >> = >> >> You'll note that in the discussion of RBF pinning we were pretty broad, >> and that

Re: [Lightning-dev] [bitcoin-dev] RBF Pinning with Counterparties and Competing Interest

A few replies inline. On 4/22/20 12:13 AM, Olaoluwa Osuntokun wrote: > Hi Matt, > > >> While this is somewhat unintuitive, there are any number of good anti-DoS >> reasons for this, eg: > > None of these really strikes me as "good" reasons for this limitation, which > is at the root of this iss

[Lightning-dev] RBF Pinning with Counterparties and Competing Interest

[Hi bitcoin-dev, in lightning-land we recently discovered some quite frustrating issues which I thought may merit broader discussion] While reviewing the new anchor outputs spec [1] last week, I discovered it introduced a rather nasty ability for a user to use RBF Pinning to steal in-flight HTLC

Re: [Lightning-dev] Anchor Outputs Spec & Implementation Progress

Knee-jerk gut reaction replies inline :) Matt On 3/30/20 3:00 PM, Olaoluwa Osuntokun wrote: -snip- > In response to the first concern: it is indeed the case that these new > commitments are more expensive, but they're only _slightly_ so. The new > default commitment weight is as if there're two

Re: [Lightning-dev] Using libp2p as a communication protocol for Lightning

Because writing connection logic and peer management is really not that complicated compared to HTLC state machines and the rest of lightning. For crypto, lighting does use the noise framework, though the resulting code is so simple (in a good way) that its super easy to just write it yourself i

Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

ction index within block, >>> 16-bit output index), the spam-prevention might end up requiring more data >>> than the spam it stops, so --- >>> (Though if Matt has some ideas here I would be greatly interested --- we do >>> have to change the encodings of short-ch

Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

be greatly interested --- we do > have to change the encodings of short-channel-ids at some point, if only to > support channel factories) > > Regards, > ZmnSCPxj > >> >> On Mon, Jan 27, 2020, 20:12 Matt Corallo wrote: >> >>> Note that ther

Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

handling attacks like hijacking of routes and channel exhaustion ? > > On Mon, Jan 27, 2020, 20:12 Matt Corallo <mailto:lf-li...@mattcorallo.com>> wrote: > > Note that there's no real reason lightning nodes *have* to have > confidence in that - if a node routes

Re: [Lightning-dev] Not revealing the channel capacity during opening of channel in lightning network

Note that there's no real reason lightning nodes *have* to have confidence in that - if a node routes your payment to the next hop, how they do it doesn't really matter. Allowing things like non-lightning "channels" (eg just a contractual agreement to settle up later between two mutually-trusting p

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

ansferred at each iteration? Also does it >> > make sense that you make partial payment per block instead of waiting for >> > the total file to arrive. It might be the case that the zk proof of the >> > total file is correct but then sender might cheat while sending individual

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

have to give a > ZK proof "block x is part of File F". Is it how this should work ? > >> On Mon, Jan 20, 2020 at 11:59 PM Matt Corallo >> wrote: >> Zk proofs are incredibly fast these days for small-ish programs. They’re >> much too slow for a consensus sys

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

dar > wrote: > >  > But isn't it that the use of ZK proof will render the system slow and hence > defy the very purpose of lightning network which intends to make things > scalable as well as faster transaction ? > >> On Mon, Jan 20, 2020 at 11:48 PM Matt Corallo

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

apers around Bitcoin tend to miss nearly all relevant context, sadly). Matt On 1/20/20 6:10 PM, Subhra Mazumdar wrote: > Are you referring to the paper Zero knowledge contingent payment > revisited ? I will look into the construction. Thanks for the > information! :) > > On Mon, Jan

Re: [Lightning-dev] Data Lightning Atomic Swap (DLAS-down, DLAS-up)

On 11/9/19 4:31 AM, Takaya Imai wrote: > [What I do not describe] > * A way to detect that data is correct or not, namely zero knowledge > proof process. Have you come across Zero Knowledge Contingent Payments? Originally it was designed for on-chain applications but it slots neatly into lightning

Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols

Right, I kinda agree here in the sense that there are things that very significantly help mitigate the issue, but a) I'm not aware of any clients implementing it (and the equivalent mitigations in Bitcoin Core are targeted at a different class of issue, and are not sufficient here), and b) its some

Re: [Lightning-dev] Lightning in a Taproot future

Given the timeline for soft forks to activate on Bitcoin, I don't know why we'd be super conservative about using new features of the Bitcoin consensus rules. I think obviously we'd want to rush as fast as we can into adding real cross-hop privacy to lightning payments, given both the number of awk

Re: [Lightning-dev] Time-Dilation Attacks on Offchain Protocols

Nice writeup! In further in-person discussions today, it was noted that the key last-resort fallback Bitcoin Core has to week out peers in case of an Eclipse Attack does not protect from this style of attack. While it is only of limited concern for most Bitcoin Core users, it very much may expose

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

Regarding your list, A. Indeed, unlikely to happen. B. Maybe, but we’re talking a 10x increase so that suddenly you’re paying some extra pennies. In the scale of likelihood, and in the scale of what fees will be anyway, this doesn’t matter. C. You still seem to have missed the point that they nee

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

Regarding the dust relay limit, there may be a little bit of a misunderstanding as to a few important details. The purpose of it (much like the dust output values in the anchor outputs) is to discourage outputs which are not ever economically spendable, not short-term uneconomically spendable. Th

Re: [Lightning-dev] [PATCH] First draft of option_simplfied_commitment

(resend from the right src) >> On Oct 30, 2019, at 06:04, Joost Jager wrote: >> > For the anchor outputs we consider: >> > >> > * Output type: normal P2WKH. At one point, an additional spending path was >> > proposed that was unconditional except for a 10 block csv lock. The >> > intention of th

  1   2   >