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

2021-12-02 Thread Rusty Russell
Matt Corallo writes: > 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 this for every PTLC payment, cause why

Re: [Lightning-dev] Turbo channels spec?

2021-08-11 Thread Rusty Russell
Sorry this took so long. https://github.com/lightningnetwork/lightning-rfc/pull/895 This changed quite a bit, based on discussion here and more coherent thinking. 1. You can simply send funding_locked early, no feature needed. 2. It's a bit useless unless you are the (sole) funder or you trust

Re: [Lightning-dev] Error Codes for LN

2021-07-06 Thread Rusty Russell
Carla Kirk-Cohen writes: > Hi all, Hi Carla, I apologize for not responding to this earlier, but it was raised again in the recent spec meeting (https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-07-05-20.06.log.html). I love the idea of more specific error

Re: [Lightning-dev] Turbo channels spec?

2021-07-06 Thread Rusty Russell
ZmnSCPxj writes: > Mostly nitpick on terminology below, but I think text substantially like the > above should exist in some kind of "rationale" section in the BOLT, so --- > > In light of dual-funding we should avoid "funder" and "fundee" in favor of > "initiator" and "acceptor". Yes, Lisa

Re: [Lightning-dev] Turbo channels spec?

2021-07-04 Thread Rusty Russell
Matt Corallo writes: > 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 th

Re: [Lightning-dev] Turbo channels spec?

2021-06-29 Thread Rusty Russell
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 well. This would be backward compatible, I think. Eclair would send `funding_locked`, which is perfectly

[Lightning-dev] Turbo channels spec?

2021-06-28 Thread Rusty Russell
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 a new feature bit "I accept zeroconf channels". 2.

[Lightning-dev] Upgrade on reestablish.

