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

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

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

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

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

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* encode enough

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

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't stay

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. Allowing only

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

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

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

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 amount

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

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

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

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

[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

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,

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

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

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 average it out

Re: [Lightning-dev] #zerobasefee

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, they don't match the costs particularly well at all. Sure

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

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

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

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*

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

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

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

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

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

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

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`

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

eas 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 Osuntokun > <mailto:laol...@gmail.com>&g

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

here 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 inline. >> >> On 4/22/20 12

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

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) today could, if B broadcas

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

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

[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

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

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

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

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-channel

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

eatly 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 there's n

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

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 your paymen

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

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

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)

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 20, 2

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

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

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

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 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.

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

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

> On Oct 30, 2019, at 03:04, Rusty Russell wrote: > > Joost Jager writes: >> * Add `1 OP_CHECKSEQUENCEVERIFY OP_DROP` to the non-revocation clause of >> the HTLC outputs. > >> For the anchor outputs we consider: >> >> * Output type: normal P2WKH. At one point, an additional spending path

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

rty. " to "you always need at least one non-CSV output per party. " > > I realize these limits are there for a reason though, but I'm wondering if > could relax them. Also now that jeremyrubin has expressed problems with the > current mempool limits. > >> On T

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

his, but I’m asking since it seems like > there has been several changes to the acceptance code and eviction > policy since the limit was first introduced. > > - Johan > > > On Wed, Feb 13, 2019 at 6:57 AM Rusty Russell <mailto:ru...@rustcorp.com.au>> wrote: >

Re: [Lightning-dev] Network probes

This seems like a bad idea as it could create timing attacks to discover if a node is the target for a payment. Matt On 1/18/19 9:06 PM, Olaoluwa Osuntokun wrote: Nodes can and eventually should start using bloom filters to avoid most database lookups for incoming payment hashes.

Re: [Lightning-dev] Quick analysis of channel_update data

I mentioned this on IRC, but note that the flapping is not just useless information to be discarded without consideration. An important use of routing data is providing a "good" subset to nodes like mobile clients that don't want all the bandwidth to stay fully in sync. A pretty good indicator

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

can announce a bogus package and leave you unable to add a new transaction to it, the difference being it may be significantly more expensive to do so. If it were the case the you could RBF after the fact, I would likely agree with you. > On Jan 8, 2019, at 00:50, Rusty Russell wrote: >

Re: [Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

pe of that design is. Suhas opened an issue to try to scope it out a bit more at https://github.com/bitcoin/bitcoin/issues/14895 Matt On Dec 3, 2018, at 22:33, Rusty Russell wrote: Matt Corallo writes: As an alternative proposal, at various points there have been discussions around solvin

Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort

should just hold an IRC meeting at the same time on #lightning-dev. Matt On 11/28/18 2:43 PM, Peter Todd wrote: On November 27, 2018 12:13:27 AM UTC, Matt Corallo wrote: +100 for IRC meetings, though, really, I'd much much stronger prefer substantive discussion happen on GitHub

[Lightning-dev] CPFP Carve-Out for Fee-Prediction Issues in Contracting Applications (eg Lightning)

(cross-posted to both lists to make lightning-dev folks aware, please take lightning-dev off CC when responding). As I'm sure everyone is aware, Lightning (and other similar systems) work by exchanging pre-signed transactions for future broadcast. Of course in many cases this requires either

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

For the low low cost of 3 witness bytes, I think the simplification of analysis/separation of concerns is worth it, though I agree it is probably not strictly required. On 11/26/18 3:12 AM, Rusty Russell wrote: Matt Corallo writes: Hmm, are we willing to consider CLTV sufficient? In case

Re: [Lightning-dev] [META] Organization of 1.1 Spec Effort

+100 for IRC meetings, though, really, I'd much much stronger prefer substantive discussion happen on GitHub or the mailing list. Doing finalization in a live meeting is really unfair to those who can't find the time to attend regularly (or happen to miss the one where that thing was discussed

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

Indeed, this change assumes (a) the change in relay policy around CPFP that is discussed on this thread, and (b) some kind of (at least very basic) package relay in Bitcoin Core. (a) requires some discussion, but people seem at least not entirely against it when I've discussed it with people,

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

Not sure if others already realized this, but in thinking about our RBF policy hack from Adelaide a bit more, to allow the carve-out exception of "last tx in a package, which has only one unconfirmed ancestor" to always be available for the "honest party" when broadcasting a commitment

[Lightning-dev] RouteBoost: Adding 'r=' fields to BOLT 11 invoices to flag capacity

Resending due to ML bugs On a related note, it would be nice to get some clarity on appropriate usage of the r= field here. The way I had implemented it initially was that if an invoice had an r= field any publicly-discovered last-hop routes would be ignored as the r= data is most likely more

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

Ok, so limit things to 100 channels... Still don't see why the constants get into unreasonable load here... On January 15, 2018 2:53:07 AM UTC, ZmnSCPxj wrote: >Good morning Matt, > >> I can't imagine the constants add up that fast... Allow 25 channels >per peer and

Re: [Lightning-dev] [1.1] Proposed `funding_cancelled` message

I have to say I'm rather not a fan of this idea. Adding messages which do not result in different node behavior other then waiting for the timeout with little overhead on the node to simply keep watching for the funding transaction is a recipe for ending up with a needlessly complex protocol