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

2021-10-19 Thread Bastien TEINTURIER
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

2021-09-22 Thread Bastien TEINTURIER
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

2021-09-21 Thread Bastien TEINTURIER
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] Asymmetric features

2021-07-08 Thread Bastien TEINTURIER
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

2021-07-02 Thread Bastien TEINTURIER
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

2021-07-01 Thread Bastien TEINTURIER
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?

2021-06-30 Thread Bastien TEINTURIER
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?

2021-06-29 Thread Bastien TEINTURIER
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

2021-04-26 Thread Bastien TEINTURIER
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] Increase channel-jamming capital requirements by not counting dust HTLCs

2021-04-24 Thread Bastien TEINTURIER
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] Increase channel-jamming capital requirements by not counting dust HTLCs

2021-04-23 Thread Bastien TEINTURIER
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] L2s Onchain Support IRC Workshop

2021-04-23 Thread Bastien TEINTURIER
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 >

[Lightning-dev] Trampoline routing improvements and updates

2020-12-28 Thread Bastien TEINTURIER
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

Re: [Lightning-dev] Lightning Distributed Routing

2020-11-30 Thread Bastien TEINTURIER
Hi Joao, Thanks for the time you spent on this, the paper is clear on the trade-offs (sacrificing some privacy for efficiency). My main negative feedback here is that you seem to assume that nodes will honestly cooperate. It feels to me that nodes can cheat and gossip biased or invalid

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

2020-11-27 Thread Bastien TEINTURIER
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

2020-11-19 Thread Bastien TEINTURIER
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

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

2020-11-02 Thread Bastien TEINTURIER via Lightning-dev
Good morning Joost and Z, So in your proposal, an htlc that is received by a routing node has the > following properties: > * htlc amount > * forward up-front payment (anti-spam) > * backward up-front payment (anti-hold) > * grace period > The routing node forwards this to the next hop with > *

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

2020-10-23 Thread Bastien TEINTURIER via Lightning-dev
Hey Joost and Z, I brought up the question about the amounts because it could be that > amounts high enough to thwart attacks are too high for honest users or > certain uses. I don't think this is a concern for this proposal, unless there's an attack vector I missed. The reason I claim that is

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

2020-10-23 Thread Bastien TEINTURIER via Lightning-dev
Thanks for your answers, My first instinct is that additional complications are worse in general. > However, it looks like simpler solutions are truly not enough, so adding > the complication may very well be necessary. I agree with both these statements ;). I'd love to find a simpler solution,

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

2020-10-22 Thread Bastien TEINTURIER via Lightning-dev
Good morning list, Sorry in advance for the lengthy email, but I think it's worth detailing my hybrid proposal (bidirectional upfront payments), it feels to me like a workable solution that builds on previous proposals. You can safely ignore the details at the end of the email and focus only on

Re: [Lightning-dev] Hold fees: 402 Payment Required for Lightning itself

2020-10-19 Thread Bastien TEINTURIER via Lightning-dev
Good morning list, I've started summarizing proposals, attacks and threat models on github [1]. I'm hoping it will help readers get up-to-speed and avoid falling in the same pitfalls we already fell into with previous proposals. I've kept it very high-level for now; we can add nitty-gritty

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