2021-05-06 Thread Rusty Russell
I wanted this for my simplified update commitment draft, so here it is. Would be nice to upgrade those old channels to static remotekey and anchors (yeah, it's still on my TODO) so we could top the old stuff out of implementations and finally the spec!

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

2021-05-04 Thread Rusty Russell
Matt Corallo writes: > 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

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

2021-05-04 Thread Rusty Russell
Matt Corallo writes: > 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

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-04-27 Thread Rusty Russell
Lloyd Fournier writes: > Hey Rusty, > > Thoughts on each point below. > > On Fri, 23 Apr 2021 at 14:29, Rusty Russell wrote: > >> OK, I'm now leaning *against* this method. >> >> 1. It removes the ability to update a channel without access to the node's >&

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

2021-04-27 Thread Rusty Russell
there's no debate on the state of the channel when this is being applied. Cheers, Rusty. Rusty Russell writes: > Matt Corallo writes: >>> On Apr 24, 2021, at 01:56, Rusty Russell wrote: >>> >>> Matt Corallo writes: >>>> Somehow I missed this th

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

2021-04-26 Thread Rusty Russell
Matt Corallo writes: >> 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 a

Re: [Lightning-dev] Making unannounced channels harder to probe

2021-04-23 Thread Rusty Russell
Joost Jager writes: >> >> But Joost pointed out that you need to know the node_id of the next node >> though: this isn't quite true, since if the node_id is wrong the spec >> says you should send an `update_fail_malformed_htlc` with failure code >> invalid_onion_hmac, which node N turns into its

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

2021-04-23 Thread Rusty Russell
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 types of message-non-delivery-and-resending > production desync bugs for several years.

[Lightning-dev] Making unannounced channels harder to probe

2021-04-23 Thread Rusty Russell
Hi all, You can currently probe for a channel id attached to node N by sending an HTLC, and seeing whether the error reply comes from the N or the next hop. The real answer is to get back to blinded paths, BTW. But Joost pointed out that you need to know the node_id of the next node

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-04-22 Thread Rusty Russell
n, because it was so clever! Thoughts? Rusty. Rusty Russell writes: > Lloyd Fournier writes: >> Hi Rusty, >> >> On Tue, 20 Apr 2021 at 10:55, Rusty Russell wrote: >> >>> Lloyd Fournier writes: >>> > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell

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

2021-04-20 Thread Rusty Russell
Christian Decker writes: > Rusty Russell writes: >>> This is in stark contrast to the leader-based approach, where both >>> parties can just keep queuing updates without silent times to >>> transferring the token from one end to the other. >> >> Yo

[Lightning-dev] Splicing draft

2021-04-20 Thread Rusty Russell
https://github.com/lightningnetwork/lightning-rfc/pull/863 I haven't even *started* to implement this, so I could well have missed something. Let's see. Cheers! Rusty. ___ Lightning-dev mailing list Lightning-dev@lists.linuxfoundation.org

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-04-19 Thread Rusty Russell
Lloyd Fournier writes: > Hi Rusty, > > On Tue, 20 Apr 2021 at 10:55, Rusty Russell wrote: > >> Lloyd Fournier writes: >> > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell >> wrote: >> > >> >> >> >> Say r1=SHA256(ss || cou

Re: [Lightning-dev] Recovery of Lightning channels without backups

2021-04-19 Thread Rusty Russell
Lloyd Fournier writes: > On Wed, Dec 9, 2020 at 4:26 PM Rusty Russell wrote: > >> >> Say r1=SHA256(ss || counter || 0), r2 = SHA256(ss || counter || 1)? >> >> Nice work. This would be a definite recovery win. We should add this >> to the DF spec, because

[Lightning-dev] Replacement of invoices to handle stuck payments.

2021-04-16 Thread Rusty Russell
Hi all, https://github.com/lightningnetwork/lightning-rfc/pull/798/commits/fc8aab72ccdd616301dc200fc124824efe4fbb58 I've just added a simple addition to the proposed BOLT 12 offers spec, where invoice requests can ask to obsolete old invoices. This allows a simple workaround in the

[Lightning-dev] c-lightning release v0.10.0: Neutralizing Fee Therapy

2021-03-31 Thread Rusty Russell
We're pleased to announce the 0.10.0 release of c-lightning, named by @jsarenik. https://github.com/ElementsProject/lightning/releases/tag/v0.10.0 This is a major release, consolidating a number of features, fixes and experimental extensions. Highlights for Users * pay has been refined

Re: [Lightning-dev] PoDLEs revisited

2021-01-28 Thread Rusty Russell
Lloyd Fournier writes: > I think immediate broadcast of signaling TX is a bad idea even if it's done > over lightning since it leaks that the UTXO associated with the signaling > TX is creating a channel (even if the channel was meant to be private). > You could argue that the signaling TX need

Re: [Lightning-dev] PoDLEs revisited

2021-01-19 Thread Rusty Russell
Lloyd Fournier writes: > I think PoDLE might actually have an advantage in parallel attacks if the > scheme was changed a bit. A weakness of the lightning proposal as compared > to the joinmarket idea is that the `h2` point is not broadcast immediately > -- rather you wait for failure and then

Re: [Lightning-dev] PoDLEs revisited

2021-01-12 Thread Rusty Russell
Lloyd Fournier writes: > Rusty, Zman, > > A concern I have with only doing one signaling transaction out of the whole > group of inputs is that it means you don't prove ownership of the other > inputs. But that's by design. You can contact two peers and middleman between them to produce a

Re: [Lightning-dev] PoDLEs revisited

2021-01-07 Thread Rusty Russell
Lloyd Fournier writes: > This achieves all properties except for (4 - distinguishable on-chain) > which is why it was dismissed. It also seems to require 2 txs per channel open? (Interestingly I missed that post previously, thanks for the pointer!) > I think it is possible to extend the idea

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

2020-11-21 Thread Rusty Russell
Bastien TEINTURIER writes: > 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)`. >

[Lightning-dev] Minor tweaks to blinded path proposal

2020-11-17 Thread Rusty Russell
See: https://github.com/lightningnetwork/lightning-rfc/blob/route-blinding/proposals/route-blinding.md 1. Can we use additive tweaks instead of multiplicative? They're slightly faster, and supported by the x-only secp API. 2. Can we use x-only pubkeys? It's generally trivial, and a

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

2020-10-20 Thread Rusty Russell
Christian Decker writes: >> And you don't get the benefit of the turn-taking approach, which is that >> you can have a known state for fee changes. Even if you change it to >> have opener always the leader, it still has to handle the case where >> incoming changes are not allowed under the new

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

2020-10-14 Thread Rusty Russell
Joost Jager writes: >> >> > A crucial thing is that these hold fees don't need to be symmetric. A new >> > node for example that opens a channel to a well-known, established >> routing >> > node will be forced to pay a hold fee, but won't see any traffic coming >> in >> > anymore if it announces

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

2020-10-14 Thread Rusty Russell
Christian Decker writes: > I wonder if we should just go the tried-and-tested leader-based > mechanism: > > 1. The node with the lexicographically lower node_id is determined to > be the leader. > 2. The leader receives proposals for changes from itself and the peer > and orders them

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

2020-10-14 Thread Rusty Russell
Bastien TEINTURIER writes: > It's a bit tricky to get it right at first, but once you get it right you > don't need to touch that > code again and everything runs smoothly. We're pretty close to that state, > so why would we want to > start from scratch? Or am I missing something? Well, if

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

2020-10-12 Thread Rusty Russell
Joost Jager writes: > This hold fee could be: lock_time * (fee_base + fee_rate * htlc_value). > fee_base is in there to compensate for the usage of an htlc slot, which is > a scarce resource too. ... > > In both cases the sender needs to trust its peer to not steal the payment > and/or

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

2020-10-12 Thread Rusty Russell
Hi all, Our HTLC state machine is optimal, but complex[1]; the Lightning Labs team recently did some excellent work finding another place the spec is insufficient[2]. Also, the suggestion for more dynamic changes makes it more difficult, usually requiring forced quiescence. The

[Lightning-dev] c-lightning release v0.9.1: The Antiguan BTC Maximalist Society

2020-09-15 Thread Rusty Russell
We're pleased to announce the 0.9.1 release of c-lightning, named by Jon Griffiths. https://github.com/ElementsProject/lightning/releases/tag/v0.9.1 This is a significant release with major bugfixes to multi-part payments and various notable speedups and improvements across the board.

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

2020-08-22 Thread Rusty Russell
Olaoluwa Osuntokun writes: > After getting some feedback from the Lightning Labs squad, we're thinking > that it may be better to make the initial switch over double-opt-in, similar > to the current `shutdown` message flow. So with this variant, we'd add two > new messages: `commit_switch` and

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

2020-04-28 Thread Rusty Russell
"David A. Harding via bitcoin-dev" writes: > To avoid the excessive wasting of bandwidth. Bitcoin Core's defaults > require each replacement pay a feerate of 10 nBTC/vbyte over an existing > transaction or package, and the defaults also allow transactions or > packages up to 100,000 vbytes in

Re: [Lightning-dev] Proof-of-closure as griefing attack mitigation

2020-04-05 Thread Rusty Russell
Hi ZmnSCPxj, This is a rework of the old unwrap-the-onion proposal, with some important bits missing. > Secondly, C needs to prove that the channel it is willing to close involves > the payment attempt, and is not some other channel closure that it is > attempting to use to fulfill its

Re: [Lightning-dev] Blind paths revisited

2020-03-10 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, et al., > > >> Note that this means no payment secret is necessary, since the incoming >> `blinding` serves the same purpose. If we wanted to, we could (ab)use >> payment_secret as the first 32-bytes to put in Carol's enc1 (i.e. it's >> the ECDH for Carol to

[Lightning-dev] Blind paths revisited

2020-03-09 Thread Rusty Russell
I recently hit a dead-end on rendezvous routing; the single-use requirement is a showstopper for offers (which are supposed to be static and reusable). Fortunately, t-bast has a scheme for blinded paths (see https://gist.github.com/t-bast/9972bfe9523bb18395bdedb8dc691faf ) so I've been examining

Re: [Lightning-dev] A proposal for up-front payments.

2020-02-29 Thread Rusty Russell
Anthony Towns writes: > Aside from those philosophical complaints, seems to me the simplest > attack would be: > > * route 1000s of HTLCs from your node A1 to your node A2 via different, > long paths, using up the total channel capacity of your A1/A2 nodes, > with long timeouts > *

Re: [Lightning-dev] Direct Message draft

2020-02-23 Thread Rusty Russell
Christian Decker writes: > Rusty Russell writes: > >> I like it! The lack of "reply" function eliminates all storage >> requirements for the intermediaries. Unfortunately it's not currently >> possible to fit the reply onion inside the existing onion, bu

Re: [Lightning-dev] A proposal for up-front payments.

2020-02-23 Thread Rusty Russell
Anthony Towns writes: > On Fri, Feb 21, 2020 at 12:35:20PM +1030, Rusty Russell wrote: >> And if there is a grace period, I can just gum up the network with lots >> of slow-but-not-slow-enough HTLCs. > > Well, it reduces the "gum up the network for blocks" to &qu

Re: [Lightning-dev] A proposal for up-front payments.

2020-02-20 Thread Rusty Russell
Anthony Towns writes: > On Tue, Feb 18, 2020 at 10:23:29AM +0100, Joost Jager wrote: >> A different way of mitigating this is to reverse the direction in which the >> bond is paid. So instead of paying to offer an htlc, nodes need to pay to >> receive an htlc. This sounds counterintuitive, but

Re: [Lightning-dev] Direct Message draft

2020-02-20 Thread Rusty Russell
René Pickhardt writes: > Hey Rusty, > > I was very delighted to read your proposal. But I don't see how you prevent > message spam. If I understand you correctly you suggest that I can > communicate to any node along a path of peer connections (not necessarily > backed by payment channels but

Re: [Lightning-dev] Direct Message draft

2020-02-20 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > > A concern I have brought up in the past is that if this is more than just a > single request-response, i.e. if this is a conversation where Alice sends to > Bob, Bob sends back to Alice, Alice sends back to Bob, and so on, then if the > same path is

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-20 Thread Rusty Russell
lisa neigut writes: >> With PoDLE this would not be possible I think, as you would not be able > to open the PoDLE commitment with the other node as the target (if we go > with the modified PoDLE which also commits to which node an opening is for, > to prevent the pouncing venus flytrap attack).

[Lightning-dev] Direct Message draft

2020-02-20 Thread Rusty Russell
Hi all! It seems that messaging over lightning is A Thing, and I want to use it for the offers protocol anyway. So I've come up with the simplest proposal I can, and even implemented it. Importantly, it's unreliable. Our implementation doesn't remember across restarts, limits

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

2020-02-20 Thread Rusty Russell
Bastien TEINTURIER writes: > 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

[Lightning-dev] [RELEASE] c-lightning 0.8.1: "Channel to the Moon"

2020-02-17 Thread Rusty Russell
We're pleased to announce 0.8.1, named by @vasild (who last release was a new committer!) https://github.com/ElementsProject/lightning/releases/tag/v0.8.1 *Highlights for Users* - We now support gifting msat to the peer when opening a channel, via push_msat, providing a brand new way

Re: [Lightning-dev] DRAFT: interactive tx construction protocol

2020-02-12 Thread Rusty Russell
ZmnSCPxj via Lightning-dev writes: > Good morning niftynei, > > >> Rusty had some suggestions about how to improve the protocol messages for >> this, namely adding a serial_id to the inputs and outputs, which can then be >> reused for deletions.  >> >> The serial id can then also be used as the

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

2020-02-12 Thread Rusty Russell
Bastien TEINTURIER writes: > Hi Rusty, > > Thanks for the answer, and good luck with c-lightning 0.8.1-rc1 ;) ... Now -rc2. I actually had a RL use for lightning (OMG!), and sure enough found a bug. > I've been thinking more about improving my scheme to not require any sender > change, but I

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

2020-02-09 Thread Rusty Russell
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 > my proposal > would need the same mitigation as yours, Bob will need to include the >

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

2020-02-04 Thread Rusty Russell
Bastien TEINTURIER writes: > Hey again, > > Otherwise Mallory gets two invoices, and wants to know if they're >> actually the same node. Inv1 has nodeid N1, routehint Bob->C1, Inv2 has >> nodeid N2, routehint Bob->C2. > > I think this attack is interesting. AFAICT my proposal defends against

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

2020-02-03 Thread Rusty Russell
Rusty Russell writes: > Bastien TEINTURIER writes: >> That's of course a solution as well. Even with that though, if Alice opens >> multiple channels to each of her Bobs, >> she should use Tor and a different node_id each time for better privacy. > > There are two

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

2020-02-03 Thread Rusty Russell
Bastien TEINTURIER writes: > That's of course a solution as well. Even with that though, if Alice opens > multiple channels to each of her Bobs, > she should use Tor and a different node_id each time for better privacy. There are two uses for this feature (both of which I started implementing):

Re: [Lightning-dev] Decoy node_ids and short_channel_ids

2020-02-02 Thread Rusty Russell
Bastien TEINTURIER writes: > We can easily get rid of (1.) by leveraging the `payment_secret`. The > improved scheme is: > > * Alice draws a random `decoy_key` > * Alice computes the corresponding `decoy_node_id = decoy_key * G` > * Alice draws a random `payment_secret` > * Alice computes

Re: [Lightning-dev] eltoo towers and implications for settlement key derivation

2019-12-02 Thread Rusty Russell
ZmnSCPxj writes: > Good morning Rusty, > >> > Hi all, >> > I recently revisited the eltoo paper and noticed some things related >> > watchtowers that might affect channel construction. >> > Due to NOINPUT, any update transaction can spend from any other, so >> > in theory the tower only needs the

Re: [Lightning-dev] eltoo towers and implications for settlement key derivation

2019-12-02 Thread Rusty Russell
Conner Fromknecht writes: > Hi all, > > I recently revisited the eltoo paper and noticed some things related > watchtowers that might affect channel construction. > > Due to NOINPUT, any update transaction _can_ spend from any other, so > in theory the tower only needs the most recent update txn

Re: [Lightning-dev] [DRAFT] BOLT 13(?): WatchTower protocol

2019-12-02 Thread Rusty Russell
Hi Sergi! Great to see progress on this! Detailed comments below. Sergi Delgado Segura writes: > ## Sending and receiving appointments > > Once the client is aware of the services provided by the server, the former > can start sending appointments to the latter. > > +---+

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-22 Thread Rusty Russell
m by forcing the sender to use some resources (instead of sats). > Maybe this idea has already been proposed and broken, if that's the case > I'd love to see the > discussion if someone can surface it. > > > Cheers, > Bastien > > Le lun. 11 nov. 2019 à 00:32, Rusty Russell a &g

Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-13 Thread Rusty Russell
Yaacov Akiba Slama writes: > So we can integrate between them without intermixing the semantics of > the protocols but we need only to define the interaction points between > them. > > In the previous worflow, the seller can for instance add in the LN > invoice H(Quotation

Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-12 Thread Rusty Russell
Yaacov Akiba Slama writes: >   Seller: Quotation (UBL) > >   Buyer: Order (UBL) > >   Seller: Prepayment Invoice (UBL) > >   Seller: Invoice (LN) > >   Buyer/Seller: Payment & Ack (LN) > >   Buyer: Receipt (UBL) > > > The advantage of such workflow are that we don't need to add any fields > to

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

2019-11-11 Thread Rusty Russell
Joost Jager writes: >> >> > We could >> > simplify this to a single to_self_delay that is proposed by the >> initiator, >> > but what was the original reason to allow distinct values? >> >> Because I didn't fight hard enough for simplicity :( >> > > But the people you were fighting with, what

Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-10 Thread Rusty Russell
Yaacov Akiba Slama writes: > Hi Rusty. > > On 08/11/2019 05:09, Rusty Russell wrote: >> Hi Yaacov, >> I've been pondering this since reading your comment on the PR! >> >> As a fan of standards, I am attracted to UBL (I've chaired an >> OASI

Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-10 Thread Rusty Russell
Ross Dyson writes: > Hi Rusty, > > We spoke in detail about this after your presentation at LNconf. I'm one of > the contributors to LNURL so I am a little familiar with what you're trying > to achieve and am very grateful you're considering implementing something > similar to the mainnet

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-10 Thread Rusty Russell
Anthony Towns writes: > On Fri, Nov 08, 2019 at 01:08:04PM +1030, Rusty Russell wrote: >> Anthony Towns writes: >> [ Snip summary, which is correct ] > > Huzzah! > > This correlates all the hops in a payment when the route reaches its end > (due to the final pr

Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-07 Thread Rusty Russell
and what should be in a general UBL field is a question we have to think on further. Anyway, you'll have to bear with me as I read this 172 page standard... Cheers, Rusty. > What do you think? > PS: Sorry for crossposting here and in > https://github.com/lightningnetwork/l

Re: [Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-07 Thread Rusty Russell
ZmnSCPxj writes: > First, please confirm my understanding of the message flow. > Suppose I have a donation offer on my website and Rusty wants to donate to me. > Then: > > ZmnSCPxj Rusty > || > +-- `lno`

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-07 Thread Rusty Russell
Anthony Towns writes: > On Thu, Nov 07, 2019 at 02:56:51PM +1030, Rusty Russell wrote: >> > What you wrote to Zmn says "Rusty decrypts the onion, reads the prepay >> > field: it says 14, ." but Alice doesn't know anything other than >> > so can't

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-07 Thread Rusty Russell
Joost Jager writes: >> >> > Isn't spam something that can also be addressed by using rate limits for >> > failures? If all relevant nodes on the network employ rate limits, they >> can >> > isolate the spammer and diminish their disruptive abilities. >> >> Sure, once the spammer has jammed up the

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-06 Thread Rusty Russell
Anthony Towns writes: > On Wed, Nov 06, 2019 at 10:43:23AM +1030, Rusty Russell wrote: >> >> Rusty prepares a nonce, A and hashes it 25 times = Z. >> >> ZmnSCPxj prepares the onion, but adds extra fields (see below). >> > It would have made more sen

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-06 Thread Rusty Russell
Joost Jager writes: > In my opinion, the prepayment should be a last resort. It does take away > some of the attractiveness of the Lightning Network. Especially if you need > to make many payment attempts over long routes, the tiny prepays do add up. > For a $10 payment, it's probably nothing to

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-05 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi Rusty, > > Agreed w.r.t the need for prepaid HTLCS, I've been mulling over other > alternatives for a few years now, and none of them seems to resolve the > series of routing related incentive issues that prepaid HTLCs would. > >> Since both Offers and Joost's

Re: [Lightning-dev] A proposal for up-front payments.

2019-11-05 Thread Rusty Russell
Anthony Towns writes: > On Tue, Nov 05, 2019 at 07:56:45PM +1030, Rusty Russell wrote: >> Sure: for simplicity I'm sending a 0-value HTLC. >> ZmnSCPxj has balance 1msat in channel with Rusty, who has 1000msat >> in the channel with YAIjbOJa. > > Alice, Bob and Carol

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

2019-11-05 Thread Rusty Russell
Joost Jager writes: >> >> > * Add `to_remote_delay OP_CHECKSEQUENCEVERIFY OP_DROP` to the `to_remote` >> > output. `to_remote_delay` is the csv delay that the remote party accepted >> > in the funding flow for their outputs. This not only ensures that the >> > carve-out works as intended, but

[Lightning-dev] BOLT 11: add optional vendor field.

2019-11-04 Thread Rusty Russell
It was pointed out to me[1] at thelightningconference.com that it's often a legal requirement to list the vendor on a receipt. It also makes perfect sense. It can be done in the description field, but that's really supposed to be a description of the *items*. Dividing it also lets wallets have

[Lightning-dev] [VERY ROUGH DRAFT] BOLT 12: Offers

2019-11-04 Thread Rusty Russell
Hi all, This took longer than I'd indicated; for that I'm sorry. However, this should give us all something to chew on. I've started with a draft "BOLT 12" (it might be BOLT 13 by the time it's finalized though!). I've also appended indications where we touch other BOLTs: 1. BOLT 7

[Lightning-dev] A proposal for up-front payments.

2019-11-04 Thread Rusty Russell
Hi all, It's been widely known that we're going to have to have up-front payments for msgs eventually, to avoid Type 2 spam (I think of Type 1 link-local, Type 2 though multiple nodes, and Type 3 liquidity-using spam). Since both Offers and Joost's WhatSat are looking at sending

Re: [Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

2019-11-03 Thread Rusty Russell
Rusty Russell writes: > Olaoluwa Osuntokun writes: >> Defaults don't necessarily indicate higher/lower reliability. Issuing a >> single CLI command to raise/lower the fees on one's node doesn't magically >> make the owner of said node a _better_ routing node operator. >

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

2019-11-01 Thread Rusty Russell
Matt Corallo writes: > Why not stick with the original design from Adelaide with a spending path > with a 1CSV that is anyone can spend (or that is revealed by spending another > output). The original design IIRC was a single anyone-can-spend anchor output. If we need two anchor outputs, and

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

2019-10-30 Thread Rusty Russell
Joost Jager writes: > We started to look at the `push_me` outputs again. Will refer to them as > `anchor` outputs from now on, to prevent confusion with `push_msat` on the > `open_channel` message. > > The cpfp carve-out https://github.com/bitcoin/bitcoin/pull/15681 has been > merged and for

Re: [Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

2019-10-13 Thread Rusty Russell
Olaoluwa Osuntokun writes: > Hi Rusty, > > I think this change may be a bit misguided, and we should be careful about > making sweeping changes to default values like this such as fees. I'm > worried that this post (and the subsequent LGTMs by some developers) > promotes the notion that somehow

[Lightning-dev] Increasing fee defaults to 5000+500 for a healthier network?

2019-10-10 Thread Rusty Russell
Hi all, I've been looking at the current lightning network fees, and it shows that 2/3 are sitting on the default (1000 msat + 1 ppm). This has two problems: 1. Low fees are now a negative signal: defaults actually indicate lower reliability, and routing gets tarpitted trying them

Re: [Lightning-dev] Quotes for Article on LN Bug Fix

2019-09-28 Thread Rusty Russell
Hi Ed, Sorry for the delay. There's always a tension between safety and disclosure. In this case, the three implementations agreed that it was best to make sure everyone had done a release and ensure there were no problem with upgrades and that the majority of people had upgraded before

[Lightning-dev] Full Disclosure: CVE-2019-12998 / CVE-2019-12999 / CVE-2019-13000

2019-09-27 Thread Rusty Russell
ibes the requirement to wait for confirmations[5]. It did NOT, however, require the receiver to actually check that the transaction is the one promised by the funder: both the amount and the actual scriptpubkey. Discovery - Rusty Russell (Blockstream) discovered this while working on protocol

[Lightning-dev] Avoiding gossip spam: how many updates do you need?

2019-09-05 Thread Rusty Russell
Hi all, The next release of c-lightning will start suppressing gossip which comes too fast. I have implemented a simple filter which allows each message (node_announcement or channel_update) ONCE PER DAY on average, with a burst up to 4 times per day. We will also discard identical

[Lightning-dev] CVEs assigned for lightning projects: please upgrade!

2019-08-30 Thread Rusty Russell
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Security issues have been found in various lightning projects which could cause loss of funds. Full details will be released in 4 weeks (2019-09-27), please uprade well before then. Effected releases: CVE-2019-12998 c-lightning < 0.7.1

Re: [Lightning-dev] Proposal: Automated Inbound Liquidity With Invoices

2019-08-13 Thread Rusty Russell
Ecurrencyhodler Blockchains writes: >1. Bob wants to send me 100,000 sats. >2. My node just came online and has 0 inbound liquidity. >3. I create an invoice for 100,000 sats. My LN node recognizes I have 0 >inbound liquidity so my wallet also embeds my URI in the invoice. >4.

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

2019-08-08 Thread Rusty Russell
ZmnSCPxj via Lightning-dev writes: >> > Typical quotes suggested that commodity hardware would take 2 seconds to >> > find a route >>   >> Can you provide a reproducible benchmark or further qualify this number (2 >> seconds)? > > No reproducible benchmark. OK, on my digital ocean 2-cpu 4GB ram

Re: [Lightning-dev] [PROPOSAL] Removal of proposal to make CSV delay symmetric

2019-07-24 Thread Rusty Russell
Pierre writes: >> > How would bruteforcing on the CSV delay be different from a BIP32 >> > wallet with look ahead keys? Especially given that we could try with >> > most probable values first. >> >> It's a big multiplier, given that CSV can be specified by the >> counterparty. If you accept up

Re: [Lightning-dev] [PROPOSAL] Removal of proposal to make CSV delay symmetric

2019-07-20 Thread Rusty Russell
Pierre writes: > Hi Rusty, > > How would bruteforcing on the CSV delay be different from a BIP32 > wallet with look ahead keys? Especially given that we could try with > most probable values first. It's a big multiplier, given that CSV can be specified by the counterparty. If you accept up to

[Lightning-dev] [PROPOSAL] Removal of proposal to make CSV delay symmetric

2019-07-17 Thread Rusty Russell
Hi all, In Adelaide we proposed that CSV delays be symmetric; that the to-self output would be delayed to avoid weird "no, you close!" games. Unfortunately, Roasbeef points out that this undermines the great strength of the option_static_remotekey, which allows a

[Lightning-dev] [PROPOSAL] Gossip protocol v2

2019-07-13 Thread Rusty Russell
Hi all, At the last Summit we discussed using Schnorr sigs for gossip; we'll also need to change things for taproot-based channels, so I think it makes sense to combine the two changes. channel_announcement drops from 430 to 140 (plus feature bitmap). channel_update drops from to 136 to

[Lightning-dev] [RELEASE] c-lightning v0.7.1: The Unfailing Twitter Consensus Algorithm

2019-07-04 Thread Rusty Russell
This is a recommended upgrade! https://github.com/ElementsProject/lightning/releases/tag/v0.7.1 We're pleased to announce c-lightning 0.7.1, named by new C-Lightning Core Team member Lisa Neigut. Highlights for Users o Gossip (both serving to others and

Re: [Lightning-dev] More thoughts on NOINPUT safety

2019-03-19 Thread Rusty Russell
es. Since "must have a non-SIGHASH_NOINPUT" rule addresses the first reuse scenario (as well as the second), I'd be content with that proposal. Future segwit versions may choose to relax it.[1] Cheers, Rusty. [1] Must be consensus, not standardness; my prev suggestion was bogus. Rusty Russel

Re: [Lightning-dev] [META] Mailing list move

2019-03-18 Thread Rusty Russell
nSCPxj > > Sent with ProtonMail Secure Email. > > ‐‐‐ Original Message ‐‐‐ > On Saturday, March 16, 2019 12:45 PM, Rusty Russell > wrote: > > > Hi all, > > > > Linux Foundation (who graciously host this list for us) is > > deprecating their mailing list

[Lightning-dev] [META] Mailing list move

2019-03-15 Thread Rusty Russell
Hi all, Linux Foundation (who graciously host this list for us) is deprecating their mailing list infrastructure (mailman2 is unmaintained, apparently v3 is a mess), and migrating lists to groups.io. Apparently this is the direction that bitcoin-dev is heading. Unless people raise

[Lightning-dev] [RFC] option_static_remotekey

2019-03-14 Thread Rusty Russell
e for HTLC outputs). This is a much simpler stepping stone, and resolves one immediate problem. Suggested-by: @roasbeef Signed-off-by: Rusty Russell diff --git a/.aspell.en.pws b/.aspell.en.pws index b1a1ad3..20664f2 100644 --- a/.aspell.en.pws +++ b/.aspell.en.pws @@ -33

  1   2   3   >