Re: [Lightning-dev] Proposal for Stuckless Payment

This is a very good proposal, thanks Hiroki for all those details it helped me learn a lot. If I'm not mistaken, https://eprint.iacr.org/2018/472.pdf has shown that we MUST add another round of communication if we want to avoid the wormhole attacks (and thus decorrelate payments). While I agree

[Lightning-dev] Trampoline Onion Routing proposal

Good morning list, I have been working on formalizing how trampoline onion routing could work and just published a PR here . Comments are welcome as this introduces changes at several layers. Mobile phones are already struggling to keep

Re: [Lightning-dev] Eltoo, anyprevout and chaperone signatures

Thanks for your answers and links, the previous discussions probably happened before I joined this list so I'll go dig into the archive ;) > I think it makes sense for us to consider both variants, one committing > to the script and the other not committing to the script, but I think it > applies

[Lightning-dev] Eltoo, anyprevout and chaperone signatures

Good morning list, I have been digging into Anthony Towns' anyprevout BIP proposal to verify that it has everything we need for Eltoo . The separation between anyprevout and

Re: [Lightning-dev] eltoo implementation in Bitcoin functional test framework

Good morning Richard, This is an interesting initiative, I'm curious to see the results! I know we haven't worked on any Eltoo implementation yet at Acinq and I don't know if others have attempted it. However I have a very open question that may impact your project. I'm starting to look at

Re: [Lightning-dev] Fwd: Trampoline Routing

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 d

Re: [Lightning-dev] Trampoline Routing

'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 real

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

Good morning ZmnSCPxj, Thanks for sharing this analysis, you're touching on a lot of interesting points and giving a lot of good resource pointers. It echoes many ideas we also had to improve eclair's routing algorithm (which currently uses Yen's k-shortest paths with Dijkstra, a few configurable

Re: [Lightning-dev] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

Good morning ZmnSCPxj, The channel that is failing is then the channel *after* the error-reporting > node (assuming bit `NODE` (`0x2000`) is not set in the `failure_code`: if > it is a node-level error we should back off by one node and mark the erring > node as unreliable). > > Indeed, the other

[Lightning-dev] Trampoline Routing

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

Re: [Lightning-dev] Rendez-vous on a Trampoline

19 Lightning with Sphinx routing and AMP. >> >> https://cornwarecjp.github.io/amiko-pay/doc/amiko_draft_2.pdf >> >> (esp. section 2.1.3) >> >> Please forgive the use of the term "Ripple". 2013 was a different time. >> >> >> CJP >> >> &

Re: [Lightning-dev] Rendez-vous on a Trampoline

so give us a > payment-level ACK [1], which may be a key component for payment splitting > (otherwise > you have no idea if _any_ shards have even arrived at the other side). > > > [1]: > https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001524.html >

[Lightning-dev] Pay-to-Open and UX improvements

Good morning list, As everyone who has ever used a Lightning wallet is well aware, the onboarding process could be made smoother. With Phoenix [1], we've been experimenting with pay-to-open [2]. That works well in practice and provides a great UX for newcomers, but it requires temporary trust

Re: [Lightning-dev] Pay-to-Open and UX improvements

Hi ZmnSCPxj, Thanks for your response. * Once the pre-funding is sufficiently confirmed as per Bob security > parameter > This is the part I'm trying to avoid. If we're ok with waiting for confirmation, then it's easy to do indeed (and let's just wait for the funding tx to confirm, I believe we

Re: [Lightning-dev] Pay-to-Open and UX improvements

Thanks a lot David for the suggestion and pointers, that's a really interesting solution. I will dive into that in-depth, it could be very useful for many layer-2 constructions. Thanks ZmnSCPxj as well for the quick feedback and the `OP_CAT` construction, a lot of cool tricks coming up once (if?)

[Lightning-dev] Rendez-vous on a Trampoline

Good morning everyone, Since I'm a one-trick pony, I'd like to talk to you about...guess what? Trampoline! If you watched my talk at LNConf2019, I mentioned at the end that Trampoline enables high AMP very easily. Every Trampoline node in the route may aggregate an incoming multi-part payment

Re: [Lightning-dev] Pay-to-Open and UX improvements

Good morning list, Thanks again for all the good suggestions, this is awesome. David and ZmnSCPxj's proposals got me thinking (and I still need to dive into Antoine's suggestion as well), and I may have found a very interesting construction. It's either great or completely dumb. I hope you can