2020-10-14 Thread Bastien TEINTURIER via Lightning-dev
To be honest the current protocol can be hard to grasp at first (mostly because it's hard to reason about two commit txs being constantly out of sync), but from an implementation's point of view I'm not sure your proposals are simpler. One of the benefits of the current HTLC state machine is that

Re: [Lightning-dev] Making (some) channel limits dynamic

2020-10-14 Thread Bastien TEINTURIER via Lightning-dev
Hey laolu, I think this fits in nicely with the "parameter re-negotiation" portion of > my > loose Dynamic commitments proposal. Yes, maybe it's better to not offer two mechanisms and wait for dynamic commitments to offer that flexibility. Instead, you may > want to only allow them to utilize

Re: [Lightning-dev] Why should funders always pay on-chain fees?

2020-10-14 Thread Bastien TEINTURIER via Lightning-dev
ot;fully loaded" commitment > transaction. > Even with HTLCs, they could only be signed at 1 sat/byte from the funder's > perspective, once again putting the burden on the broadcaster/confirmer to > make up the difference. > > -- Laolu > > > On Mon, Oct 5, 2020 at 6

Re: [Lightning-dev] Making (some) channel limits dynamic

2020-10-12 Thread Bastien TEINTURIER via Lightning-dev
Good morning, For instance, Tor is basically two-layer: there is a lower-level TCP/IP > layer where packets are sent out to specific nodes on the network and this > layer is completely open about where the packet should go, but there is a > higher layer where onion routing between nodes is used.

Re: [Lightning-dev] Making (some) channel limits dynamic

2020-10-09 Thread Bastien TEINTURIER via Lightning-dev
Hey Zman, raising the minimum payment size is another headache > It's true that it may (depending on the algorithm) lower the success rate of MPP-split. But it's already a parameter that node operators can configure at will (at channel creation time), so IMO it's a complexity we have to deal

Re: [Lightning-dev] Why should funders always pay on-chain fees?

2020-10-08 Thread Bastien TEINTURIER via Lightning-dev
t should cost higher for the counterparty > to withhold a HTLC than paying onchain-fees to close the channel. > > Or can you think about another mitigation for the issue raised above ? > > Antoine > > Le lun. 5 oct. 2020 à 09:13, Bastien TEINTURIER via Lightning-dev &l

Re: [Lightning-dev] Making (some) channel limits dynamic

2020-10-08 Thread Bastien TEINTURIER via Lightning-dev
Good morning Antoine and Zman, Thanks for your answers! I was thinking dynamic policy adjustment would be covered by the dynamic > commitment mechanism proposed by Laolu I didn't mention this as I think we still have a long-ish way to go before dynamic commitments are spec-ed, implemented and

Re: [Lightning-dev] Incremental Routing (Was: Making (some) channel limits dynamic)

2020-10-08 Thread Bastien TEINTURIER via Lightning-dev
If I remember correctly, it looks very similar to how I2P establishes tunnels, it may be worth diving in their documentation to fish for ideas. However in their case the goal is to establish a long-lived tunnel, which is why it's ok to have a slow and costly protocol. It feels to me that for

Re: [Lightning-dev] Why should funders always pay on-chain fees?

2020-10-05 Thread Bastien TEINTURIER via Lightning-dev
Hi darosior, This is true, but we haven't solved yet how to estimate a good enough `min_relay_fee` that works for end-to-end tx propagation over the network. We've discussed this during the last two spec meetings, but it's still unclear whether we'll be able to solve this before package-relay

[Lightning-dev] Why should funders always pay on-chain fees?

2020-10-05 Thread Bastien TEINTURIER via Lightning-dev
Good morning list, It seems to me that the "funder pays all the commit tx fees" rule exists solely for simplicity (which was totally reasonable). I haven't been able to find much discussion about this decision on the mailing list nor in the spec commits. At first glance, it's true that at the

[Lightning-dev] Making (some) channel limits dynamic

2020-10-05 Thread Bastien TEINTURIER via Lightning-dev
Good evening list, Recent discussions around channel jamming [1] have highlighted again the need to think twice when configuring your channels parameters. There are currently parameters that are set once at channel creation that would benefit a lot from being configurable throughout the lifetime

Re: [Lightning-dev] Dynamic Commitments: Upgrading Channels Without On-Chain Transactions

2020-07-21 Thread Bastien TEINTURIER via Lightning-dev
Thanks for sharing this, I think it's the right time to start experimenting with that kind of feature (especially in the light of Taproot and the package relay work / pinning transactions issue). we can start to experiment with flow-control like > ideas such as limiting a new channel peer to only

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

2020-06-22 Thread Bastien TEINTURIER via Lightning-dev
Hey ZmnSCPxj, I agree that in theory this looks possible, but doing it in practice with accurate control of what parts of the network get what tx feels impractical to me (but maybe I'm wrong!). It feels to me that an attacker who would be able to do this would break *any* off-chain construction

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

2020-06-22 Thread Bastien TEINTURIER via Lightning-dev
these nodes makes that scenario unlikely (IMHO). Thanks, Bastien Le sam. 20 juin 2020 à 12:37, David A. Harding a écrit : > On Sat, Jun 20, 2020 at 10:54:03AM +0200, Bastien TEINTURIER wrote: > > We're simply missing information, so it looks like the only good > > solution is to

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

2020-06-20 Thread Bastien TEINTURIER via Lightning-dev
Hello Dave and list, Thanks for your quick answers! The attacker would be broadcasting the latest > state, so the honest counterparty would only need to send one blind > child. > Exactly, if the attacker submits an outdated transaction he would be shooting himself in the foot, as we could claim

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

2020-06-19 Thread Bastien TEINTURIER via Lightning-dev
Good morning list, Sorry for being (very) late to the party on that subject, but better late than never. A lot of ideas have been thrown at the problem and are scattered across emails, IRC discussions, and github issues. I've spent some time putting it all together in one gist, hoping that it

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

2020-04-22 Thread Bastien TEINTURIER via Lightning-dev
Hi Antoine and list, Thanks for raising this. There's one step I'd like to understand further: * Mallory can broadcast its Pinning Preimage Tx on offered HTLC #2 output > on Alice's transaction, > feerate is maliciously chosen to get in network mempools but never to > confirm. Absolute fee must

[Lightning-dev] A better encoding for lightning invoices

2020-04-01 Thread Bastien TEINTURIER via Lightning-dev
Good morning list, In Bolt 11 we decided to use bech32 to encode lightning invoices. While bech32 has some nice properties, it isn't well suited for invoices. The main drawback of Bolt 11 invoices is their size: when you start adding routing hints or rendezvous onions, invoices become huge and

Re: [Lightning-dev] Blind paths revisited

2020-03-13 Thread Bastien TEINTURIER via Lightning-dev
Good morning ZmnSCPxj, Ok I see what you mean. In that case it would be slightly different from the current path blinding proposal. The recipient would need to give the sender all the blinding points for each hop in the blinded path. Currently the recipient only gives one blinding point and then

Re: [Lightning-dev] Blind paths revisited

2020-03-11 Thread Bastien TEINTURIER via Lightning-dev
Good morning list, Thanks Rusty for following up on this, I'm glad it may be useful for offers! I certainly want this as well for wallet users' privacy. I have gathered my proposal in a better format than my previous gist here:

Re: [Lightning-dev] Sphinx Rendezvous Update

2020-02-25 Thread Bastien TEINTURIER via Lightning-dev
out at me if I have > forgotten to consider something :-) > > Cheers, > Christian > > [1] > https://github.com/lightningnetwork/lightning-rfc/blob/rendez-vous/proposals/0001-rendez-vous.md > [2] https://gist.github.com/cdecker/ec06452bc470749d9f6d2de73651c5fd > > Basti

[Lightning-dev] Sphinx Rendezvous Update

2020-02-24 Thread Bastien TEINTURIER via Lightning-dev
Good morning list, After exploring decoys [1], which is a cheap way of doing route blinding, I'm turning back to exploring rendezvous. The previous mails on the mailing list mentioned that there was a technicality to make the HMACs check out, but didn't provide a lot of details. The issue is that

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

2020-02-17 Thread Bastien TEINTURIER
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

2020-02-13 Thread Bastien TEINTURIER
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

2020-02-13 Thread Bastien TEINTURIER
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

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

2020-02-11 Thread Bastien TEINTURIER
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

2020-02-05 Thread Bastien TEINTURIER
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

2020-02-04 Thread Bastien TEINTURIER
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

2020-02-04 Thread Bastien TEINTURIER
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] Decoy node_ids and short_channel_ids

