--- Log opened Mon Dec 07 00:00:38 2020
00:11 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
00:11 -!- lndbot [~lndbot@138.197.213.35] has quit [Remote host closed the connection]
00:14 -!- lndbot [~lndbot@138.197.213.35] has joined #lightning-dev
00:15 -!- lndbot2 [~lndbot@138.197.213.35] has joined #lightning-dev
00:15 -!- warren [~warren@fedora/wombat/warren] has quit [Ping timeout: 256 seconds]
00:16 -!- lndbot [~lndbot@138.197.213.35] has quit [Read error: Connection reset by peer]
00:20 -!- warren [~warren@fedora/wombat/warren] has joined #lightning-dev
00:23 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
00:27 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
00:28 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]
00:40 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
01:00 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
01:04 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
01:06 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
01:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
01:44 -!- Pavlenex [~Thunderbi@178.220.68.122] has joined #lightning-dev
01:52 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
02:00 -!- laptop [~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev
02:04 -!- kexkey [~kexkey@static-198-54-132-157.cust.tzulo.com] has quit [Ping timeout: 260 seconds]
02:06 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
02:07 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Remote host closed the connection]
02:16 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev
02:19 -!- greypw [~greypw@unaffiliated/greypw] has quit [Quit: I'll be back!]
02:20 -!- greypw [~greypw@unaffiliated/greypw] has joined #lightning-dev
02:21 -!- greypw [~greypw@unaffiliated/greypw] has quit [Client Quit]
02:23 -!- greypw [~greypw@unaffiliated/greypw] has joined #lightning-dev
02:34 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has joined #lightning-dev
02:37 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
03:01 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:10 -!- nobody123 [~nobody123@213.153.86.159] has quit [Remote host closed the connection]
03:11 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
03:14 -!- nobody123 [~nobody123@213.153.86.159] has quit [Read error: No route to host]
03:14 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
03:27 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has joined #lightning-dev
03:41 -!- laptop [~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com] has quit [Read error: Connection reset by peer]
03:41 -!- laptop [~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev
03:48 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
03:50 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has joined #lightning-dev
03:59 -!- Pavlenex [~Thunderbi@178.220.68.122] has quit [Quit: Pavlenex]
04:17 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
04:23 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
04:40 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #lightning-dev
04:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
04:50 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Quit: Pavlenex]
04:51 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
05:13 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Quit: No Ping reply in 180 seconds.]
05:14 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev
05:31 -!- nobody123 [~nobody123@213.153.86.159] has quit [Remote host closed the connection]
05:31 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
05:35 -!- nobody123 [~nobody123@213.153.86.159] has quit [Ping timeout: 246 seconds]
05:37 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Quit: ZNC - http://znc.in]
05:46 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
05:49 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
05:58 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
06:28 -!- nobody123 [~nobody123@213.153.86.159] has quit [Remote host closed the connection]
06:29 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
06:30 -!- nobody12_ [~nobody123@213.153.86.159] has joined #lightning-dev
06:30 -!- nobody123 [~nobody123@213.153.86.159] has quit [Read error: Connection reset by peer]
06:44 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has joined #lightning-dev
07:16 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #lightning-dev
07:17 -!- nobody12_ [~nobody123@213.153.86.159] has quit [Remote host closed the connection]
07:17 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
07:21 -!- prayank [~andr0irc@2409:4053:2e13:900f:d41e:b11b:ed95:2493] has joined #lightning-dev
07:22 -!- nobody123 [~nobody123@213.153.86.159] has quit [Ping timeout: 256 seconds]
07:26 -!- greypw [~greypw@unaffiliated/greypw] has quit [Quit: I'll be back!]
07:28 -!- greypw [~greypw@unaffiliated/greypw] has joined #lightning-dev
07:38 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:5081:c991:1e35:d185] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
07:42 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #lightning-dev
07:59 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Quit: Leaving]
07:59 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev
08:06 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev
08:08 -!- kexkey [~kexkey@static-198-54-132-157.cust.tzulo.com] has joined #lightning-dev
08:09 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
08:13 -!- belcher_ is now known as belcher
08:14 -!- proofofkeags [~proofofke@174-16-212-53.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
08:40 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
08:45 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev
08:47 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 272 seconds]
08:55 -!- belcher_ is now known as belcher
09:00 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
09:30 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 265 seconds]
09:32 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection]
09:32 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
09:35 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev
09:37 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
09:48 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
09:49 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Quit: Pavlenex]
09:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
10:09 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
10:12 -!- prayank [~andr0irc@2409:4053:2e13:900f:d41e:b11b:ed95:2493] has quit [Ping timeout: 260 seconds]
10:14 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 246 seconds]
10:16 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
10:27 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined #lightning-dev
10:30 -!- ja [janus@anubis.0x90.dk] has joined #lightning-dev
10:42 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds]
10:48 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev
10:52 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
10:52 < lnd-bot> [lightning-rfc] t-bast merged pull request #803: Require to claim revoked local output in its own penalty tx post-anchor (master...2020-10-no-aggregation-post-anchor) https://github.com/lightningnetwork/lightning-rfc/pull/803
10:52 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
10:52 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
10:52 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/920e51986d65...01b56742deb3
10:52 < lnd-bot> lightning-rfc/master 01b5674 Antoine Riard: Require to claim revoked local output in its own penalty tx post-anchor (#...
10:52 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
10:58 -!- bmancini55 [46200586@70.32.5.134] has joined #lightning-dev
10:59 < cdecker> Good evening :-)
10:59 < ariard> cdecker: hello :)
11:00 < t-bast> Good morning!
11:01 < t-bast> If someone can double-check the tx size calculation in #815 to ensure I didn't miss anything, we'll be able to merge this PR before we start the meeting :)
11:02 < cdecker> Currently don't have the source handy
11:03 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #lightning-dev
11:03 < bitconner> howdy!
11:03 < niftynei> hi hi hi
11:05 < cdecker> Heia
11:06 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
11:06 < t-bast> I put a tentative agenda here: https://github.com/lightningnetwork/lightning-rfc/issues/821, for once we don't have many PRs to bikeshed!
11:06 < dr-orlovsky> Will we have a dev meeting today? Does Rusty's new Offers/invoices proposals is un the agenda?
11:06 < dr-orlovsky> perfect, thanks
11:07 < t-bast> dr-orlovsky: yes it is, but I don't see rusty in the room yet
11:07 < ariard> bitconner: I'm finalizing the security.md but it sounds your pgp key is expired 2020-09-13?
11:07 < ariard> at least as display by gpg keyring
11:07 < cdecker> Rusty is unable to join today, sadly
11:07 < t-bast> ok, so I'm not sure we'll discuss offers if rusty isn't there
11:08 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Remote host closed the connection]
11:08 < cdecker> Probably best to wait for next time, it's his baby :-)
11:08 < t-bast> Shall we start?
11:08 < t-bast> #startmeeting
11:08 < t-bast> Bot still not back xD
11:08 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
11:08 < t-bast> I'll copy-paste my output to the github issue
11:08 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/821
11:09 < t-bast> Let's discuss gossip queries first
11:09 < bitconner> ariard: i think you have an outdated version of my key, the current expiration is 2021-09-13
11:09 < t-bast> #topic gossip queries (slightly) revisited
11:09 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/804
11:09 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/811
11:09 < bitconner> i will email to you
11:09 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Remote host closed the connection]
11:10 < ariard> bitconner: I'm talking about the security@lightning.engineering one, fingerprint: 91FE464CD75101DA6B6BAB60555C6465E5BCB3AF, as linked also in your README
11:10 < cdecker> bitconner, are you rotating or modifying the expiry? I just extended the expiry of mine last week, but was unsure what is better
11:10 < ariard> bitconner: thanks :)
11:11 < t-bast> This revisits the discussion we had about splitting blocks in multiple replies or not. We chose to *not* split, which made it easier to know when sync ended.
11:11 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has joined #lightning-dev
11:11 < t-bast> But it would probably be nice(r) to allow splitting blocks, but needs an explicit signal for end of sync.
11:11 < t-bast> My personal choice would be to add an explicit bool field to say "this is the end of my gossip" and allow splitting
11:11 < bitconner> ariard: ah okay, will ping roasbeef
11:12 < t-bast> WDYT?
11:12 < bitconner> cdecker: yeah i extended mine this summer :)
11:12 < cdecker> Well, the complete flag was supposed to be something like that and we all interpreted it differently, didn't we?
11:13 <+roasbeef> complete flag absically isn't used rn 
11:13 < t-bast> yes and that's a shame, TBH the complete flag as is interpreted right now is a bit useless IMO
11:13 < cdecker> Exactly, we better call it FIN this time :-)
11:13 < bitconner> i think only lnd used it as an EOF, but agree i'd like to see an explicit signal
11:13 < cdecker> At least that has a specific meaning in networking streams :-)
11:14 <+roasbeef> latest version of lnd basically never interprets the value 
11:14 < bitconner> fin of file :)
11:14 < bitconner> i think we do for backcompat with our older nodes
11:14 < niftynei> 🐟
11:14 < bitconner> though there shouldn't be many of those now...
11:15 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 272 seconds]
11:15 < t-bast> to be safe, we can use a new field, that's easy with tlv
11:15 < cdecker> Right
11:15 < t-bast> I can draft a spec PR to add that new field and allow splitting blocks
11:15 <+roasbeef> new field for?
11:15 < t-bast> roasbeef: for FIN
11:16 < t-bast> that we would all interpret as an EOF this time :)
11:16 < bitconner> could we not just reuse the useless field?
11:16 <+roasbeef> why do we need that? since you can just tell if they are done based on the block values 
11:16 < t-bast> from eclair's point of view, we can re-use complete, it's ignored right now
11:16 < t-bast> roasbeef: no you can't if you allow splitting a block in multiple replies
11:16 < bitconner> easy for us, we can just revert the changes to make it full_information
11:16 <+roasbeef> for the last chunk only? 
11:16 < bitconner> that made it*
11:17 < t-bast> yes, only for the last chunk, so it could be okay, but if we can make it better for almost no cost, why not? :)
11:17 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Quit: Pavlenex]
11:17 < cdecker> We seem to be still checking the complete flag
11:17 < t-bast> c-lightning and rust-lightning, what's your current interpretation of the complete/full_information field? Is it ok if we re-purpose it?
11:18 < t-bast> cdecker: but how do you react to its value?
11:18 < cdecker> Oh, wait no, I mixed up the code paths
11:18 < bitconner> cdecker: iirc rusty said you look at it bc lnd split across blocks and that it was for lnd compat
11:19 < t-bast> if you already interpret it as an EOF, then it's great, let's make it official :D
11:19 < cdecker> I don't think we do, otherwise we'd get a conflict with lnd
11:20 < ariard> t-bast: we evaluate it as an error and stop sync with peer
11:20 < ariard> so yeah EOF for us is fine
11:21 < t-bast> hum unfortunately we always set it to `1` by default to say "yes we have full information"
11:22 < cdecker> EOF was how we used to interpret it iirc
11:22 < t-bast> but since we don't split blocks it should be ok
11:22 < cdecker> Ok, just checked: we don't use complete anywhere significate
11:23 < cdecker> s/significate/significant/
11:23 < t-bast> Ok great, I'll submit a PR to repurpose it (again, hopefully for the last time!)
11:23 < bitconner> might be something that we have to roll out progressively
11:23 < t-bast> #action t-bast to submit PR to fix #804
11:24 < cdecker> ack
11:24 < t-bast> bitconner: if you don't split blocks when replying and set this value to true, then the migration should work fine; I'll detail this in my PR
11:24 <+roasbeef> lnd 0.12 will no longer split on blocks 
11:24 < t-bast> :+1:
11:24 < bitconner> 1) receiver-side interpretation, 2) set correctly on sender-side, 3) allow block splitting
11:24 <+roasbeef> seems th worst case w/e the complete flag is you just end up needing to repeat your last query tho/ 
11:24 <+roasbeef> like the final block range right? 
11:25 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #lightning-dev
11:25 < t-bast> bitconner: oh right, yeah I agree for that kind of rollout
11:25 < bitconner> or you end after receiving the first reply
11:25 < bitconner> if e.g. complete is always 1
11:25 <+roasbeef> also are we anywhere close to the 8k chans in a single block limit? I would think that'd require nodes to cooperate to make a single transaction to exist, not facotring in anything else that may be in the block 
11:26 < t-bast> bmancini55, could you tell us a bit more about #811?
11:26 < cdecker> The main problem with not knowing when you are complete is that you are only allowed one concurrent query, so asking too early means you might get dropped
11:26 <+roasbeef> fwiw lnd already still sets the complete bit/flag as well 
11:27 <+roasbeef> since we left it in place for older nodes before we stopped relying on it ourselves to know when the other side had stopped 
11:27 < cdecker> Yeah, we set it, but ignore it on the read-path
11:27 < ariard> t-bast: IIRC the issue described by Brian is that rn you don't have a way to opt-out from zlib support
11:27 < bitconner> in 0.12 we added logic to send back shuffle(channels)[:chunkSize] when there are do many for a single reply, that way there is probabilistic propagation for those channels
11:28 < t-bast> ariard: that's my understanding as well, the issue is that the sender (who sends query_channel_range) decides on the encoding the response should use, and you're unable to tell it beforehand that you don't handle zlib?
11:28 < bitconner> probably a good recommendation to make in the spec if people stick to no-block-splitting
11:29 -!- Pavlenex [~Thunderbi@185.244.212.67] has quit [Client Quit]
11:29 < bitconner> we could remove zlib :)
11:29 < ariard> t-bast: yes and thus you have to uselessly initiate syncing with zlib-support-only peers when you're only interested with raw-support peers
11:30 < bitconner> t-bast: wdym by don't support zlib? receivers are required to understand both
11:30 <+roasbeef> this is related to #804 in a sense, re possilby going over the boundary 
11:31 <+roasbeef> lnd can unpack zlib, but doesn't pack iirc, we opposed addition of it from teh start, but others wanted to save that couple of RTTs or w/e it was at that time, I don't think we're any where close to having 8k channels in a block as well 
11:31 < t-bast> bitconner: rust-lightning doesn't want to support zlib, and they have no way of communicating that so when a node sends them a query_channel_range asking for zlib encoding, their only choice is to drop the connection IIUC
11:32 < bitconner> t-bast: that's why we argued to make zlib gated by a feature bit from the start :)
11:32 < bitconner> but that ship has sailed lol
11:32 < t-bast> I'd need to check the actual data (since our node servers a lot of gossip queries to mobile wallets) to see if it's useful or not
11:33 < t-bast> As for gating it via a feature bit, do you remember why this wasn't chosen?
11:33 < bitconner> i would not be opposed to removing zlib entirely
11:33 < bitconner> simplicity
11:33 <+roasbeef> I think there were oother concerns at the time elsewhere t-bast, since this was pretty early on and it was simple also 
11:33 < ariard> t-bast: your node server is sending the whole graph to your clients or you're selecting paths for them?
11:33 <+roasbeef> as before that we just sent the entire routing table upon connect lol 
11:34 < t-bast> yeah but it could really save bandwidth, which can be useful for nodes that have a lot of mobile wallets connecting to it, so I'll need to check, we may want to keep zlib in eclair...
11:34 < bitconner> i suppose it's not too late to create a option-no-zlib feature bit
11:34 < t-bast> ariard: depends on the wallet, phoenix doesn't need graph data, but eclair-mobile is a full lightning node
11:34 <+roasbeef> fwiw you can also cut down on bandwidth by just selecting a handfull of peers to "sync" from as lnd does 
11:34 < cdecker> t-bast: remember I had mentioned the incremental server-assisted sync? I have a working version of that if you're interested
11:34 < t-bast> I agree, we could add this new feature bit now
11:34 <+roasbeef> +1
11:35 < ariard> a option-no-zlib would solve the issue
11:35 < t-bast> roasbeef: that doesn't work when you're the one people chose to sync from :D
11:35 < cdecker> Only if you make it mandatory, which pretty much splits the network though
11:35 < t-bast> cdecker: I'm interested in that, please do share it :)
11:36 < cdecker> Need to finish it up, but it's coming along very nicely
11:36 < BlueMatt> cdecker: I presume its based on minisketch or similar?
11:36 <+roasbeef> server-assited? 
11:36 < t-bast> I don't think we'd need to make it mandatory, it's just that this way when connecting to nodes that don't support zlib, you ask them for unencoded data
11:36 < cdecker> Nope, it just orders gossip messages, and if you synced once you can tell us exactly when that was
11:36 < t-bast> *uncompressed
11:37 < cdecker> We can then compute an optimal set of messages to catch you up
11:37 < bitconner> eventually you would have to make it mandatory yeah
11:37 < cdecker> No need for set-reconciliation if you have a canonical order :-)
11:37 < BlueMatt> ah, ok, I mean I think there's a lot of room to redo query sync to make that possible in a general case
11:37 < ariard> so support of no-zlib signals "I reply with raw scids only"
11:37 < BlueMatt> instead of using a server.
11:38 < BlueMatt> eg using time-other-node-received instead of block heigh means its should work 95% of the time (instead of now, which may or may not even be close) and then minisketch or similar is a pretty quick pass to check.
11:38 < t-bast> ariard: exactly, it means you should only send me query_channel_range *without* zlib activated
11:38 < BlueMatt> but all of that is a lot more work than "ugh, no zlib"
11:38 < t-bast> true that, that's why we've been discussing better gossip for a while, but no-one dived into implementing it :)
11:39 < cdecker> Ok, let's bikeshed a flag to signal no-zlib first, and we can brainstorm other things later
11:39 < bitconner> imo option-no-zlib should be blue
11:39 < BlueMatt> right.
11:39 < t-bast> I can draft a PR for that as well, and we can discuss it on github and during next meeting?
11:39 < martindale> Red please
11:39 < t-bast> Purple. Definitely purple.
11:39 < ariard> t-bast: and it doesn't matter to have a optional/mandatory interpretation
11:40 < t-bast> #action t-bast draft a feature flag for zlib support PR
11:41 < t-bast> #topic DB export format
11:41 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/820
11:41 < cdecker> This is pretty much undoable if you ask me
11:42 < bitconner> fwiw a hacky way to do no-zlib today would be to look for mandatory DLP (since i think only lnd sets that) and we never send back zlib
11:42 < t-bast> Haha. I was about to say that key handling / derivation would probably be painful, but why undoable?
11:42 < BlueMatt> standard db of *what*?
11:42 <+roasbeef> it's possible, but could be hard to maintain compat between all the impls 
11:42 <+roasbeef> basically they want an exportable channel format 
11:42 < BlueMatt> standard db of channel data? yea, thats not nearly worth the amount of effort
11:42 <+roasbeef> that can be imported into anything else 
11:42 < cdecker> We cannot fully describe the entire schema of all implementations, so it'd have to be a subset. A subset means we'd need to have ways to rehydrate the remainder
11:42 < BlueMatt> right, what cdecker said.
11:42 < t-bast> cdecker: yeah I agree, painful
11:43 < t-bast> Other option is to wait for low fees and close your channels
11:43 <+roasbeef> great idea in the abstract, but will be hard to get right at the impl level, not to mention other impl level local priorities 
11:43 < t-bast> Re-open with a new implementation
11:43 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has joined #lightning-dev
11:43 < cdecker> It might be possible much much later, when development has settled down, and we happen to converge to a common schema, but right now it'd be very limiting for very little upside
11:43 < BlueMatt> so, seems there's broad agreement - just not practical, certainly not practical in the coming few years.
11:43 < cdecker> ack
11:43 < t-bast> Ok, I sense a strong no from everyone :)
11:43 < bitconner> it's probably easier for us to start from scratch and build one impl than to make dbs compatible with four existing impls
11:44 < BlueMatt> lol, probably indeed bitconner 
11:44 < t-bast> I'll answer on the issue.
11:44 <+roasbeef> ppl can start to dev it thesmevles ofc as well, doesn't neccsrily need to be something on the spec level until it gets some actual uptake 
11:44 <+roasbeef> lol
11:45 < t-bast> #action NACK the issue
11:45 < t-bast> #topic 1 sat/byte for second level HTLCS in anchors++
11:45 < t-bast> ariard I believe you added that one?
11:45 < bitconner> why not 0?
11:45 < cdecker> If it were a minimalistic approach like lnd's SCB then I could see it working, but a whole DB, no
11:45 < t-bast> as long as it's a constant value, we can pretty much put anything, can't we?
11:45 <+roasbeef> I just added this
11:46 -!- nobody123 [~nobody123@213.153.86.159] has quit [Remote host closed the connection]
11:46 <+roasbeef> we implemented a mitigation against the fee leak stuff 
11:46 <+roasbeef> but found it too restrictive in practice, like smaller channels could only have 4 outstanding htlcs, stuff like that 
11:46 -!- nobody123 [~nobody123@213.153.86.159] has joined #lightning-dev
11:46 <+roasbeef> so we've went ahead and implemented the variant of anchors that has 1 sat/byte at the second level 
11:46 < ariard> the only downside I can see is now you have to spend a bumping utxo?
11:46 < bitconner> roasbeef: we implemented 0
11:46 <+roasbeef> to force aggreegation and eliminate the vector 
11:46 <+roasbeef> err yeh 0 lol
11:47 <+roasbeef> this is also kinda nice as you can potentially salvage more of the htlc is you need to go on chain 
11:47 <+roasbeef> ariard: yeh that's the tradeoff, but lnd has a pretty good internal system for bumping/input aggregation 
11:47 < ariard> it's fairer for the channel initiator to not have to pay counterparty-initiated HTLCs at the price of increasing the average onchain price
11:47 <+roasbeef> and users could potentially use swap servies like Loop to swap out and anchor down in a single transaction 
11:47 <+roasbeef> ariard: well there's two things here: the htlc output, and the second levle feees 
11:48 <+roasbeef> initiator still pays for the htlc output, but the sender now doesn't pay for the second level fees until broadcast/timeout time 
11:48 < ariard> roasbeef: right the htlc output is still paid by channel initiator with your proposal?
11:48 < bitconner> on the commitment txn, yes
11:48 <+roasbeef> so we're looking at obtaining a new feature bit for this, and will likely just advertise this going forward, as we want to start to enable this by default
11:48 < t-bast> roasbeef: the swap-out + bump fee idea is interesting, you'd actually be paying off-chain for an on-chain RBF
11:49 <+roasbeef> t-bast: yeah, also a cool concept independently of this specific use case as well 
11:49 < ariard> it's increasing average price but as it's only sad scenario, i.e unilaterla onchain closing I think that's okay
11:49 < bitconner> ariard: wdym increasing price?
11:49 < t-bast> roasbeef: but that probably requires a protocol to exchange signatures and allow the swap server to attach an input...not sure how feasible it is in practice 
11:50 <+roasbeef> yeh if you need to swap, but i think many nodes that are routing have output sitting around just due to sweeping random things that go on chain 
11:50 < ariard> bitconner: previously the second-level HTLC transactions fees would have been paid from the funding output amount?
11:50 <+roasbeef> so we just want a bit allocated, and could potentially use a higher one 
11:50 < ariard> bitconner: i mean the htlc output
11:51 <+roasbeef> t-bast: not sure what you mean, ifyou impl swaps as Loop does, this is just the client sweeping that output and anchoring down in a single transacton 
11:51 < t-bast> I'm in favor of this, but that really needs a spec PR to ensure we use the same feature bit and constant feerate
11:51 -!- nobody123 [~nobody123@213.153.86.159] has quit [Ping timeout: 256 seconds]
11:51 < ariard> and if your input/output pair with outgoing amount is the same than htlc output you have to attach a bumping utxo to pay
11:51 < bitconner> ariard: the price is still the same, just comes from a different input, which is already the case bc of single/acp?
11:51 <+roasbeef> mhmm, we're planning on, but just want to flag that we'll likely move faster than the spec PR, tho the params are pretty consstrained 
11:51 < t-bast> roasbeef: oh ok, I think I see what you mean for the swap, I was thinking of something different then
11:51 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 272 seconds]
11:51 <+roasbeef> since from our pov, it's been so long and we're so close to getting this thing out 
11:52 < ariard> bitconner: yes and this different input wouldn't have been spent previously, I mean your transaction is bigger by one input?
11:52 < BlueMatt> given how many times anchor has been close and then ariard found some new critical-ish issue in it, lets make sure its all written out and there's more time to stare at it.
11:52 < t-bast> did you consider a constant feerate, but negotiated at channel_open time?
11:53 < bitconner> if you don't attach another input then the fees can be siphoned by anyone.. no? so wasn't that always a requirement?
11:53 < t-bast> because you still have the issue that it may end up below the min-relay-fee, don't you?
11:53 <+roasbeef> you still have the sighash all component bitconner 
11:53 <+roasbeef> t-bast: this forces aggregation and/or another input 
11:54 < t-bast> roasbeef: but without package relay, that won't work, will it?
11:54 < bitconner> ah right, only one of the signatures is single/acp
11:54 <+roasbeef> it will, since you always attach something 
11:54 <+roasbeef> it's your job to make sure that somethign gets propagated 
11:54 <+roasbeef> this isn't the commitment transaction with a clamed fee rate, it's the second level htlcs 
11:54 <+roasbeef> what fee rate the other party signs with 
11:54 < t-bast> oooh right
11:54 < t-bast> of course
11:55 < t-bast> you add inputs, my bad
11:55 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
11:55 < cdecker> Nice, sounds like yet another eltoo feature being backported :+1: 
11:55 <+roasbeef> yeh so you always add
11:55 <+roasbeef> hehe
11:56 < t-bast> but did you consider negotiating it during channel_open? This way if I want to set it to 5 sat/byte (but constant), it doesn't suffer from the issue ariard found and I may not need to attach a new input
11:56 < ariard> roasbeef: the sighash_single counterparty sign the second-level output amount with the same value than the htlc output ?
11:56 < bitconner> we chose with zero since it ensures there are no fees to siphon, any chosen constant still has wiggle room for games
11:56 <+roasbeef> t-bast: that still leaks _something_ tho fee wise 
11:56 <+roasbeef> may not need to attach, but  likely would in practice given time lock expiry constraints 
11:57 <+roasbeef> ariard: essentially yeh, so that input+output are "locked" 
11:57 < ariard> roasbeef: you will always need to attach otherwise you hit min-relay fee as raised by t-bast?
11:57 < bitconner> you also might overpay by 5x
11:57 < t-bast> ok got it, that's interesting
11:57 < ariard> I concede the attachment is probabilistic, like only if you need to broadcast the transaction
11:58 <+roasbeef> the change it's impl wise is pretty small, you just remove the "fee decrement" for this chan type 
11:58 < BlueMatt> it does kinda suck just in terms of how expensive it is to add the output
11:58 <+roasbeef> yeh so the "happy path" isn't impacted 
11:58 < BlueMatt> errr, input
11:58 <+roasbeef> BlueMatt: which output? 
11:58 < BlueMatt> but also maintain an output on chain
11:58 < t-bast> do you have anchor output channels in production you care about? if not that 0-fee on HTLC txs could be the default for anchor output channels, to avoid a compatbility matrix nightmare (once scrutinized and implemented)
11:58 <+roasbeef> ah to bump? yeh there's that 
11:59 < bitconner> this is the change: https://github.com/lightningnetwork/lnd/pull/4840/commits/af1fe6bebc6f4ec9fbc109b9c34d529dfa766ca1
11:59 < ariard> it's increasing the cost of the "sad path"
11:59 <+roasbeef> t-bast: hard to tell, but fwiw it's been a build/dev flag on lnd, so I think adding a new bit is a better path
11:59 < BlueMatt> by a nontrivial margin, too.
11:59 <+roasbeef> ehh disagre it always increases the sad path
11:59 < BlueMatt> though I dont know that I care, just pointing it out.
11:59 <+roasbeef> as you might have been overpaying before 
11:59 < BlueMatt> 1 sat/vbyte is never overpaying :p
11:59 <+roasbeef> and you'd likely want to bump/aggegrate anyway to accoutn for the timelock race on force close 
11:59 < t-bast> roasbeef: ok, and probably allows experimenting earlier, and we may later choose to force both feature bits to be mandatory if we want to remove some code
12:00 < cdecker> Sounds like exactly what the experimental high feature bits were introduced :-)
12:00 <+roasbeef> t-bast: mhmm, those that havne't deployed have the option to only signal this new bit as well fwiw, tho the gap between them is pretty small, and for lnd kinda doesn't matter in practice as we have generalized sweeping/aggregation engine internally 
12:01 <+roasbeef> cdecker: yep, so I think we may pick a high bit to start with, and then bank on something something dynamic commitments in the future to have things eventually be uniform
12:01 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined #lightning-dev
12:01 <+roasbeef> how close are others in enabeling anchors as their default chan type? 
12:01 < bitconner> there is also the matter of: if we have the safer format, do we allow creation of leaky-anchor channels
12:02 < cdecker> Yep, sounds like a plan. I'm curious to see these proposals in action
12:02 -!- laptop [~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com] has quit [Ping timeout: 240 seconds]
12:02 < cdecker> Ideally the lessons learned iterating should inform the golden anchor implementation I think
12:02 <+roasbeef> cdecker: +1
12:02 < t-bast> We've been lagging behind in eclair, we need to work on the whole RBF engine story. Got caught up working on Phoenix iOS, so it will take us a few more months before anchor outputs can safely be enabled.
12:02 < ariard> generally, the price "sad path" will have to increase if we're moving off from negotiated feerate (package relay future)
12:03 <+roasbeef> ariard: the price of the sad path is a function of the ctlv delta and on chain dynamics as well 
12:03 <+roasbeef> as you're usually force closing for a reason 
12:03 <+roasbeef> but ok, we'll put up the PR spec wise, and also pick a high bit for our own experimentation 
12:03 < ariard> roasbeef: functio nof the cltv delta ? how do this increase your feerate
12:04 < bitconner> if we want to make the sad path less costly we could also backport the eltoo txn structure, and remove those expensive outputs on the contested stae
12:04 <+roasbeef> i wonder if it's possible to add sparse bit encoding w/o adding a new init message as well...
12:04 < bitconner> state
12:04 <+roasbeef> ariard: if the delta is 2 blocks, you need to get into the chain within that delta or the timelock race starts 
12:04 <+roasbeef> if it's 1000 blocks, you have more time and can likely end up using a lower fee rate 
12:04 <+roasbeef> bitconner: yeh that "generalized channel" paper starts to go in that direction, soem cool ideas there 
12:04 < ariard> roasbeef: i see and you need to increase your feerate but it's already a higher level question that the fee model you're choosing
12:05 < t-bast> #action LL to create PR detailing the proposal and exposing an experimental feature bit for compat' testing
12:05 <+roasbeef> ref: https://eprint.iacr.org/2020/476
12:05 < ariard> bitconner: yeah I've a draft post to compare package-relay vs-eltoo+moar malleability, imo either would solve pinning
12:05 -!- laptop [~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev
12:05 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has quit [Changing host]
12:05 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #lightning-dev
12:05 < bitconner> nice, looking forward to it!
12:06 < cdecker> Absolutely
12:06 < bitconner> has CL deployed anchors?
12:06 < cdecker> We have an experimental implementation (behind compile guards), so we could test compat, but don't announce experimental things in the changelog
12:06 < ariard> roasbeef: what would be really cool is to cooperatively relax timelocks when the mempool is congestionned
12:07 < bitconner> if the peer is cooperative, why unilateral close?
12:07 <+roasbeef> ariard: that can be done w/o cooperation 
12:07 <+roasbeef> since you just update your CLTV delta in your direction 
12:07 < ariard> bitconner: it might disappear in the future when the mempool is still congestionned
12:07 < bitconner> gotcha
12:07 <+roasbeef> but that's a good idea also, possilbe today, impls just need to pick a heuristic
12:07 < bitconner> or maybe accidental close
12:08 < cdecker> Gotta run off in a couple, shall we address the last topic?
12:08 <+roasbeef> could also base it off past exp
12:08 <+roasbeef> ok what's next?
12:08 < ariard> roasbeef: I meaned the CLTV in the transaction but you need coordination on the whole path, not only the relay policy
12:08 -!- MrMa [92735271@146-115-82-113.s2410.c3-0.sbo-ubr1.sbo.ma.cable.rcncustomer.com] has joined #lightning-dev
12:08 < t-bast> Yes, let's quickly go throught the last item
12:08 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Quit: ZNC - http://znc.in]
12:08 < t-bast> #topic Channel backup revisited
12:08 < ariard> RL's anchor was pending on spec agreement on the fee leak issue 
12:08 < cdecker> Alternative backups
12:08 < t-bast> #link https://lists.linuxfoundation.org/pipermail/lightning-dev/2020-December/002907.html
12:08 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has joined #lightning-dev
12:08 <+roasbeef> ariard: the value in the transaction, is dervied off your routing channel policy tho? 
12:08 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has quit [Changing host]
12:08 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #lightning-dev
12:08 < t-bast> This proposal changes the funding tx script to make the remote funding pubkey determinisitc
12:09 < t-bast> That makes channel backups easier once you've only backed up your seed
12:09 <+roasbeef> interesting, haven't read the mail yet 
12:09 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Remote host closed the connection]
12:09 < bitconner> cdecker: got it thanks! for 0.12 lnd still needs to decide whether to allow leaky-anchors, but it sounds like we have some time before elcair and CL deploy in full
12:09 < cdecker> This proposal also makes use of the peer's willingness to act on our behalf (close the channel, correctly)
12:09 < t-bast> The main issue I see is that when you have multiple channels to a peer, you need a counter (argh)
12:09 < cdecker> I'm not sure we should encourage relying on the one node in the network that gains from stealing from us
12:09 <+roasbeef> how does this avoid re-use? 
12:09 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has joined #lightning-dev
12:09 <+roasbeef> cdecker: yeh nad we've tried to move away from that by doing static remote key 
12:09 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has quit [Remote host closed the connection]
12:10 < bitconner> ariard: 👍
12:10 < ariard> roasbeef: it's function ofc (i.e max_accepted_htlcs) but it would more a preventive measure to prevent massive channel closures due to nodes running off of bumping utxos
12:10 <+roasbeef> also this doesn't work for nodes that aren't advertised in the network 
12:10 < ariard> and thus closing before to being unable to confirm
12:10 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has joined #lightning-dev
12:11 -!- jonasschnelli [~jonasschn@static.239.36.216.95.clients.your-server.de] has quit [Changing host]
12:11 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #lightning-dev
12:11 <+roasbeef> also this still would rewuire you to somehow make the other side force close right? 
12:11 < cdecker> Jap
12:12 <+roasbeef> identifying the output is only half of the recovery scenario 
12:12 < cdecker> Recover, connect, signal, wait for close
12:12 < bitconner> it is kind of nice that you can just run through all public routing nodes and scan the chain..
12:13 < bitconner> even historical ones
12:13 < bitconner> you don't even really need a list of pubkeys
12:13 <+roasbeef> but it also forces re-use, and adds identifyign on chain information back to the LN layer 
12:13 <+roasbeef> so even unadvertised chanenls would easily be linked back to the nodes 
12:14 < t-bast> right, the right to forget when deleting a backup is actually a feature?
12:14 < bitconner> roasbeef: re-use?
12:14 <+roasbeef> it is a link level thing tho, so ppl can start to roll it out if they wanted with an exp feature bit 
12:14 <+roasbeef> bitconner: all my chanenls to you will use the same multi-sig keys, and have the same script hash 
12:14 < bitconner> there's a counter
12:15 <+roasbeef> now and also in the future
12:15 < bitconner> >  Of course, to open
12:15 < bitconner> multiple channels with the same node we would have to generate a new shared
12:15 < bitconner> secret from each one by hashing a counter.
12:15 < ariard> it's still stateful you have to remember the counter
12:15 < t-bast> yeah or brute-force the counter
12:15 <+roasbeef> so it's w/e counter state vs the SCB type format itself which is a few hundred bytes
12:15 < bitconner> yeah, but within the realm of brute forcability /shrug
12:16 < niftynei> my understanding is it makes brute-forcing a recovery within the realm of possible
12:16 <+roasbeef> I think it's also overlooking the on-chain brute force cost tho 
12:16 <+roasbeef> wihch can be prohbitive depending on node set up and age of chan kinda 
12:16 <+roasbeef> one Q that comes to mind also is how to sync the counter state and if that's needed 
12:17 <+roasbeef> so it can create a new look ahead gap in a sense 
12:17 <+roasbeef> if we start funding, then stop for w/e reason, and also how to deal with concucrrent funding attempts
12:17 < t-bast> there's something you can do with a cooperative peer: encrypt that counter and send it to him when you `revoke_and_ack`, and have him send it back in `channel_reestablish`
12:18 <+roasbeef> t-bast: iirc eclair does something liek this already right? 
12:18 -!- Pavlenex [~Thunderbi@185.244.212.67] has joined #lightning-dev
12:18 < t-bast> yes, we do that for phoenix: https://medium.com/@ACINQ/phoenix-wallet-part-3-backup-f63a9470d4e7
12:18 < ariard> t-bast: hmmmm counter is for channel opening ? why does it come at reestablishment, you assume knowledge of funding script at this phase?
12:19 < t-bast> ariard: it can simply prevent the brute-force step
12:19 < t-bast> ariard: but maybe it's not useful and brute-force is totally ok
12:19 < ariard> t-bast: add a new message "do-i-have-channel-with-you" ? information space is cheap
12:20 <+roasbeef> since chans made w/ unadvertised nodes aren't covered wtih this, it still kinda falls back to an SCB-like structure imo 
12:20 < cdecker> You mean "now-is-a-good-time-to-cheat-me-out-of-my-money" message :-)
12:20 <+roasbeef> kek
12:20 < t-bast> lol
12:20 <+roasbeef> something something watch towers 
12:20 < cdecker> "Please blackmail me" message
12:20 < bitconner> LOL
12:21 < niftynei> bahaha
12:21 <+roasbeef> --we-do-not-negotiate-with-terrorists=1
12:21 < ariard> cdecker: ahahah isn't already the assumption with DLP?
12:21 < bitconner> my sides
12:21 < niftynei> should probably add a "mercy" flag to that message lol
12:22 < cdecker> Hehe, and since it'd be unfair to keep that info private, let's add a "hey-i-restored-from-a-leaky-backup" flag in the node_announcement
12:22 < cdecker> So the whole world can have a laugh
12:22 < bitconner> roasbeef: yeah that's a good point, something like SCB will always be required for non-advertsided nodes
12:22 < t-bast> shame, shame, shame
12:23 < cdecker> But yeah, good point on non-public nodes
12:23 < niftynei> mmh sounds like this is 'an improvement for public nodes, doesn't help private channels'
12:23 <+roasbeef> niftynei: yeh, with caveats w.r.t concurrent funding and how to handle the "look ahead gap" when scanning on-chain 
12:23 <+roasbeef> look ahead gap meaning, when do I stop looking, as it's possilbe we skipped counter values due to failed funding 
12:23 < bitconner> yeah it's an improvement for public counterparties, but often public nodes have private counterparties so doesn't help public nodes all that much
12:24 < cdecker> The counter can also be replaced with something publicly known: blockheight or blockhash
12:24 < niftynei> ah yep. but it does create a 'bounded search space' for recovery
12:24 < cdecker> That way we always look +/-100 around the funding TX height and can derive the counter
12:24 < ariard> it's rate-limiting your channel opening per-block?
12:24 < bitconner> what happend to disseminating blockheight/hash in the ping msg :)
12:24 <+roasbeef> IIRC CL used to factor in teh node pubkey when deriving certain keys but removed that right? 
12:24 < cdecker> ariard: yep, but only per peer
12:25 < ariard> bitconner: like a lot of things, will happen in 2021 
12:25 < t-bast> we also mix in the funding key in our bip32 path for channel keys
12:25 < cdecker> roasbeef: key derivation still includes peer_id
12:25 < bitconner> ariard: as long as there's still space for my 4k videos
12:25 <+roasbeef> 2021 really has a lot riding on it...can we get the simulation back on track?!!
12:26 <+roasbeef> the aliens tried by giving us certain scientific discoveries, but my Divergence Meter is still off 
12:26 < cdecker> roasbeef: don't worry, I'm about to propose the OP_CORONA for even better off-chain contracts (touchless and all)
12:26 < ariard> bitconner: I don't guarantee about the dollar in 2021, but 4k in 2020 should still be 4k in 2021 :p
12:27 < niftynei> lol
12:27 < bitconner> please don't say the d word :)
12:27 <+roasbeef> https://steins-gate.fandom.com/wiki/Divergence_Meter ;)
12:28 < cdecker> Anywho, I gotta go. 'twas fun :-)
12:28 < t-bast> Alright guys, I gotta go, thanks for your time!
12:28 < t-bast> #endmeeting
12:28 < ja> t-bast: would it be possible to mark the topics as markdown sections? then it will be easier to read
12:28 < cdecker> Yep, great meeting everyone ^^
12:28 < niftynei> til next time
12:28 < ariard> yeah, see you on gh and elsewhere :)
12:28  * bitconner waves royally
12:29  * niftynei awkwardly high fives bitconners wave
12:30 < bitconner> bahaha 😂
12:30 -!- bmancini55 [46200586@70.32.5.134] has left #lightning-dev []
12:32 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
12:32 < lnd-bot> [lightning-rfc] t-bast merged pull request #815: Correct htlc witness size calculations (master...htlc-witness-size) https://github.com/lightningnetwork/lightning-rfc/pull/815
12:32 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
12:32 -!- lnd-bot [~lnd-bot@165.227.7.29] has joined #lightning-dev
12:32 < lnd-bot> [lightning-rfc] t-bast pushed 1 commit to master: https://github.com/lightningnetwork/lightning-rfc/compare/01b56742deb3...d0c83854de7e
12:32 < lnd-bot> lightning-rfc/master d0c8385 Johan T. Halseth: Correct htlc witness size calculations (#815)
12:33 -!- lnd-bot [~lnd-bot@165.227.7.29] has left #lightning-dev []
12:33 -!- t-bast [~t-bast@5.50.145.86] has quit [Quit: Leaving]
12:34 -!- joost_ [~joostjgr@81-207-149-246.fixed.kpn.net] has quit [Quit: Leaving]
12:38 -!- laptop [~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com] has quit [Ping timeout: 272 seconds]
12:40 -!- laptop [~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com] has joined #lightning-dev
13:12 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
13:19 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev
14:02 -!- Netsplit *.net <-> *.split quits: jesseposner, awesome_doge, midnight
14:23 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #lightning-dev
14:26 -!- zmnscpxj [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
14:30 -!- jesseposner [~jp@2601:643:8980:bfd2:1401:d5c:a187:3181] has joined #lightning-dev
14:33 -!- awesome_doge [awesome-do@gateway/shell/matrix.org/x-witaeypfsoxnjlkc] has joined #lightning-dev
14:54 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 265 seconds]
14:59 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Remote host closed the connection]
14:59 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
15:04 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 240 seconds]
15:07 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
15:07 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
15:12 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
15:21 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
15:41 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
16:03 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 260 seconds]
16:15 -!- jonatack [~jon@213.152.161.170] has quit [Quit: jonatack]
16:27 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has joined #lightning-dev
16:59 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
17:00 -!- laptop [~laptop@ppp-0-247.leed-a-2.dynamic.dsl.as9105.com] has quit [Ping timeout: 265 seconds]
17:12 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has quit [Ping timeout: 272 seconds]
17:12 -!- kabaum [~kabaum@h-13-35.A163.priv.bahnhof.se] has joined #lightning-dev
17:24 -!- tryphe_ is now known as tryphe
17:40 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has quit [Read error: Connection reset by peer]
17:41 -!- sr_gi [~sr_gi@80.174.218.168.dyn.user.ono.com] has joined #lightning-dev
17:43 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
18:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
18:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
18:08 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has quit [Quit: ZNC - http://znc.in]
18:08 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
18:09 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has joined #lightning-dev
18:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
18:12 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 240 seconds]
18:19 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:54a5:5132:6498:c2e9] has joined #lightning-dev
18:29 -!- IPGlider [~IPGlider@45.76.34.219] has quit [Ping timeout: 256 seconds]
18:33 -!- IPGlider [~IPGlider@45.76.34.219] has joined #lightning-dev
19:21 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
19:56 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
20:28 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev
20:30 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 246 seconds]
20:39 -!- nobody123 [~nobody123@dslb-094-216-007-055.094.216.pools.vodafone-ip.de] has joined #lightning-dev
20:44 -!- nobody123 [~nobody123@dslb-094-216-007-055.094.216.pools.vodafone-ip.de] has quit [Ping timeout: 256 seconds]
21:01 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:54a5:5132:6498:c2e9] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
21:23 -!- da39a3ee5e6b4b0d [~da39a3ee5@2403:6200:8876:a9cd:54a5:5132:6498:c2e9] has joined #lightning-dev
21:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
21:53 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
22:14 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
22:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]
22:32 -!- musdom [~Thunderbi@202.184.212.139] has joined #lightning-dev
22:50 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
22:50 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
22:51 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
22:56 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Read error: Connection reset by peer]
22:58 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
23:20 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
23:22 -!- jeremyrubin [~jr@c-73-15-215-148.hsd1.ca.comcast.net] has quit [Ping timeout: 256 seconds]
23:23 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
23:26 -!- jonasschnelli [~jonasschn@2a01:4f9:2a:2510::2] has quit [Changing host]
23:26 -!- jonasschnelli [~jonasschn@unaffiliated/jonasschnelli] has joined #lightning-dev
23:53 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
23:54 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
--- Log closed Tue Dec 08 00:00:14 2020