Re: [Lightning-dev] Pay-to-Open and UX improvements

Thanks Ethan, I agree on that. Let me also share additional feedback I received on #bitcoin-wizards from gmaxwell [1]: * Changing the behavior of OP_CHECKSIG is a no-go because using two stack arguments instead of one increases the witness size * This is better done as a new opcode as you

Re: [Lightning-dev] Pay-to-Open and UX improvements

Good points, these are good optimisations if we propose such a new opcode! I'm still pondering whether this will be useful enough or if finney attacks completely ruin all use-cases... Le jeu. 19 déc. 2019 à 07:24, ZmnSCPxj a écrit : > Good morning t-bast, > > > > - A script-path spend with

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

Damn you're good. Le jeu. 13 févr. 2020 à 11:44, ZmnSCPxj a écrit : > Good morning t-bast, > > > > Propose we take the `z` to use as bolt11 letter, because even the > French > > > don't pronounce it in "rendez-vous"!) > > > > As long as Z-man didn't want to claim this bolt11 letter for himself

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

Thanks for the feedback and discussion. Here are some more comments. This is relevant if we ever want to hide the node id of the last node: Bob > could provide a symmetric > encryption key to all its peers with unpublished channels, which the peer > can XOR with its own true > node id and use the

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

Hi ZmnSCPxj, That is precisely what I am referring to, the lowest bits of the node ID > are embedded in the SCID, which we do not want to openly reveal to Carol. > Got it, I wasn't understanding your point correctly. We totally agree on that. Though if the point is to prevent Carol from

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

or pass on that payment. What do you think? Do you believe `option_scid_assign` can do a better job in such situations? Cheers, Bastien Le mer. 5 févr. 2020 à 02:44, Rusty Russell a écrit : > Bastien TEINTURIER writes: > > Hey again, > > > > Otherwise Mallory ge

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

on, for privacy reasons). The only way I'd see to avoid is would be that Alice needs to share her `decoy_node_id`s with Bob (and the mapping to a `decoy_scid`) which means more state to manage...but maybe I'm just missing a better mitigation? Cheers, Bastien Le mar. 4 févr. 2020 à 15:09, Bastien TEIN

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

to fairly judge that). Thanks for the feedback, I'll keep working on improving the proposal. Bastien Le mar. 4 févr. 2020 à 05:29, Rusty Russell a écrit : > > Rusty Russell writes: > > Bastien TEINTURIER writes: > >> That's of course a solution as well. Even with that though, if Alice

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

Exactly what Matt said. I would also add that libp2p aims to be a kind of swiss-army knife for p2p networking: that's nice for many use-cases, but when security is your main focus, it's not. Look at TLS: most attacks are downgrade attacks because the protocol offers way too many options.

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

4:40, Rusty Russell a écrit : > > Bastien TEINTURIER writes: > >> But Mallory can do the same attack, I think. Just include the P_I from > >> the wrong invoice for Bob. > > > > Good catch, that's true, thanks for keeping me honest there! In that case > >

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

broken. I'm still offering beers and cocktails to anyone who cracks it [1]! Thanks! Bastien [1] https://twitter.com/realtbast/status/1227233654503505925 Le jeu. 13 févr. 2020 à 05:49, Rusty Russell a écrit : > > Bastien TEINTURIER writes: > > Hi Rusty, > > > > Thanks fo

[Lightning-dev] Decoy node_ids and short_channel_ids

Good morning list, I'd like to explore some enhancements for unannounced (sometimes called private) channels. Unannounced channels are really useful for mobile nodes that won't be online often enough to route payments. That does leak information to your channel peer, but that's a topic for

Re: [Lightning-dev] Mitigating Channel Jamming with Stake Certificates

Good morning list, This is an interesting approach to solve this problem, I really like the idea. It definitely deserves digging more into it: the fact that it doesn't add an additional payment makes it largely superior to upfront payment schemes in terms of UX. If we restrict these stake

Re: [Lightning-dev] Minor tweaks to blinded path proposal

