--- Log opened Mon Apr 26 00:00:37 2021
00:58 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has joined #lightning-dev
01:07 -!- musdom [~Thunderbi@202.184.3.8] has joined #lightning-dev
01:24 -!- felixweis [sid154231@gateway/web/irccloud.com/x-rjfaljpefwtmhbry] has quit [Read error: Connection reset by peer]
01:24 -!- robmyers [sid14471@gateway/web/irccloud.com/x-qbibrvrjrrsilpfg] has quit [Ping timeout: 245 seconds]
01:24 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-agddwmhusnotufog] has quit [Ping timeout: 246 seconds]
01:24 -!- yakitorifoodie1 [yakitorifo@gateway/web/irccloud.com/x-udattsmwragtwffx] has quit [Read error: Connection reset by peer]
01:24 -!- wallet42____ [sid154231@gateway/web/irccloud.com/x-guxdlozlodzaccek] has quit [Read error: Connection reset by peer]
01:25 -!- robby938________ [sid238281@gateway/web/irccloud.com/x-ffxqroxxhwwodbtm] has quit [Read error: Connection reset by peer]
01:29 -!- robby938________ [sid238281@gateway/web/irccloud.com/x-edvcymgdzvmpxmpw] has joined #lightning-dev
01:29 -!- felixweis [sid154231@gateway/web/irccloud.com/x-hrgkjieufsancvyx] has joined #lightning-dev
01:30 -!- yakitorifoodie1 [yakitorifo@gateway/web/irccloud.com/x-faldpkpwolszyase] has joined #lightning-dev
01:30 -!- robmyers [sid14471@gnu/social/robmyers] has joined #lightning-dev
01:30 -!- jakesyl [sid56879@gateway/web/irccloud.com/x-pmfzsdugzopkxzat] has joined #lightning-dev
01:30 -!- wallet42____ [sid154231@gateway/web/irccloud.com/x-ncppgzjybbotbvgu] has joined #lightning-dev
02:00 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
02:01 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
02:02 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
02:10 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
02:15 -!- pm7 [pm7@gateway/shell/mydevil.net/x-xllnrojjgetcnaxl] has quit [Quit: Żegnam]
02:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
03:14 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has quit [Ping timeout: 240 seconds]
03:57 -!- musdom [~Thunderbi@202.184.3.8] has quit [Ping timeout: 245 seconds]
04:03 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has joined #lightning-dev
04:17 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has quit [Ping timeout: 252 seconds]
04:25 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has joined #lightning-dev
04:33 -!- musdom [~Thunderbi@202.184.3.8] has joined #lightning-dev
04:43 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
04:47 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Ping timeout: 240 seconds]
04:55 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 252 seconds]
04:56 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
05:16 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
05:28 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
06:06 -!- musdom [~Thunderbi@202.184.3.8] has quit [Ping timeout: 240 seconds]
06:07 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has quit [Ping timeout: 240 seconds]
06:19 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
06:19 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has joined #lightning-dev
06:20 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
06:24 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
06:25 -!- Xaldafax [~Xaldafax@cpe-198-72-160-101.socal.res.rr.com] has joined #lightning-dev
06:26 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
06:46 -!- dr_orlovsky [~dr-orlovs@31.14.40.19] has joined #lightning-dev
06:46 -!- dr-orlovsky [~dr-orlovs@31.14.40.19] has quit [Ping timeout: 265 seconds]
07:12 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
07:13 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev
07:15 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 252 seconds]
07:16 -!- openoms [~quassel@gateway/tor-sasl/openoms] has joined #lightning-dev
07:16 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
07:21 -!- swambo [~swambo@92.41.176.174.threembb.co.uk] has quit [Ping timeout: 252 seconds]
07:35 -!- copumpkin [~copumpkin@unaffiliated/copumpkin] has joined #lightning-dev
07:58 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 252 seconds]
08:01 -!- wxss [~user@mail.deeplinkmedia.com] has quit [Remote host closed the connection]
08:10 -!- proofofkeags [~proofofke@205.209.28.54] has joined #lightning-dev
08:17 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds]
08:18 -!- sr_gi [~sr_gi@static-167-163-230-77.ipcom.comunitel.net] has quit [Quit: The Lounge - https://thelounge.chat]
08:19 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
08:19 < lnd-bot> [lightning-rfc] cdecker force pushed 2 commits to all-the-sigs: https://github.com/lightningnetwork/lightning-rfc/compare/bc821bbef0e8...ed3abf60b149
08:19 < lnd-bot> lightning-rfc/all-the-sigs 76a38dc Christian Decker: proposal: Added Funding Timeout Recovery proposal
08:19 < lnd-bot> lightning-rfc/all-the-sigs ed3abf6 Christian Decker: squash! proposal: Added Funding Timeout Recovery proposal
08:19 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
08:29 -!- wxss [~user@mail.deeplinkmedia.com] has joined #lightning-dev
08:43 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
08:43 < lnd-bot> [lightning-rfc] cdecker pushed 1 commit to keyolo: https://github.com/lightningnetwork/lightning-rfc/commit/654fac0c3331
08:43 < lnd-bot> lightning-rfc/keyolo 654fac0 Christian Decker: proposal: Added Funding Timeout Recovery proposal (KEYOLO variant)
08:44 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
08:45 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
08:45 < lnd-bot> [lightning-rfc] cdecker opened pull request #866: proposal: Added Funding Timeout Recovery proposal (KEYOLO variant) (master...keyolo) https://github.com/lightningnetwork/lightning-rfc/pull/866
08:45 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
08:55 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
09:08 -!- Jackielove4u [uid43977@gateway/web/irccloud.com/x-zdrlyohajirblhze] has quit [Quit: Connection closed for inactivity]
09:08 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
09:10 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
09:52 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds]
10:12 -!- musdom [~Thunderbi@202.184.3.8] has joined #lightning-dev
10:34 -!- vincenzopalazzo [~vincenzop@host-79-18-34-139.retail.telecomitalia.it] has joined #lightning-dev
11:15 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
11:16 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
11:17 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
11:20 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 240 seconds]
11:31 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 245 seconds]
11:32 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #lightning-dev
11:39 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
11:39 -!- joost__ [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
11:48 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
11:49 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Client Quit]
11:56 -!- musdom [~Thunderbi@202.184.3.8] has quit [Quit: musdom]
11:57 -!- musdom [~Thunderbi@202.184.3.8] has joined #lightning-dev
12:49 -!- t-bast [~t-bast@2a01:e0a:156:8800:5c70:c837:eae:c90f] has joined #lightning-dev
12:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
12:56 < t-bast> Hello everyone!
12:57 < BlueMatt> hi t-bast!
12:57 -!- unixb0y [~unixb0y@p200300c6bf2c6447992d8b285ce07e0f.dip0.t-ipconnect.de] has joined #lightning-dev
12:58 < ariard> yo t-bast
12:59 < jkczyz> hey
12:59 < t-bast> I started reading https://github.com/ariard/L2-zoology/blob/master/threats/README.md, very nice to have all of these grouped in one place
12:59 < BlueMatt> bitconner: re-ping on https://github.com/lightningnetwork/lightning-rfc/pull/608#issuecomment-815496095
13:00 < BlueMatt> yes, thanks ariard for your persistent work here! Even if some of us are deficient in available time to help as much as we should :(
13:00 < harding> ariard: I agree with t-bast, it is nice to have that all grouped together.
13:00 < t-bast> I'll find some more time this week to read all of it :)
13:01 < ariard> t-bast: yep actually working on translating them in functional tests : https://github.com/ariard/bitcoin/tree/2021-04-26-preimage-pinning
13:01 < t-bast> ariard: nice!
13:01 < ariard> and then when it's good i'll uplift them to signet
13:02 < unixb0y> Hi today is LN spec meeting? :) 
13:02 < rusty> Yes!  Hi all!
13:02 < t-bast> BTW for those who know how to review core wallet PRs, I'd love some feedback on https://github.com/bitcoin/bitcoin/pull/21359
13:02 < t-bast> It would be really helpful for us to get this integrated for anchor outputs
13:02 -!- lndev-bot` [~docker-me@46.101.246.115] has quit [Remote host closed the connection]
13:02 < ariard> t-bast: used to do a lot of core wallet, i can have a look :)
13:03 -!- lndev-bot2 [~docker-me@46.101.246.115] has joined #lightning-dev
13:03 < t-bast> thanks!
13:03 < cdecker> Hi everyone ^^
13:03 < niftynei> hello hello
13:04 < unixb0y> Noice! Rusty you’re rustyrussel?
13:04 < t-bast> Did someone have time to implement https://github.com/lightningnetwork/lightning-rfc/pull/847? I have a PR ready for eclair, waiting for interop
13:04 < rusty> unixb0y: No.  I'm rustyrussell.
13:04 < unixb0y> Big fan!
13:05 < niftynei> t-bast: it's on my todo list for this week
13:05 < t-bast> cool thanks niftynei, don't hesitate to ping me when you have something and I'll do the testing
13:05 < BlueMatt> quick update on meeting: you can blame canberra's failed vax rollout for rusty's inability to travel, but short of my previous suggestion of putting rusty in one of those big bubble balls looks like we're probably delayed until very end of this year or next.
13:06 < rusty> unixb0y: thanks!
13:07 < t-bast> damn, let's hope we can make it at some point...
13:07 < vincenzopalazzo> hello guys :)
13:07 < cdecker> Would be great to see everyone in RL again :-)
13:07 < ariard> cdecker: well just go to #rust-bitcoin ?
13:08 < t-bast> Definitely, it would be great!
13:08 < rusty> BlueMatt: that's not quite fair; I believe we're employing a technique called "we're an island, and the rest of you are our guinea pigs".
13:08 < t-bast> Everywhere is an island if you zoom out enough...
13:08 < ariard> vincenzopalazzo: hi :)
13:08 < BlueMatt> rusty: lol, well, ok, i suppose the rest of us can get in bubble balls? :)
13:08 < BlueMatt> lightning spec meet up, strange japanese reality show edition
13:09 < ariard> lightning spec ninja warrior edition xD
13:09 < rusty> BlueMatt: that would be amazing...
13:10 < BlueMatt> anyway, back to meeting
13:11 < rusty> t-bast: I'll have to do a mechnical check on 852, but looks good.
13:11 < t-bast> rusty: great, it's painful to review but it's actually a good clean-up
13:12 < t-bast> those test vectors became a bit of a mess
13:12 < rusty> Yes, I have a test which outputs it, so I'll change the format (then usually there are a few minor edits to remove stuff) and ensure it's the same.  Agreed that cleanup is a win.
13:15 < t-bast> Shall we officially start?
13:15 < t-bast> #startmeeting LN Spec Meeting
13:16 < t-bast> ...
13:16 < ariard> no bot?
13:16 < t-bast> bot is dead again?
13:16 < cdecker> I just restarted it
13:16 < vincenzopalazzo> null pointer :-)
13:16 < t-bast> #startmeeting LN Spec Meeting
13:17 < t-bast> Let's do without :)
13:17 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
13:17 < t-bast> #startmeeting LN Spec Meeting
13:17 < lndev-bot> Meeting started Mon Apr 26 20:17:13 2021 UTC and is due to finish in 60 minutes.  The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot.
13:17 < lndev-bot> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
13:17 < lndev-bot> The meeting name has been set to 'ln_spec_meeting'
13:17 < cdecker> Ah there you go, it's not working on the VPS but from home it is...
13:17 < t-bast> #topic Funding Timeout Recovery
13:17 < rusty> t-bast: I'll have to do a mechnical check on 852, but looks good. (repaste from before meeting start, for posterity)
13:18 < cdecker> Ok, as promised I wrote up the keyolo variant, but it feels "wrong"
13:18 < t-bast> thanks rusty! Let's move to the other items, once we have interop on that one we'll just merge
13:18 < cdecker> PR #866 is the competing one btw
13:18 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/864
13:18 < t-bast> #https://github.com/lightningnetwork/lightning-rfc/issues/866
13:18 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/866
13:18 < cdecker> Let's keep tradeoff discussions to #854 to keep them localized and wording suggestions can go to the respective PR
13:18 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/854
13:19 < rusty> I like 866, but it's weird.  We can't extend the error message, so we need a new msg anyway.  I don't think the discussion of malleability applies, since "here's the key, do what you want" seems sufficient to cover that?
13:20 < cdecker> Would have been nice to add a TLV to the error instead
13:20 <+roasbeef> cdecker: yeh not a fan of just sending private keys over the wire to peers as I commented on the OG PR.... 
13:21 < ariard> cdecker: another advantage of OG proposal is fundee can still add a balance in the closing tx
13:21 < cdecker> Yep, same here, it should be rare, so I don't weigh the on-chain footprint too much either
13:21 < ariard> like if you negotiated a push_msat out-of-band or already paid for it
13:22 < cdecker> ariard: wouldn't that require a sighash_single and require the matching output to be the fundee's?
13:22 < ariard> cdecker: for sure it would require single, lastest of proposal is sighash_none?
13:22 < cdecker> That'd allow the fundee to force an output to him as compensation
13:22 -!- smartineng [~Icedove@88.135.18.171] has quit [Quit: smartineng]
13:23 < cdecker> Yep, sighash_none to impose as little restrictions as possible
13:23 < BlueMatt> cdecker: I'm not sure what you mean "creates a new foot-gun" - if you dont have a way of storing the latest state reliably, you are already in face-gun territory, this isnt new there.
13:23 < cdecker> Not a fan of complicating what is pretty much a gentlemans agreement
13:23 < BlueMatt> there was also discussion of this in the context of taproot
13:23 < ariard> and how do that make sense for dual-funded channel? wouldn't OG proposal makes more sense
13:23 < BlueMatt> where sighash_single isnt just a trivial change, its materially more expensive
13:24 < cdecker> Hm? Which footgun comment are you referring to? Made a couple of them in this context :-)
13:24 < BlueMatt> cdecker: I was referring to the quote you left on the non-yolo variant describing the difference
13:24 < cdecker> dual-funded channels are not impacted by this since the funding needs to be collaboratively agreed on anyway, and RBF can't be done without collaboration
13:24 <+roasbeef> taproot is still a ways away, and it'll be a pretty massive overhaul, so imo shouldn't affect what we do in the short term 
13:25 <+roasbeef> don't think I can bring myself to add in code that dumps a private key over the wire....
13:25 < cdecker> That was roasbeef's comment talking about a footgun :-)
13:25 < BlueMatt> sure, but if we're close to the fence on a proposal, it seems like a worthwhile thing to shift us one way or another :)
13:25 < ariard> cdecker: sure but we assume the funding has confirmed here and try to avoid feerate penalty on commitment
13:25 <+roasbeef> how would ppl even expose this on the node level? does the responder have to opt in to agree to send their key? 
13:26 <+roasbeef> just seems really error prone imo 
13:26 <+roasbeef> inb4 some reddit scam or something 
13:26 < cdecker> Nah, it's a throwaway key that should not leak info (in theory when derived in a hardened way), but I also prefer #854 (non-keyolo)
13:26 < BlueMatt> huh? hopefully the node never exposes some config option to let users manually do this?
13:27 < ariard> and if you have a hardware signer? quite uncomfortable to have a policy exporting private key
13:27 <+roasbeef> cdecker: throw away key? I read it as the funding private key rn 
13:27 <+roasbeef> and also what if you can't even get a private key from a node easily? 
13:27 < cdecker> Yeah, it's just "1) forget channel but keep stub, 2) on reconnect tell the peer so they can recover"
13:27 < BlueMatt> in both cases you have to make sure you make sure the channel closure is committed to disk before you expose anything, I dont think thats very different
13:27 < BlueMatt> alright, well so far it sounds like everyone disagrees with me. I'm happy to be overruled :)
13:27 < cdecker> roasbeef: yes, but its a funding_privkey specifically generated for that channel, if you're not using the channel there's no need to keep it private
13:28 <+roasbeef> yeh but we don't really have any spec level requirements on how that key is generated cdecker 
13:28 < cdecker> BlueMatt: yep, that was my comment to roasbeef's footgun: forgotten, persisted, marked as inactive, and only then reveal the privkey
13:28 <+roasbeef> so if you assume the worst case, bad things could happen, and also we'd essentially be requiring hot funding keys forever on the spec levle 
13:28 < ariard> BlueMatt: well with taproot you can add a tapscript to sign to be used especially with sighash_single, but you might loose the feerate saving due to longuer merkle branch...
13:29 < BlueMatt> cdecker: right, i think my point is more broadly the foot-gun quesiton here is no different between the two proposals, and it is further no different than really every other "you didnt persist properly" foot gun in lightning today
13:29 < cdecker> Just to be clear, the keyolo is the result of 4 weeks ago's discussion, I'm not a fan myself, but wanted to give the option
13:29 < BlueMatt> ariard: right, my point was you cannot do the joined signature. thanks for clarifying :)
13:29 < cdecker> Also because it seemed overwhelmingly everyone wanted to go keyolo instead xD
13:29 < t-bast> I think the argument of not having easy access to the funding private key because it's delegated to another component is a reasonable argument to prefer #854 over #866
13:30 < cdecker> Also it doesn't introduce the belated requirement of hardened derivation for the funding_privkey
13:30 < t-bast> I wanted to go keyolo for simplicity's sake, but I understand that it's actually harder for some implementations than non-keyolo
13:30 < rusty> I somewhat share roasbeef's concern: now our HSM gives out keys, which makes me uncomfortable.  OTOH, it's definitely simpler.
13:31 < BlueMatt> t-bast: I mean signing sighash-none is really not a lot different from just exposing the priv key
13:31 < BlueMatt> hsm should have similar requirements for both, honestly
13:31 < cdecker> Good point rusty, it'd be state to keep in our hsmd to remember that we gave out the key, and that we mustn't sign commitment txs for that key anymore
13:31 < cdecker> ... which is also true for #854, damn
13:32 < t-bast> BlueMatt: true, sighash_none is something HSMs wouldn't lightly sign...
13:32 < ariard> well you can delete the key once sent, but quid of network disconnection at the same time?
13:33 < BlueMatt> ariard: yea, preferably not, though I guess its best-effort anyway, soooooooo
13:33 <+roasbeef> t-bast: depends on the hsm really there's levels, first level is just it can do secp signing before even doing sighash stuff, etc 
13:33 < BlueMatt> ariard: yea, i think thats not really a bad idea, really. I mean it sucks cause its not reliable, but the funder shouldnt be relying on this to begin with
13:33 < t-bast> roasbeef: an HSM that doesn't do any kind of validation is a false sense of security imho
13:33 <+roasbeef> t-bast: well you start w/ just segregation there go from there 
13:34 <+roasbeef> it isn't a binary thing 
13:34 < ariard> BlueMatt: you might cache the message until ack from counterparty but have deleted the state
13:34 < BlueMatt> ariard: there is no ack? or do you mean tcp-ack?
13:34 < cdecker> Yep, it's a simple proposal, must not work all the time (gentleperson's agreement remember) and we definitely don't want to get incentives such as fundee payoffs into the mix
13:34 < ariard> BlueMatt: i mean lightning message level ack, tcp would be such a layer violation
13:35 < ariard> and you might not run lightning on tcp
13:35 < cdecker> The stubs can be removed after a while btw, if the peer doesn't reconnect in 2 weeks there's no need to keep them around imho
13:35 < t-bast> I agree with cdecker, this should still be an exceptional case and we shouldn't over-engineer it
13:35 < BlueMatt> ariard: ok, so you mean we should add an ack. i guess, but, like, then what if the funder doesnt send one, then its the same as having no ack :)
13:36 < rusty> I think we can do simpler than 854.  1. extend reestablish to include the outpoint and amount for the commit tx. 2. have a reply which signs that for any stub, aborted channel.  This means it doesn't even need to remember anything except the key, peer id and channel id, and covers the "I accidentally RBFed the commit tx" case.
13:36 < ariard> BlueMatt: let's say timeout on your cache? but yeah sounds over-engineering
13:37 < BlueMatt> rusty: presumably you mean with sighash_none? or we'd have to include the output as well.
13:37 < rusty> BlueMatt: yeah, if you want sighash_single you would have to provide output.  Or normal sig and provide entire tx, but that's getting a bit hairy maybe.
13:38 < cdecker> Let's start with sighash_none, we can always add complexity later (... never)
13:38 <+roasbeef> kek
13:38 < rusty> cdecker: but can't someone else steal the sighash none?  Hmm, I guess it needs both sigs, so no...
13:38 < BlueMatt> dont you mean remove complexity by sending the privkey? *ducks*
13:39 < BlueMatt> but, sure, I'm down for whatever
13:39 < ariard> if you have to agree on output amount you migh need yet another negotiation mechanism
13:39 < BlueMatt> you shouldnt need to agree - if you've closed the channel, you've closed it
13:39 < t-bast> I don't follow why it would be simpler than #854
13:39 < BlueMatt> sign anything the counterparty wants, if its wrong, full nodes will reject it
13:40 < ariard> in the hypothesis we have also sighash_single and the fundee would propose a cooperation payoff 
13:40 < BlueMatt> yea, this is more "nodes will do this by default cause its nice, and most people dont modify their nodes because its hard" not "game theoretically secure and ideal"
13:41 < rusty> BlueMatt: and of course "it's worked so far" :)
13:41 < BlueMatt> right, works nearly perfectly in practice, works none of the time in theory :)
13:41 < cdecker> ariard: payoff for the fundee seems out of scope, that's far more negotiation than I'm willing to add for such a corner case
13:42 < ariard> cdecker: i far agree there, i was just thinking in a future where lightning is so efficient than people to price their missed opportunities for lack of funding confs
13:42 <+roasbeef> does anything deployed rn even use sighash_none? we're about to get soooo many cool points 
13:43 < t-bast> xD
13:43 < BlueMatt> roasbeef: lol, great point!
13:43 < ariard> roasbeef: well you need to combine it with sighash_noinput to be a cool kid
13:44 < unixb0y> Hey guys any news about Offers in lnd? :) 
13:44 < rusty> "I don't usually sign random transactions, but when I do it's with SIGHASH_NONE".
13:44 < cdecker> That signature would sign pretty much the timelock and that's it xD
13:44 < t-bast> Shall we conclude that we're leaning more towards #854?
13:44 <+roasbeef> rusty: LOL
13:45 < cdecker> Sounds like we pretty much agree that #854 is a bit more restrictive than #866 and we can always expand based on later experience if needed
13:45 < rusty> t-bast: ack.  More on issue?
13:45 < cdecker> sgtm
13:46 < t-bast> #action Finalize details of 854 on PR
13:46 < t-bast> #topic Deterministic points and splicing
13:46 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/862
13:46 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/863
13:46 < t-bast> I feel those two go together
13:46 < rusty> OK, so before we get too far into this: I'm on the fence.
13:47 -!- eugene-ff9 [4745e6ff@71.69.230.255] has joined #lightning-dev
13:47 < cdecker> How's the view?
13:47 <+roasbeef> interesting...so no more randomization?
13:47  * roasbeef looks at the commit 
13:47 < BlueMatt> so one question i have is what about cases where you may want some keys derived from different things - eg payment_point maybe you want from an offline seed but the other keys maybe from an online one?
13:47 <+roasbeef> oh this is the sequence number for pubkeys thing?
13:48 < rusty> The reason is that deterministic points mean that one channel is not really isolated from another any more, since the keys are now reversibly derived from the node id.  So if you accidentally give away one key, you lose the farm.  This was not true before.
13:48 <+roasbeef> how would ppl handle the new state requirement in practice? so like clear node, retain seed, re-use seed for new node situation 
13:48 <+roasbeef> iirc in the past didn't CL remove something like this from the funding key derivation rusty ?
13:48 < cdecker> Ah lol, if we get #862 then #866 is out of the question anyway, since we can't generate hardened keys using a generation
13:49 < rusty> But OTOH, being able to sniff out your own channels from raw blockchain data is pretty damn neat on paper.
13:50 <+roasbeef> something something OP_RETURN....I think electrum does this in practice now/ 
13:50 < BlueMatt> * and knowing *who* you had a channel with, correct?
13:50 < rusty> roasbeef: not that I recall: we used to hand the "per channel" keys across to the (per-peer) daemon, but then reverted to keeping them in the HSM.  Both are reasonable strategies.
13:50 <+roasbeef> ?
13:50 < rusty> BlueMatt: you brute force from known nodes, plus anyone who connects to you.
13:50 < BlueMatt> right, ok
13:50 <+roasbeef> rusty: iirc was something a sequence number per node pubkey to derive pubkeys or something, could be remembering something else...
13:51 < rusty> roasbeef: yeah, we use the db id (which only rachets forward).
13:51 < rusty> So the scheme gets weaker since you need a counter of some kind, and now you get gap issues anyway.
13:51 < t-bast> Can't you at least scope the link between key per-node? To ensure that if you give away one key, only all channels to that node are at risk, and not channels to other nodes?
13:51 < BlueMatt> any response to my initial question?
13:52 <+roasbeef> rusty: doesn't this still require you to keep track of who the other node is? 
13:52 < BlueMatt> I do think that at least being able to generate payment-point in a different way is very useful.
13:52 < BlueMatt> probably others
13:52 < t-bast> BlueMatt: IIUC this PR would make this scenario impossible...?
13:52 < rusty> roasbeef: you brute force from the public gossip + anyone who (re-)connects to you.
13:52 <+roasbeef> what if they get pruned as being a zombie from teh channel graph or something, not sure if y'all keep around the extra nodes there 
13:53 < BlueMatt> t-bast: right, IIUC the same - hence why I bring it up :). may be there we could separate "maybe we want that separate" from "nah, probably not"?
13:53 < rusty> BlueMatt: you keep payment_basepoint for that reason.
13:53 < rusty> roasbeef: yeah, best-effort, handwave something.
13:54 < BlueMatt> hmmm, ok. there's probably some other keys that would be good to split out, I'd think.
13:54 < rusty> So I think personally that the "secret backup blob stashed with peer and re-served on every reconnect" probably covers this and more.  And it's easier to implement.
13:54 < t-bast> right: `the payment basepoint is supplied directly` at the very end of the PR
13:55 < ariard> you might traverse the transaction logs with filters of well-scored routing nodes first
13:56 < t-bast> re my earlier question, I got to the `point derivation` part of the PR, so it seems that my question was moot, there's no connection between keys for channels with a different node
13:56 < BlueMatt> yea, I'm definitely -0.01 here - I doubt we'll ever implement the chain-scanning stuff, if only because its a whole new api for it, and I could see it restricting what we can do going forward with different keys in different places/security models
13:56 <+roasbeef> t-bast: doesn't eclair do the encrypted blob storag ething now for phoenix clients? 
13:56 < BlueMatt> t-bast: oh, wait, what?
13:56 < BlueMatt> so its only the funding key thats derived consistently?
13:57 <+roasbeef> rusty: rather than mandate it couldn't it be a funding modifier? so you include the key as normal, but then specify that's how it ws generated 
13:57 < BlueMatt> I totally misunderstood that, and I thought I skimmed the mailing list post :/
13:57 < t-bast> roasbeef: yes we're doing that
13:57 <+roasbeef> I think it's funding, htlc, payment base point 
13:57 <+roasbeef> 4. The `funding_pubkey` is defined as the `node_id` + G*T(`funding`).
13:57 <+roasbeef> 5. The `delayed_payment_basepoint` is defined as `node_id` + G*T(`delayed_payment`).
13:57 <+roasbeef> 6. The `htlc_basepoint` is defined as the `node_id` + G*T(`htlc`).
13:57 < rusty> roasbeef: yeah, but it's really only useful if everyone does it, so I short-circuited.  But I was young and optimistic when I wrote that proposal...
13:57 < BlueMatt> right, ok, so I'm not crazy. I think at least delayed_payment_basepoint may want to be on a different device
13:58 <+roasbeef> rusty: you as node could only open chans to nodes that use the deterministic generation possibly 
13:58 < ariard> well you might announce a derivation policy like another point for delayed_payment_basepoint
13:58 < ariard> but it will more work for your counterparty
13:59 < rusty> So, I'm voting to close the PR, apologize to llfourne and open a "backup blob" PR...
14:00 < t-bast> the backup blob is quite simple to do ;)
14:00 < cdecker> Hm, too bad, I really liked the proposal, it's a nice clean thing to do
14:02 < rusty> cdecker: but the effect on implementations' key isolation is as disquieting as sending privkeys over the wire IMHO
14:02 < cdecker> Ok, if the encrypted blob is also easy we can do that instead
14:03 < ghost43_> isn't "backup blob" orthogonal to deterministic points? I mean regardless of storing a backup with the counterparty it would be highly useful to be able to scan the blockchain to find your channels and the counterparty in the first place
14:03 < t-bast> you can just wait for nodes to reconnect to you
14:04 <+roasbeef> ghost43_: electrum allows that iirc rn by using an OP_RETURN
14:04 < ghost43_> yes I am very familiar with what electrum does, I contrbute to it :P
14:04 < ghost43_> it would save the OP_RETURN, that's all
14:04 < rusty> ghost43_: it would be, but it's also not entirely practical, doesn't cover all cases, and is harder to implement.
14:04 <+roasbeef> oh cool yeh wasn't sure if electrum peeps were here lol
14:05 <+roasbeef> rusty: rn lnd's SCB stuff has worked pretty well in practice, a node never forget ths information it needs to force close after getting a chan reest message 
14:05 < BlueMatt> ghost43_: sure, but doing it by negotiating a derivation which each possible node you might talk to is a lot of addresses to send to an electrum server
14:05 < ghost43_> BlueMatt: yes, that is true
14:08 -!- eugene-ff9 [4745e6ff@71.69.230.255] has quit [Quit: Connection closed]
14:08 < rusty> So quickly: backup blob needs a feature bit, a new "hold my beer" msg which updates the blob, and a new tlv field for init (or a new msg?) to return it.
14:09 < t-bast> if you want to really store your very latest channel state, you need to add this blob to more messages
14:09 < BlueMatt> rusty: hold-by-beer ack
14:09 < cdecker> Nice, having to fit into the TLV also puts a nice upper bound on size
14:10 <+roasbeef> rusty: something something tacked onto chan reest? (the blob)
14:10 <+roasbeef> the blob is meant just for force closing right? and not resumption? 
14:10 < ghost43_> roasbeef: depends if you want a per-chan blob
14:10 <+roasbeef> how would you handle a peer giving you a dated blob?
14:10 <+roasbeef> if it's per channel state...seems not possible 
14:11 < rusty> roasbeef: you gather them from all peers and take latest, I think.
14:11 < t-bast> if you want it for resumption you need to add it to `commit_sig` and `revoke_and_ack`
14:11 <+roasbeef> gotta be static imo, no pitfalls, just ability to get the other side to force close if needed, so you'd store them w/ peer you don't have a channel w/ 
14:12 <+roasbeef> t-bast: ecliar does per state rn? so then users just trust it won't get swapped out/
14:12 <+roasbeef> ?
14:12 < ariard> by resumption you mean per-revoked output punishment state?
14:13 < t-bast> that's true, otherwise it does consume a lot of bandwidth/storage on many nodes, maybe a lighter backup makes more sense for a fully distributed solution (and just target unblocking force-close scenarios)
14:13 < ghost43_> sending an old blob has similar game theory to the chan reestablish message dataloss protect I think
14:13 < t-bast> but the mechanism should be opaque enough so that it can be re-used for full-state storage for nodes that want it imo
14:14 < rusty> Well, you can pack whatever you want in there.  At least the info about what other channels you have, and any seed info associated.
14:14 < t-bast> Perfect, as long as the spec just specifies it as a blob of bytes in a TLV that may be added to various messages, it will be flexible enough
14:14 <+roasbeef> ghost43_: imo no, this can let you give a peer an older version to braodcast, w/ chan reest you have deterrence of having a tower out there 
14:14 < t-bast> And it lets each implementation put whatever they'd like in there
14:15 < t-bast> but you'd use your towers as well for that storage wouldn't you?
14:16 <+roasbeef> g2g will peep logs 
14:16 < ghost43_> roasbeef: kind of same situation with chan reest. if you lost the latest state but don't know it, the counterparty can trick you to force-close with it
14:16 < rusty> I think embedding in init or as a separate post-init msg means you don't need a live channel to use it, so you can pay non-peers in future to do the same thing for you.
14:16 < rusty> Anyway, let's move on, I have a hard stop in 15 too...
14:16 < t-bast> Good idea
14:17 < t-bast> Yep let's save splicing for next time and quickly discuss https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html
14:17 -!- Bugz [~pi@035-134-224-053.res.spectrum.com] has quit [Ping timeout: 240 seconds]
14:17 < ariard> +1 to keep it in a post-init msg, bolt13 tower proposal has its own compensation mechanism
14:17 < t-bast> It shuold just take a couple minutes
14:17 < t-bast> #action drop deterministic points in favor of an encrypted backup construction
14:17 < ariard> okay quickly i'm setting a bunch of irc workshop about better l2 onchain support
14:17 < t-bast> #topic ariard cross-layer work
14:17 < t-bast> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-April/003002.html
14:18 < t-bast> Let's just all attend if we can, it's going to be great :)
14:18 < ariard> agenda is : package-relay or logically equivalent, full-rbf, coordinated security disclosure across layers, and onchain security tooling (e.g libstandardness)
14:18 < BlueMatt> roasbeef: can you poke bitconner to respond on https://github.com/lightningnetwork/lightning-rfc/pull/608#issuecomment-815496095 ? I'm vaguely leaning towards proposing we revert it over bothering to implement it.
14:18 < ariard> if you have any other issues you wanna talk let me know but would like to keep it straigth, like 2-3 irc meetings
14:18 < BlueMatt> yes, thanks for organizing ariard!
14:19 -!- Bugz [~pi@035-134-224-053.res.spectrum.com] has joined #lightning-dev
14:19 < rusty> ariard: good initiative...
14:19 < BlueMatt> what about pinning mitigations, eg the carve-out thinggy that anchors uses?
14:19 < ariard> and schedule is mid-june, after bitcoin 2021
14:19 < ariard> BlueMatt: i hope we can get ride of most pinning with package-relay/full-rbf but do u think something more specific here?
14:20 < ariard> in fact you might deprecate carve-out and use only one anchor ouput if we have something like rbf-package relay
14:21 < BlueMatt> ariard: well, at the risk of getting into it pre-meeting here, I dont think full-rbf buys you anything when you still have to meet min-additional-relay fees, but also the carve-out was cause of package size limits, not package relay
14:21 < BlueMatt> but, anyway, we should discuss it at your meeting!
14:21 < t-bast> It's going to be interesting and a good opportunity to dive into a few rabbit holes
14:22 < ariard> BlueMatt: to meet min-additional-relay fees you attach a cpfp and propagate as package? yeah for sure let's talk about it latter :)
14:22 < BlueMatt> ariard: also package limits, but, yes, ok :)
14:23 < cdecker> Definitely an interesting space I don't know much about, looking forward to the discussions ^^
14:23 < cdecker> Anyway, got to go pretty soon
14:24 < ariard> BlueMatt: i see package limits we might be willingly to bump them for op_ctv-style congestion tree, that kind of more advanced protocols
14:24 < t-bast> Same for me, I'll have to drop off soon
14:24 < t-bast> Thanks for your time everyone!
14:24 < t-bast> #stopmeeting
14:24 < ariard> t-bast: thanks for chairing!
14:24 < t-bast> #endmeeting
14:24 < lndev-bot> Meeting ended Mon Apr 26 21:24:41 2021 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
14:24 < lndev-bot> Minutes:        https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-04-26-20.17.html
14:24 < lndev-bot> Minutes (text): https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-04-26-20.17.txt
14:24 < lndev-bot> Log:            https://lightningd.github.io/meetings/ln_spec_meeting/2021/ln_spec_meeting.2021-04-26-20.17.log.html
14:24 < cdecker> Thanks everyone for the feedback on #854 ^^
14:25 < unixb0y> Any news on #798? 🤔
14:25 < t-bast> Let's keep the discussions going on the PRs
14:26 < vincenzopalazzo> Thanks guys, have a nice day/night :)
14:26 < t-bast> Have a nice week everyone!
14:26 -!- t-bast [~t-bast@2a01:e0a:156:8800:5c70:c837:eae:c90f] has quit [Quit: Leaving]
14:31 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 252 seconds]
14:31 -!- unixb0y [~unixb0y@p200300c6bf2c6447992d8b285ce07e0f.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
14:47 -!- jarthur_ [~jarthur@2603-8080-1540-002d-4c85-5ce3-cfa7-4f0f.res6.spectrum.com] has joined #lightning-dev
14:48 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
14:51 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Read error: Connection reset by peer]
14:53 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
15:07 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
15:10 -!- jarthur_ [~jarthur@2603-8080-1540-002d-4c85-5ce3-cfa7-4f0f.res6.spectrum.com] has quit [Quit: jarthur_]
15:10 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has quit [Ping timeout: 240 seconds]
15:16 -!- jarthur_ [~jarthur@2603-8080-1540-002d-4c85-5ce3-cfa7-4f0f.res6.spectrum.com] has joined #lightning-dev
15:24 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has quit [Ping timeout: 265 seconds]
15:25 -!- jeremyrubin [~jr@024-176-247-182.res.spectrum.com] has joined #lightning-dev
15:46 -!- jarthur_ is now known as jarthur
15:58 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
15:59 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
16:11 -!- gleb [~gleb@178.150.137.228] has quit [Quit: Ping timeout (120 seconds)]
16:11 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
16:12 -!- gleb [~gleb@178.150.137.228] has joined #lightning-dev
16:13 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
16:28 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has quit [Quit: Leaving]
16:41 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
16:42 -!- shesek [~shesek@164.90.217.137] has joined #lightning-dev
16:42 -!- shesek [~shesek@164.90.217.137] has quit [Changing host]
16:42 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
16:43 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
16:46 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 268 seconds]
17:02 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev
17:02 -!- vincenzopalazzo [~vincenzop@host-79-18-34-139.retail.telecomitalia.it] has quit [Remote host closed the connection]
17:04 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
17:08 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
17:10 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 268 seconds]
17:12 -!- belcher_ is now known as belcher
17:24 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:38 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
17:47 -!- proofofkeags [~proofofke@205.209.28.54] has quit [Ping timeout: 252 seconds]
17:51 -!- jarthur [~jarthur@2603-8080-1540-002d-4c85-5ce3-cfa7-4f0f.res6.spectrum.com] has quit [Quit: jarthur]
17:58 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
18:04 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
18:04 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
18:04 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
18:06 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #lightning-dev
18:07 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
18:21 -!- musdom [~Thunderbi@202.184.3.8] has quit [Quit: musdom]
18:22 -!- musdom1 [~Thunderbi@202.184.3.8] has joined #lightning-dev
18:24 -!- musdom1 is now known as musdom
18:54 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
18:55 -!- CubicEarth [~CubicEart@c-67-168-1-172.hsd1.wa.comcast.net] has joined #lightning-dev
18:57 -!- proofofkeags [~proofofke@97-118-239-55.hlrn.qwest.net] has joined #lightning-dev
19:08 -!- jarthur [~jarthur@2603-8080-1540-002d-4c85-5ce3-cfa7-4f0f.res6.spectrum.com] has joined #lightning-dev
19:37 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
19:37 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
19:40 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Read error: Connection reset by peer]
19:40 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
19:40 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 265 seconds]
19:42 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
19:44 -!- lndev-bot` [~docker-me@243.86.254.84.ftth.as8758.net] has joined #lightning-dev
19:44 -!- lndev-bot [~docker-me@243.86.254.84.ftth.as8758.net] has quit [Read error: Connection reset by peer]
19:46 -!- mol [~mol@unaffiliated/molly] has quit [Read error: Connection reset by peer]
19:46 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
19:55 -!- musdom [~Thunderbi@202.184.3.8] has quit [Ping timeout: 260 seconds]
20:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
20:29 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
20:29 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
20:30 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection]
20:32 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
20:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds]
21:39 -!- gleb [~gleb@178.150.137.228] has quit [Quit: Ping timeout (120 seconds)]
21:39 -!- gleb [~gleb@178.150.137.228] has joined #lightning-dev
22:11 -!- Xaldafax [~Xaldafax@cpe-198-72-160-101.socal.res.rr.com] has quit [Quit: Bye...]
22:22 -!- musdom [~Thunderbi@202.184.3.8] has joined #lightning-dev
22:35 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 240 seconds]
22:40 -!- jarthur [~jarthur@2603-8080-1540-002d-4c85-5ce3-cfa7-4f0f.res6.spectrum.com] has quit [Quit: jarthur]
22:40 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
22:42 -!- smartineng [~Icedove@88.135.18.171] has joined #lightning-dev
22:42 -!- smartineng [~Icedove@88.135.18.171] has quit [Excess Flood]
22:44 -!- smartineng [~Icedove@88.135.18.171] has joined #lightning-dev
22:50 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
22:54 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
22:59 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
23:03 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
23:10 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
23:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 252 seconds]
23:15 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
23:43 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Quit: Leaving]
23:43 -!- joost__ [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Quit: Leaving]
23:53 -!- t-bast [~t-bast@2a01:e0a:156:8800:5c70:c837:eae:c90f] has joined #lightning-dev
23:53 -!- t-bast [~t-bast@2a01:e0a:156:8800:5c70:c837:eae:c90f] has quit [Client Quit]
23:53 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
23:56 -!- kareninsf[m] [kareninsfm@gateway/shell/matrix.org/x-rgzuxlowyfwtjgck] has joined #lightning-dev
--- Log closed Tue Apr 27 00:00:38 2021