2020-02-03 Thread Bastien TEINTURIER
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

2020-02-03 Thread Bastien TEINTURIER
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

[Lightning-dev] Decoy node_ids and short_channel_ids

2020-01-20 Thread Bastien TEINTURIER
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] Pay-to-Open and UX improvements

2019-12-19 Thread Bastien TEINTURIER
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] Pay-to-Open and UX improvements

2019-12-18 Thread Bastien TEINTURIER
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

2019-12-18 Thread Bastien TEINTURIER
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

2019-12-17 Thread Bastien TEINTURIER
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?)

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

2019-12-17 Thread Bastien TEINTURIER
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

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

2019-12-17 Thread Bastien TEINTURIER
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] Rendez-vous on a Trampoline

2019-11-12 Thread Bastien TEINTURIER
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 >

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

2019-11-12 Thread Bastien TEINTURIER
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 >> >> &

[Lightning-dev] Rendez-vous on a Trampoline

2019-10-22 Thread Bastien TEINTURIER
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] eltoo implementation in Bitcoin functional test framework

2019-09-04 Thread Bastien TEINTURIER
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

2019-08-05 Thread Bastien TEINTURIER
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

2019-08-05 Thread Bastien TEINTURIER
'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

[Lightning-dev] Trampoline Routing

2019-08-02 Thread Bastien TEINTURIER
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] Improving Lightning Network Pathfinding Latency by Path Splicing and Other Real-Time Strategy Game Techniques

2019-08-02 Thread Bastien TEINTURIER
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

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

2019-08-01 Thread Bastien TEINTURIER
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] Proposal for Stuckless Payment

2019-06-25 Thread Bastien TEINTURIER
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

2019-05-23 Thread Bastien TEINTURIER
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

2019-05-16 Thread Bastien TEINTURIER
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

2019-05-15 Thread Bastien TEINTURIER
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