Hey Rusty, Good questions. I think we could use additive tweaks, and they are indeed faster so it can be worth doing. We would replace `B(i) = HMAC256("blinded_node_id", ss(i)) * P(i)` by `B(i) = HMAC256("blinded_node_id", ss(i)) * G + P(i)`. Intuitively since the private key of the tweak comes

[Lightning-dev] Trampoline routing improvements and updates

Good morning list, Before we close this amazing year, I wanted to give you an update and reboot excitement around trampoline routing for 2021. Acinq has been running a trampoline node for more than a year to provide simple and reliable payments for tens of thousands of Phoenix [1] users. We've

[Lightning-dev] Asymmetric features

Good morning list, I've been mulling over some limitations of our feature bits mechanism and I'm interested in your ideas and comments. Our feature bits mechanism works well for symmetric features (where both peers play the same role) but not so well for asymmetric features (where there is a

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

ame bit, and they may never really intersect depending on the > nature or how widespread the new feature is. > > It's also likely the case that already implementations, or typically forks > of implementations are already using "undocumented" TLVs or feature bits in > the wil

Re: [Lightning-dev] bLIPs: A proposal for community-driven app layer and protocol extension standardization

Thanks for starting that discussion. In my opinion, what we're really trying to address here are the two following points (at least from the point of view of someone who works on the spec and an implementation): - Implementers get frustrated when they've worked on something that they think is

Re: [Lightning-dev] Turbo channels spec?

er. 30 juin 2021 à 02:09, Rusty Russell a écrit : > Bastien TEINTURIER writes: > > Hi Rusty, > > > > On the eclair side, we instead send `funding_locked` as soon as we > > see the funding tx in the mempool. > > > > But I think your proposal would work as we

Re: [Lightning-dev] Turbo channels spec?

Hi Rusty, On the eclair side, we instead send `funding_locked` as soon as we see the funding tx in the mempool. But I think your proposal would work as well. We may want to defer sending `announcement_signatures` until after the funding tx has been confirmed? What `min_depth` should we use

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

the limit). Bastien Le sam. 24 avr. 2021 à 10:01, Bastien TEINTURIER a écrit : > You're right, I was thinking about trimmed HTLCs (which can re-appear in > the commit tx > if you lower the feerate via update_fee). > > Dust HTLCs will never appear in the commit tx regardless of subse

Re: [Lightning-dev] L2s Onchain Support IRC Workshop

Great idea, I'll join as well. Thanks for setting this in motion. Le ven. 23 avr. 2021 à 17:39, Antoine Riard a écrit : > Hi Jeremy, > > Yes dates are floating for now. After Bitcoin 2021, sounds a good idea. > > Awesome, I'll be really interested to review again an improved version of >

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

Hi Eugene, The reason dust HTLCs count for the 483 HTLC limit is because of `update_fee`. If you don't count them and exceed the 483 HTLC limit, you can't lower the fee anymore because some HTLCs that were previously dust won't be dust anymore and you may end up with more than 483 HTLC outputs in

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

a écrit : > 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 c

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

Hi Matt, 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 keep payments fully non-custodial. This will be combined

Re: [Lightning-dev] Opening balanced channels using PSBT

Hi, This is exactly what the dual funding proposal provides: https://github.com/lightningnetwork/lightning-rfc/pull/851 Cheers, Bastien Le mer. 22 sept. 2021 à 07:29, Ole Henrik Skogstrøm a écrit : > Hi > > I have found a way of opening balanced channels using LND's psbt option > when opening

Re: [Lightning-dev] Stateless invoices with proof-of-payment

Hi Joost, Concept ACK, I had toyed with something similar a while ago, but I hadn't realized that invoice storage was such a DoS vector for merchants/hubs and wasn't sure it would be useful. Do you have an example of what information you would usually put in your `encoded_order_details`? I'd

[Lightning-dev] PTLCs early draft specification

Good morning list, There was a great recent post on the mailing list detailing how we could do PTLCs on lightning with a lot of other goodies [0]. This proposal contained heavy changes to the transaction structure and the update protocol. While it's certainly something we'll want to do in the

Re: [Lightning-dev] PTLCs early draft specification

Le mar. 21 déc. 2021 à 17:04, Anthony Towns a écrit : > On Tue, Dec 21, 2021 at 04:25:41PM +0100, Bastien TEINTURIER wrote: > > The reason we have "toxic waste" with HTLCs is because we commit to the > > payment_hash directly inside the transaction scripts, so we

Re: [Lightning-dev] PTLCs early draft specification

Hi Z, `SIGHASH_NONE | SIGHASH_NOINPUT` (which will take another what, four > years?) or a similar "covenant" opcode, such as `OP_CHECKTEMPLATEVERIFY` without any commitments or an > `OP_CHECKSIGFROMSTACK` on an empty message. > All you really need is a signature for an empty message, really... >

Re: [Lightning-dev] PTLCs early draft specification

Hi AJ, I think the problem t-bast describes comes up here as well when you > collapse the fast-forwards (or, anytime you update the commitment > transaction even if you don't collapse them). Yes, exactly. I think doing a synchronous update of commitments to the channel state, > something like:

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

Hi Jeremy, Right now, lightning anchor outputs use a 330 sats amount. Each commitment transaction has two such outputs, and only one of them is spent to help the transaction get confirmed, so the other stays there and bloats the utxo set. We allow anyone to spend them after a csv of 16 blocks, in

Re: [Lightning-dev] PTLCs early draft specification

0], people jumping on the thread now may find it helpful to better understand this discussion. Thanks, Bastien [0] https://github.com/t-bast/lightning-docs/pull/16 Le mer. 8 déc. 2021 à 11:00, Bastien TEINTURIER a écrit : > Hi AJ, > > I think the problem t-bast describes comes up here as well wh

Re: [Lightning-dev] A blame ascribing protocol towards ensuring time limitation of stuck HTLCs in flight.

Good morning, I agree, this onion message trick could let us work around this kind of cheating attempt. However, it becomes quite a complex protocol, and it's likely that the more we progress towards specifying it, the more subtle issues we will find that will require making it even more complex.

Re: [Lightning-dev] PTLCs early draft specification

Hi Z, Lloyd, Let's ignore the musig nonce exchanges for now. I believe these can be easily included in existing messages: they probably aren't the reason we need more round-trips (at least not the one I'm concerned about for now). Basically, if my memory and understanding are accurate, in the

Re: [Lightning-dev] A blame ascribing protocol towards ensuring time limitation of stuck HTLCs in flight.

Good morning, Thanks for looking into this! I believe there is another limitation that you're not mentioning: it's easy for a malicious node to blame an honest node. I'm afraid this is a serious limitation of the proposal. If we have a payment: A -> B -> C -> D and C is malicious. C can forward

[Lightning-dev] Blinded payments and unblinding attacks

Good morning list, In the last couple of months, @thomash-acinq and I have spent a lot of time working on route blinding for payments [1]. As you may know, route blinding is a prerequisite for onion messages [2] and Bolt 12 offers [3]. Using route blinding to provide anonymity for onion messages

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

Good morning Alex, I’ve been investigating set reconciliation as a means to reduce bandwidth and redundancy of gossip message propagation. > Cool project, glad to see someone working on it! The main difficulty here will indeed be to ensure that the number of differences between sets is bounded.

[Lightning-dev] Remotely control your lightning node from your favorite HSM

Good morning list, I have just opened a PR to the bLIPs repository [1] to document an idea that I started investigating a long time ago and had already discussed with a few people, but never found the time to write it up before. This is a very simple architecture to securely send administrative

Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM

> > Sent with Proton Mail secure email. > > --- Original Message --- > On Tuesday, September 5th, 2023 at 5:26 PM, Bastien TEINTURIER < bast...@acinq.fr> wrote: > > > > Good morning list, > > > > I have just opened a PR to the bLIPs repository [1

Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM

alidate it manually. Also, this is fully configurable: you can choose which RPCs you want to protect that way and which RPCs you want to keep open. Thanks, Bastien Le mer. 6 sept. 2023 à 17:42, William Casarin a écrit : > > On Wed, Sep 06, 2023 at 03:32:50AM +0200, Bastien TEINTURIER w

Re: [Lightning-dev] Remotely control your lightning node from your favorite HSM

ty to how we > can deliver the commands. Functionally they are very similar however. > > Cheers, > Christian > > On Thu, Sep 7, 2023, 15:06 Bastien TEINTURIER wrote: > >> Hi William, >> >> > What is wrong with runes/macaroons for validating and authenticating >

[Lightning-dev] Batch exchange withdrawal to lightning requires covenants

Good morning list, I've been trying to design a protocol to let users withdraw funds from exchanges directly into their lightning wallet in an efficient way (with the smallest on-chain footprint possible). I've come to the conclusion that this is only possible with some form of covenants (e.g.

Re: [Lightning-dev] Batch exchange withdrawal to lightning requires covenants

; > https://github.com/ariard/bitcoin/commit/19d61fa8cf22a5050b51c4005603f43d72f1efcf > > Appreciated expert eyes of folks understanding both lightning and core > mempool on this. > There was a lot of back and forth on nversion=3 design rules, though the > test is normally built on

Re: [Lightning-dev] Removing channel reserve for mobile wallet users

gt; now but still keep the dust reserve. > > Tony Giorgio > > > > > > Original Message > On Oct 18, 2023, 8:51 AM, Bastien TEINTURIER < bast...@acinq.fr> wrote: > > > Good morning list, > > I'd like to discuss the channel reserve requirement, and arg

[Lightning-dev] Removing channel reserve for mobile wallet users

Good morning list, I'd like to discuss the channel reserve requirement, and argue that it should be fine to get rid of it for channels between mobile wallet users and their service provider. I know, I know, your first reaction will be "but this is a security parameter, I don't want to hear about

Re: [Lightning-dev] Removing channel reserve for mobile wallet users

itments, forwarding HTLCs and also > finding routes? > > -kp > > --- Original Message --- > On Wednesday, October 18th, 2023 at 3:51 PM, Bastien TEINTURIER < > bast...@acinq.fr> wrote: > > Good morning list, > > I'd like to discuss the channel reserve re

Re: [Lightning-dev] Batch exchange withdrawal to lightning requires covenants

he exchange does not have an incentive to > double-spend its own withdrawal transactions, or if all the batched funding > outputs are shared with a LSP, malicious collusion is less plausible. > > Best, > Antoine > > Le mer. 18 oct. 2023 à 15:35, Bastien TEINTURIER a > écrit :

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"

gt; and its companion nversion=3 policy, where an attacker package RBF a >> honest package out of the >> > mempool to subsequently double-spend its own high-fee child with a >> transaction unrelated to the >> > channel. As the remaining commitment transaction is pre-signed with a >> m

Re: [Lightning-dev] Removing channel reserve for mobile wallet users

ed the reserve for our users in Bitkit (well, down to the > dust limit because it doesn't work currently without it). > > I think this behaviour could/should be fixed, have you already reported > the issue? > > Cheers, > ziggie > > --- Original Message --- >

Re: [Lightning-dev] [lightning-dev] Batch exchange withdrawal to lightning requires covenants

paying for the common transaction fields only once instead of N times (where N is the size of the batch). For larger batches, in a high-fee future, I believe this could be significant? Thanks, Bastien Le mar. 24 oct. 2023 à 06:41, David A. Harding a écrit : > On 2023-10-17 03:03, Bastien TEINT

Re: [Lightning-dev] Resumable channels using OP_CHECKSIGFROMSTACK

Hi Thomas, > That's a pity. I would have expected you to be interested, given that > Phoenix could benefit from that feature. I don't think this is an attack wallet providers can reasonably attempt. The mobile wallet can check at every connection that the provider isn't trying to cheat, and the

Re: [Lightning-dev] Resumable channels using OP_CHECKSIGFROMSTACK

Hi Thomas, I don't think those fraud proofs are necessary at all. They're also dangerous, because they impose a hard penalty on LSPs for something that should be best effort (and could get desynchronized by connection issues, especially with flaky mobile connections). I agree with Peter Todd

Re: [Lightning-dev] Resumable channels using OP_CHECKSIGFROMSTACK

he non-trivial part is to design the proof that the user could share publicly, without revealing its private data or leaking its backup encryption keys. Thanks, Bastien Le mer. 16 août 2023 à 15:16, Peter Todd a écrit : > On Wed, Aug 16, 2023 at 09:56:21AM +0200, Bastien TEINTURIER wrote: >

Re: [Lightning-dev] Resumable channels using OP_CHECKSIGFROMSTACK

Hi ghost, > Note that the "reputation loss" argument does not hold up that well if > you let Bob connect to arbitrary nodes. That's true, in that case such nodes don't care as much about their reputation and could have an incentive to cheat. But even in that case, the user will detect it easily

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

Hey Matt, Great work on finding this issue, thoroughly testing it against implementations, and on the follow-up you did after reporting this to the various teams. We all agree that having more people spending time poking at the code to find issues is very beneficial for the project. I hope your

[Lightning-dev] Security issue in anchor outputs implementations

Good morning list, I will describe here a vulnerability found in older versions of some lightning implementations of anchor outputs. As most implementations have not yet released support for anchor outputs, they should verify that they are not impacted by this type of vulnerability while they

Re: [Lightning-dev] Proposal: Bundled payments

egwit support also took years. > > [1] http://whentaproot.com/ > > >> >> cheers, >> >> Thomas >> >> >> >> >> >> On 15.06.23 11:01, Bastien TEINTURIER wrote: >> > Hi Thomas, >> > >> > First of all,

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

I completely agree with Matt, these two components are completely independent and too often conflated. Scoring channels and estimating liquidity is something that has been regularly discussed by implementations for the last few years, where every implementation did its own experiments over time.

[Lightning-dev] Onion messages rate-limiting

During the recent Oakland Dev Summit, some lightning engineers got together to discuss DoS protection for onion messages. Rusty proposed a very simple rate-limiting scheme that statistically propagates back to the correct sender, which we describe in details below. You can also read this in gist

Re: [Lightning-dev] Inbound channel routing fees

Hi Joost, As I've already stated every time this has been previously discussed, I believe this doesn't make any sense. The funds that are on the other side of the channel belong to your peer, not you, so they're free to use it however they want. If you're not happy with the way your peer is

Re: [Lightning-dev] Inbound channel routing fees

gt; increases on that incoming channel. My money gets locked up in a channel >> that may or may not be interesting to me. Wouldn't it be fair to be >> compensated for that? >> >> Any thoughts from routing node operators would be welcome too (or links >> to previous th

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

Hey Zman and list, I don't think waxwing's proposal will help us for private gossip. The rate-limiting it provides doesn't seem to be enough in our case. The proposal rate-limits token issuance to once every N blocks where N is the age of the utxo to which we prove ownership of. Once the token is

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

Hey all, Thanks for the comments! Here are a few answers inline to some points that aren't fully addressed yet. @laolu > Another question on my mind is: if this works really well for rate limiting of > onion messages, then why can't we use it for HTLCs as well? Because HTLC DoS is

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

me network can be _both_ a reliable > > micro-payment system _and_ also a reliable arbitrary message transport > > layer. I guess only time will tell... > > > > > The `shared_secret_hash` field contains a BIP 340 tagged hash > > > > Any reason to use the tagg

[Lightning-dev] A pragmatic, unsatisfying work-around for anchor outputs fee-bumping reserve requirements

Good morning list, The lightning network transaction format was updated to leverage CPFP carve-out and allow nodes to set fees at broadcast time, using a feature called anchor outputs [1]. While desirable, this change brought a whole new set of challenges, by requiring nodes to maintain a

Re: [Lightning-dev] Fat Errors

Hi Joost, I need more time to review your proposed change, but I wanted to quickly correct a misunderstanding you had in quoting eclair's code: > Unfortunately it is possible for nodes on the route to hide themselves. > If they return random data as the failure message, the sender won't know >

Re: [Lightning-dev] Watchtower-Free Lightning Channels For Casual Users

Hi John, > My understanding of the current Lightning protocol is that users specify a to_self_delay safety parameter which is typically about 2 weeks and that they pay for routing, but not for their partner's cost-of-capital. Is that correct? > > If it is, then when a dedicated user (DLU)

Re: [Lightning-dev] Watchtower-Free Lightning Channels For Casual Users

Hey John, Thanks for sharing, this is very interesting. There is a good insight here that we can remove the intermediate HTLC-timeout transaction for outgoing payments because we are the origin of that payment (and thus don't need to quickly claim the HTLC on-chain to then relay that failure to

Re: [Lightning-dev] A pragmatic, unsatisfying work-around for anchor outputs fee-bumping reserve requirements

e restrictive solution to > what's already possible: being able to dynamically fee bump commitment > transactions, and aggregate second level spends. > > -- Laolu > > On Thu, Oct 27, 2022 at 6:51 AM Bastien TEINTURIER wrote: >> >> Good morning list, >> &g

Re: [Lightning-dev] Watchtower-Free Lightning Channels For Casual Users

critical in the current environment. However, > if we eventually get to the point where the blockchain is highly-contested > and fees are high, it may no longer be worth paying the fees to put a splice > transaction on-chain unless a large amount of capital is at stake for a long > p

Re: [Lightning-dev] Splice Lock Race Condition Solution

Hi Dustin, I believe this is the scenario I described in [1]? I haven't looked at the `announcement_signatures` case yet, but at least for the `commit_sig` case this should never be an issue. It only means that sometimes, after sending `splice_locked`, you will receive some `commit_sig` messages

[Lightning-dev] Proposed changes to the splicing specification

Good morning list, As some of you may know, we've been hard at work experimenting with splicing [1]. Splicing is a complex feature with a large design space. It was interesting to iterate on two separate implementations (eclair and cln) and discover the pain points, edge cases and things that

Re: [Lightning-dev] Proposal: Bundled payments

Hi Thomas, First of all, I'd like to highlight something that may not be obvious from your email, and is actually pretty important: your proposal requires *senders* to be aware that the payment will lead to a channel creation (or a splice) on the *receiver* end. In particular, it requires all

Re: [Lightning-dev] Computing Blinding Factors in a PTLC and Trampoline World

Hey Zman, I'm a bit confused because you use a different mechanism than the one specified in the latest schnorr multi-hop locks proposal that I know of, which can be found in [1]. If we use the construction from [1], it seems straightforward that using trampoline doesn't have any impact on the

Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs

some worst-case liquidity griefing scenario. A privacy-preserving > credential can be introduced between the payment of the fee and the redeem > of the service to unlink dual-funding initiators (if the maker has enough > volume to constitute a reasonable anonymity set). > > Best, > Antoi

Re: [Lightning-dev] Blinded Paths Doom Scenario

Hey Ben, I'm not sure why it would be dramatically different from today. If I understand your scenario correctly, the recipient would only provide blinded paths that go through "regulated" nodes so that they can witness the payment. Since the recipient agrees on doing that, the recipient could

Re: [Lightning-dev] Blinded Paths Doom Scenario

that a user is much closer to one of > them without realizing. A sender might try to go for 6 hops, but if it > turns out that their first hop is one of the nodes in the blinded route, it > ruins the privacy they were trying to attain. PTLCs could help, but there's > still timing and amou

Re: [Lightning-dev] Blinded Paths Doom Scenario

tacks, unannounced channel assumptions, LSPs, and the strict enforcement of many hops being included in the blinded part of the route. > > Tony > > On 7/27/23 02:20, Bastien TEINTURIER wrote: > > Hey, > > > This breaks down since we have pretty weak anti-correlation mechanisms

Re: [Lightning-dev] Proposal: Bundled payments

Hi Thomas, > I believe pre-payment of the mining fee can be combined with 0-conf; > I am not sure why you picture them as opposed? Even with BOLT-12, I > don't see 0-conf going away. Sorry if that was unclear, that's not at all what I meant. What I meant is that if we *stopped* using 0-conf for

Re: [Lightning-dev] Liquidity griefing for 0-conf dual-funded txs

r us in this case). > > 3) After tx_complete exchange, TryLock() our UTXO inputs and abort if > > already locked. > > 4) Broadcast funding transaction and begin using the 0-conf channel. > > > > I think this at least enables the common use case for 0-conf: LSPs can > >

[Lightning-dev] Liquidity griefing for 0-conf dual-funded txs

Good morning list, One of the challenges created by the introduction of dual funded transactions [1] in lightning is how to protect against liquidity griefing attacks from malicious peers [2]. Let's start by reviewing this liquidity griefing issue. The dual funding protocol starts by exchanging

Re: [Lightning-dev] Liquidity Ads and griefing subtleties

veryone > benefits more from cooperating than from trying to cheat each other. > This is very similar to how the current network works. > > > On Wed, Dec 13, 2023 at 12:59 PM Bastien TEINTURIER > wrote: > > > > Hey Keagan, > > > > Thanks for your feedback! >

  1   2   >