--- Log opened Mon Jun 08 00:00:44 2020
00:38 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 246 seconds]
00:45 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
00:55 -!- yzernik_ [~yzernik@2600:1700:dc40:3dd0:a852:dcf8:562d:bad2] has joined #lightning-dev
00:56 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Read error: Connection reset by peer]
01:07 -!- jonatack_ [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Quit: jonatack_]
01:13 -!- pretyflaco [~k3m@77.243.183.203] has quit [Ping timeout: 256 seconds]
01:13 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
01:23 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #lightning-dev
01:27 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev
01:27 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
01:30 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 240 seconds]
01:31 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
01:31 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
01:39 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev
01:40 -!- yzernik_ [~yzernik@2600:1700:dc40:3dd0:a852:dcf8:562d:bad2] has quit [Ping timeout: 272 seconds]
01:42 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
01:49 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 246 seconds]
01:49 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has joined #lightning-dev
02:03 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
02:43 -!- yzernik [~yzernik@75-25-138-252.lightspeed.plalca.sbcglobal.net] has quit [Ping timeout: 264 seconds]
03:25 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
03:28 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Client Quit]
03:33 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
04:03 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
04:13 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
04:13 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
04:19 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Remote host closed the connection]
04:22 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
04:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
04:29 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Quit: __gotcha]
04:30 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
04:34 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 258 seconds]
04:48 -!- gojiHmPFPN [~textual@c-73-47-220-190.hsd1.ma.comcast.net] has joined #lightning-dev
04:50 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
04:55 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
05:06 -!- shesek [~shesek@5.102.222.33] has joined #lightning-dev
05:06 -!- shesek [~shesek@5.102.222.33] has quit [Changing host]
05:06 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
05:06 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
05:10 -!- bauerj [~bauerj@unaffiliated/bauerj] has quit [Quit: "Die Bauers, die können's einfach!"]
05:11 -!- bauerj [~bauerj@unaffiliated/bauerj] has joined #lightning-dev
05:35 -!- dr-orlovsky [~Dr_Orlovs@31.14.40.19] has quit [Ping timeout: 265 seconds]
05:46 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
06:01 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
06:09 -!- pretyflaco [~k3m@185.213.155.177] has joined #lightning-dev
06:10 -!- shesek [~shesek@5.102.222.33] has joined #lightning-dev
06:10 -!- shesek [~shesek@5.102.222.33] has quit [Changing host]
06:10 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
06:15 -!- pretyflaco [~k3m@185.213.155.177] has quit [Ping timeout: 260 seconds]
06:28 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
06:35 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
06:38 -!- molz_ [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
06:46 -!- dr-orlovsky [~Dr_Orlovs@31.14.40.19] has joined #lightning-dev
06:48 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
06:49 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 256 seconds]
06:51 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 260 seconds]
06:55 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
07:00 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 258 seconds]
07:05 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #lightning-dev
07:06 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
07:10 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 260 seconds]
07:13 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Read error: Connection reset by peer]
07:13 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev
07:19 -!- Amperture [~amp@65.79.129.113] has joined #lightning-dev
07:22 -!- Amperture [~amp@65.79.129.113] has quit [Client Quit]
07:36 -!- slivera [~slivera@103.231.88.26] has quit [Remote host closed the connection]
07:52 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
07:56 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Remote host closed the connection]
07:57 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #lightning-dev
07:57 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 260 seconds]
08:01 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Ping timeout: 246 seconds]
08:09 -!- pretyflaco [~k3m@185.213.155.168] has joined #lightning-dev
08:18 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
08:23 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
08:28 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 264 seconds]
08:31 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
08:34 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
08:39 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 264 seconds]
08:42 -!- rorp [43a994bd@c-67-169-148-189.hsd1.ca.comcast.net] has joined #lightning-dev
08:44 -!- rorp [43a994bd@c-67-169-148-189.hsd1.ca.comcast.net] has quit [Remote host closed the connection]
08:51 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds]
09:12 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
09:14 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
09:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
09:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
09:23 -!- vasild_ is now known as vasild
09:35 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has quit [Ping timeout: 246 seconds]
09:37 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
09:49 -!- fkinglag [~fkinglag@unaffiliated/fkinglag] has joined #lightning-dev
09:50 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 260 seconds]
09:57 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
10:02 -!- mol_ [~mol@unaffiliated/molly] has joined #lightning-dev
10:04 -!- zmnscpxj__ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
10:05 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 264 seconds]
10:12 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
10:12 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
10:17 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 256 seconds]
10:19 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
10:24 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 264 seconds]
10:28 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
10:40 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
10:44 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 260 seconds]
10:50 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
10:55 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 256 seconds]
10:57 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
11:05 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
11:07 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
11:08 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
11:10 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 264 seconds]
11:12 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 240 seconds]
11:25 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 272 seconds]
11:26 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
11:30 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 264 seconds]
11:36 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
11:40 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 240 seconds]
11:41 -!- molz_ [~mol@unaffiliated/molly] has joined #lightning-dev
11:44 -!- mol_ [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
11:55 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
12:13 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
12:28 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
12:28 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
12:32 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
12:33 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 258 seconds]
12:34 -!- t-bast [~t-bast@2a01:e34:efde:97d0:a0dd:b1dd:ac09:d724] has joined #lightning-dev
12:55 -!- rorp [68fe5c3e@104.254.92.62] has joined #lightning-dev
12:58  * t-bast waves at the crowd (anybody there?)
12:59 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
12:59 < rusty> Hello everyone!
13:00 < t-bast> hey rusty!
13:01 < t-bast> what's happening in c-lightning nowadays? I'm seeing some hsmd work?
13:01 < cdecker> Hey everyone ^^
13:01 < niftynei> hi hi
13:02 < rusty> t-bast: I don't know, I've been (re-)writing protocol tests.  Hope to make some noise about it this week!
13:02 < t-bast> rusty: nice, good thing to get rebooted!
13:02 < t-bast> hey cdecker, niftynei
13:02 < cdecker> t-bast: loads of long overdue refactoring, should be good soon
13:03 < t-bast> it sounds like we're all consolidating/refactoring/preparing for the next wave
13:03 < rusty> t-bast: yeah, tomorrow I have got some time with a Python consultant to go through the code, since it's on the edge of my Python knowledge...  But it
13:04 < rusty> 's pretty exciting stuff.
13:05 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
13:05 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
13:05 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
13:05 < BlueMatt> rusty: I presume it does a bunch of tests around async message deliver
13:05 < BlueMatt> y?
13:05 < ariard> hi folks
13:05 < cdecker> Heya ^^
13:05  * t-bast waves at ariard and BlueMatt
13:06 < BlueMatt> (we'll have pythong bindngs for the lib soonish, so should be super easy to add us for testing :) )
13:06 < rusty> BlueMatt: yeah, you basically create a DAG of possible event paths, like "send this msg, expect this msg", then it runs through all of them.
13:06 < BlueMatt> cool!
13:06 < cdecker> ariard: sorry for the very direct answer to #783, hope it didn't come across too aggressive
13:07 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
13:07 < rusty> The original one used a DSL and had a heap of hard-coded stuff, so you really had to completely control waht your node did.  This one calcs much more stuff on the fly, so it's more flexible.
13:07 < ariard> cdecker: not at all feeled as aggressive :) It's hard to be right or wrong on this subject, there is a lot of factors to account
13:08 < cdecker> Thanks, it's sometimes hard to gauge the tone in writing, and I felt that my post could come across as too direct, so just wanted to say sorry if that'd be the case ^^
13:09 < cdecker> (also being hyped on coffee doesn't help ^^)
13:09 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
13:10 < ariard> I was answering you, but I think people would be okay to talk about engineering cost and trade-off of solution directly during meeting
13:10 < t-bast> I think it's good, it fuels the discussion for tonight
13:10 < t-bast> we don't have a huge schedule so we can start with those
13:11 < ariard> in fact if you know anyone willingly to do more research on inter-layer probing or transposing some of transaction origin inferrence tricks on LN that would awesome
13:12 < cdecker> Well, the academics are currently still catching up with stuff we knew years ago ;-p
13:12 < BlueMatt> cdecker: fwiw, I think part of the motivation of ariard (and my) concern here is that, historically, there have been a ton of issues around being able to prevent tx relay for txn that you see first. and I'm not at all confident that such bugs dont still exist.
13:12 < cdecker> It'll take some time for them to catch up with the really interesting things at the cutting edge. while they collect the low-hanging fruits
13:12 < BlueMatt> I dunno if "core bugs" is in the domain of things we should be worried about, but "likely core bugs" maybe is.
13:13  * BlueMatt also notes that, in the long term, I hope we all aggree that we cannot rely on mempool scanning for our security, and maybe the most worrying thing for me is that we don't have a currently-viable proposal to get there
13:13 < ariard> cdecker: yes but if we can help them on researching the actual stuff we need to know to shed lights that's worthy talking with them
13:13 < cdecker> BlueMatt: there are some things in Core that do have an impact on us (mempool logic first and foremost), so I think it is very much in scope, but at the same time out of reach
13:14 < BlueMatt> (I have some vague intuition that sighash_noinput may be part of the solution, but its only an intuition)
13:14 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
13:14 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
13:14 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
13:14 < cdecker> So we're left with trying to fill in the gaps that we discover, and this is one of those venues imho
13:14 < BlueMatt> right.
13:14 < ariard> due to base layer being p2p and not having a concept of first-seen tx, you will always have conflicts and those will be always leveragable
13:14 < cdecker> Bitcoin propagation logic could be abused to hide information from us? Let's make sure that that information gets broadcast
13:15 < BlueMatt> but also requiring mempool scanning means, to run a lightning node you *must* either run bitcoind or have a bitcoind you can query (possibly over rest or remote)
13:15 < ariard> that's right you can improve propagation logic, but how do you avoid this turning as a DoS or privacy leak
13:15 < cdecker> BlueMatt: and many nodes will use `bitcoind` as their backend, but they can help those who can't by making that information available
13:16 < ariard> cdecker: have you read other issue on mempool-pinning on the commitment tx-level ? You may have to bump something you don't know and that maybe a moving target
13:16 < cdecker> DoS: sending a preimage is not free, it requires a channel to exist and the close to have an appropriate htlc output. We can dedupe in-network like we do with gossip
13:16 < cdecker> Privacy: this is public information, grabbed from the blockchain, how can this be an issue?
13:16 < BlueMatt> given the previous concern about bandwidth usage on the network, that is maybe a bit worrying
13:16 < t-bast> Remember that the things we want to look for in the mempool are the exceptional cases (force-close should be exceptional and only happen during bugs or attacks), so we should be able to not DoS ourselves with those
13:17 < ariard> it depends on how you implement scanning logic for mempool, what if I craft a preimage tx which is in fact not tied to any channel output but mirror template?
13:17 < cdecker> BlueMatt: you're free to opt-out, but saying that noone should use assistance when they clearly need it is definitely the wrong way around
13:17 < BlueMatt> cause maybe the biggest concern ariard points out here is that what you really need to know (and all you really need to know, I think, assuming anchor), is the commitment txid which was broadcast so you can anchor-bump it.
13:17 < ariard> it's not public information as you craft conflict to taint the preimage, like ensured there is only this node able to announce the preimage on the gossip level
13:17 < BlueMatt> which also breaks all the various hidden-channel privacy bits.
13:17 < cdecker> ariard: it's rather trivial to connect an HTLC output to the channel scid that resulted in it
13:18 < BlueMatt> (i mean kinda, you can maybe pattern-match, but that hurts)
13:18 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
13:18 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
13:18 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Read error: Connection reset by peer]
13:18 < cdecker> BlueMatt: we're already tracking channel closes, keep it in your view a bit longer, you're processing those HTLC txs anyway
13:18 < BlueMatt> cdecker: thats fair, but I think my point was also that precisely those who would opt-out due to bandwidth (mobile clients) are also the ones that cannot run bitcoind
13:18 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
13:19 < ariard> cdecker: so you need to track the state of any channel closure, starting from the funding outpoint ? still you can batch the probing on 483 outputs on the same commitment tx to cost optimization
13:19 < BlueMatt> cdecker: I dont think we need htlc txes to be rumored to solve this issue. only anchor.
13:19 < cdecker> BlueMatt: agreed, but it's a tradeoff and it'd be a bad idea to dismiss a partial solution in the hopes of coming up with a perfect one
13:19 < BlueMatt> yea, thats totally fair.
13:20 < cdecker> ariard: 483 HTLCs? That's one expensive close ^^
13:20 < BlueMatt> (the concern is more around private channels, cause those are not tracked by everyone)
13:20 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
13:20 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
13:20 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
13:20 < cdecker> Fair enough, we can come up with good schemes for lightweight nodes to sync the set of preimages selectively
13:20 < ariard> yes that's expensive but learning a full-node/LN mapping, which is assumed to be stable is likely worthy of it
13:21 < ariard> and as you looking on the mempool, I wonder if you can RBF the preimage to cheat on the cost
13:21  * BlueMatt doesn't understand the discussion around preimages, my previous workaround assuming anchor solves that issue even here, I think - you can blindly anchor-rbf-bump htlc txn which are in the mempool as long as you think they are there.
13:21 < cdecker> ariard: you can't learn the (gossip) topology due to the intentional delays we introduce
13:21 < cdecker> Did we start the meeting btw?
13:21 < BlueMatt> dont think so.
13:21 < ariard> my point is this delay is not efficient, if the attacker only announcce the preimage to your mempool and a conflict to the rest of the network
13:22 < cdecker> Feels like we just jumped in head first :-)
13:22 < BlueMatt> we kinda did
13:22 < BlueMatt> this may also be the kind of thing worth a call
13:22 < BlueMatt> I'd suggest another spec meeting to physically discuss it for about the three days it would take, but, you know, probably a bad idea.
13:22 < ariard> even but a meatspace whiteboard session but...
13:22 < cdecker> ariard: we have two complementary networks here: bitcoin and lightning. You can probably infer a relationship on bitcoin, but the delays work on lightning
13:23  * cdecker needs to dig up the bitcoin network topology papers from years ago
13:23 < ariard> I agree with you it works to mask the LN topology, if your delays are poisson distribution, which you don't if your reply but that we should implement
13:23 < cdecker> Yes, you're probably right, an in-person meeting would help clarify a lot
13:24 < ariard> what I'm concerned about is the new, cheap mapping it introduces for mapping full-node-to-LN ones
13:24 < BlueMatt> cause we're all super out of sync now, I think, cause there's five issues and 20 solutions and lots of mixing and matching to do :/
13:24 < cdecker> BlueMatt: 100%
13:24 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
13:25 < BlueMatt> anyway, meeting
13:25 < ariard> I think we can make step forward on the stuff we know we want for sure, which is IMO the peer selection logic ?
13:25 < BlueMatt> hmm?
13:25 < cdecker> ariard: I'm not sure if mapping a bitcoind to LN is at all problematic, and if anythin gossiping preimages provides an alternative source of preimages, masking whether there is a bitcoind underneath the LN node at all or not
13:26 < t-bast> can you define what you mean by peer selection logic?
13:26 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
13:26 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
13:26 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
13:26 < ariard> because independently of pinning, having better peer selection, non-eclipsable it's something good to avoid abusive routing fee inflation
13:26 < ariard> t-bast: how I connect to LN peers to learn about gossips
13:26 < cdecker> ariard: definitely, a diverse set of peers can be helpful (though not necessary if we're just using the current gossip)
13:27 < t-bast> ariard: right, that one shouldn't be too hard, we can easily randomize feeler connections, that would be helpful
13:27 < ariard> cdecker: I was thinking do we have a risk of LN-native eclisping attack, like I force you to connect to my LN peers and announce you only my channels to force you routing through ?
13:28 < ariard> t-bast: I would be a little more careful on the not too hard, you may active attacker poisoning your addr map
13:28 < ariard> like it has been a lot of work on the core side to prevent this, and there are still issues with regards to addr-relay
13:28 < t-bast> ariard: you mean the initial bootstrap is hard?
13:29 < t-bast> how could we help with those? right now this is very based on real-world decisions (I
13:29 < ariard> cdecker: I think mapping a bitcoind to LN is really problematic, it's a sine qua non to make a successful pinning, time-dilation or tx-relay obstruction more efficient
13:29 < t-bast> (I'm going to open a channel to that merchant, or that one)
13:30 -!- renepick [54d313e5@cm-84.211.19.229.getinternet.no] has joined #lightning-dev
13:30 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
13:30 < t-bast> I think that what makes the "saf-ish" bootstrap phase easier in lightning than in bitcoin is that many nodes are associated with real-life services
13:30 < cdecker> I mean there is a well-known impossibility result that without prior knowledge you can only act on whatever your first entrypoint tells you (bootstrapping problem in distributed computing)
13:31 < t-bast> And have a public identity, so you can more easily diversify
13:31 < cdecker> So we need to make sure that the entrypoint is as diverse as possible (DNS seeds, baked in addr lists, ...)
13:31 < ariard> t-bast: agree, it's quite different here, manual peering in practice should almost mitigate this issue, unless are doing honeypots
13:31 < t-bast> I think there's a lot more manual selection than in bitcoin, which helps a lot
13:32 < t-bast> Not a technical solution though :D
13:32 < ariard> yes boostrapping problem for p2p network isn't solved, you somehow need to trust DNS seeds or hardcoded peers, or manual seeding through web-of-trust assumption
13:32 < cdecker> We can likely fall back on our goto-anti-DoS measure and enforce sybil-resistance by only picking nodes that have a channel open (they have funds and have spent some opening a channel)
13:32 < ariard> but due to the fact you're going to pick up your peers based on real-life services for LN, it's harded to exploit I think
13:33 < cdecker> Agreed, in extremis we can likely also fall back on the AS diversity library that sipa contributed to bitcoin core
13:33 < ariard> yes I think we're deviating a bit, we should first qualify if we have native eclipse-attack on LN and what an attacker can gain from then, before thinking mitigating them
13:33 < ariard> (beyond the case of garbage-collecting preimages)
13:33 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
13:33 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
13:33 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
13:34 < ariard> gc_preimages -- garbage-collecting preimages to answer your question cdecker, but you may have a better name :)
13:34 < BlueMatt> right, as t-bast points out, at least in the medium term, a ton of lightning activity is based on real identies or service providers, so eclipse issues are way less likely
13:34 < cdecker> Ok, do we have a risk of an eclipse attack? Not sure, depends on the attacker and its goals. If it is to skew you into using its channels so they can gain fees, then yes
13:34 < cdecker> Otherwise we're not exchanging information that could be dangerous or is unverified
13:35 < ariard> yes that the main one I can think one right now, and if we introduce preimage garbage collecting you want to be sure you're connected to peers signaling such monitoring
13:35 < cdecker> (and option_gc_preimages doesn't change that, we just augment our knowledge of the blockchain)
13:36 < cdecker> Yep, agreed
13:36 < ariard> as it's security you should assume automatic selection for those, how do you prevent someone to trick this ?
13:36 < ariard> like manual peering doesn't guarantee you it's a monitoring node
13:37 < cdecker> Though to be fair, they are signaling that they are relaying the information, not that they are actually watching a bitcoind (disclosing that would indeed add the risk of being targeted)
13:37 < ariard> yes, but I assume that if you connect to 8 peers and at least one of them is proactive and honest that should work
13:37 < t-bast> if your manual peering almost guarantees that you have an un-eclipsed view of the whole graph, then you can randomly open feeler connections and you should regularly connect to well-behaving nodes that will share preimages
13:37 < cdecker> No, don't differentiate monitoring from non-monitoring, the signaling is just "I relay preimages" that's it
13:38 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
13:38 < cdecker> Ideally the entire network relays preimages (except leaf nodes that are on metered connections) then you can pick and chose as you please
13:38  * BlueMatt notes that he's still unconvinced preimage-discovery is an issue with anchor v2.
13:38 < cdecker> The nodes that initiate broadcasts do not have to signal anything beyond their willingness to relay
13:39 < ariard> right, so you may be connected to a) manual peered not signaling b) manual peered signaling c) automatic peers signaling 
13:39 < ariard> and c) maybe entirely malicious if it's automatic dumb selection ?
13:39 < cdecker> Ok, BlueMatt sorry for hammering onto this issue. How does anchor v2 address that?
13:39 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Ping timeout: 260 seconds]
13:40 < BlueMatt> cdecker: the previous discussion was (if you know that the commitment transaction is either in the mempool or on chain), you can "blind-anchor-cpfp" the htlc transactions - there's a limited number of them and you know the txid without knowing the preimage, so you can cpfp them to get them confirmed (and if they arent there, your cpfp tx will just be ignored)
13:41 < BlueMatt> we *probably* would want a similar thing whereby you can tell your lightning peers about a transaction that you want relayed, but thats maybe no different than today
13:41 < t-bast> Does that require changes to the current anchor output proposal?
13:42 < BlueMatt> t-bast: last i checked the current anchor proposal was going to be cut back to only the commitment tx and leave htlcs alone so that we could redo that later, given it didnt work properly there anyway
13:42 < cdecker> Does that require all HTLCs to have two anchor outputs (one per endpoint)?
13:42 < BlueMatt> so, yes, but last time i was a part of the discussion we were planning on doing that anyway
13:43 < ariard> I think a remote anchor ouput on a local transaciton, either HTLC or commitment is flawed due to again not mempool omniscience
13:43 < BlueMatt> cdecker: yes. though, again, last time i was a part of the discussion i think we said "well talk about that later", and I think we really are going to have no choice but to go that way, for high-value htlcs, likely splitting htlcs into "has anchor, cause its worth it" and "is barely worth putting on the chain, so we'll take the risk" buckets.
13:43 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
13:43 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
13:43 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
13:43 < cdecker> But if there is no remote-on-local-tx anchor output, then I can't blind-CPFP your success tx, or am I missing something?
13:44 < ariard> okay not HTLC because you can be sure the commitment is confirmed but you may have any version of a revoked commitment tx being pinned in the network and not able to see it
13:44 < BlueMatt> ariard: I agree for commitment tx if you're worried about your counterparty broadcasting old commitment txn and that preventing you from broadcasting the latest one
13:44 < BlueMatt> which I think *is* an issue, though maybe a less important one, and one that may require being solved with something similar to gc_preimages, but for  commitment-tx-pattern-matching txids
13:45 < BlueMatt> cdecker: define "remote-on-local-tx"?
13:45 < ariard> cdecker: yes but to assume that your blind CPFP is successful you need to know the txid of commitment being pinned
13:45 < cdecker> Was just referring to what ariard said two lines above: "I think a remote anchor ouput on a local transaciton, either HTLC or commitment is flawed due to again not mempool omniscience"
13:46 < ariard> and it maybe any of the previous states of your channel
13:46 < cdecker> Don't we know the commitment TX? That one has to confirm before anything else can happen.
13:46 < cdecker> Oh wait you mean we're unlucky and the commitment TX is also in limbo until the HTLC CLTV expires?
13:46 < BlueMatt> right, so it sounds like we're on the same page. the issue with that proposal is that you have to always reliably learn commitment txids when they are broadcast (so you can look up the corresponding local state)
13:47 < cdecker> That's pure evil ;-)
13:47 < ariard> yes I'm talking about pinning the commitment tx itself to block you from timing-out or claiming a HTLC
13:47 < BlueMatt> cdecker: yes, that is precisely the situation.
13:47 < ariard> aand there is even more funny games,  a CPFP to be successful need a fresh utxo, someone may announce you a lot of commitment txid, and you may try to bump all of them
13:48 < BlueMatt> the issue is that you need to learn via the mempool when a commitment txid has been broadcast by your counterparty (kinda....i mean you only care about this at the time you go to close on-chain due to htlc timeout, not before)
13:48 < ariard> thefore exhausting fresh utxo in-flight on not pertinent commitment transactions
13:48 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
13:48 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Remote host closed the connection]
13:48 < BlueMatt> one proposal to address *that* is re-adding bitcoin core reject messages, but including the conflicting tx/txid when a transaction cannot be braodcast due to conflicts
13:49 < BlueMatt> but you very quickly get into whack-a-mole with these types of things
13:49 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #lightning-dev
13:49 < ariard> reject messages are sybillable, and you can easily provoke bumping-utxo exhaustion
13:50 < BlueMatt> (sidenote: sighash_no_input is *really* elegant here - assuming a lot of complicated logic in core to do so, you could imagine blind-cpfp-bumping *any* commitment tx without knowing its there or which one it is all with one tx.......in theory)
13:50 < BlueMatt> ariard: right. I'm not a fan of that idea, only noting it for completeness
13:50 < cdecker> BlueMatt: interesting note on noinput there
13:51 < ariard> BlueMatt: yes I think noinput solves it because you can push the state forward, either a valid commitment or a revoked one, but confirming a rmeote revoked is favorable to you
13:52 < BlueMatt> (note that actually *doing* that may be intractible in bitcoin core for mempool-complexity reasons, but in theory its possible)
13:52 < ariard> but it's likely a hell to implement how do you pair witnessScript with scritpubkey without actually playing the script interpreter
13:53 < BlueMatt> right. you could imagine specifying it in some elegant way when broadcasting, though - "try to attach this to output 2 to any tx that spends output X:Y"
13:53 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
13:53 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
13:53 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
13:53 < ariard> or we can tag commitment tx and cpfp-bump, likely what you're saying
13:54 < cdecker> BlueMatt: so why not just do what eltoo does in reaction to everything: broadcast the latest state. If it doesn't confirm, rebroadcast with higher fees, until it eventually confirms
13:54 < ariard> IMO, the most-viable to solve this is to push for a feerate limited-package-relay
13:54 < ariard> that way, it's only a feerate game between attacker and victim which is easy to analyze
13:55 < cdecker> Yes, absolutely. Simplifying the RBF rules to be linear and only consider feerate is the best solution imho
13:55 -!- t-bast [~t-bast@2a01:e34:efde:97d0:a0dd:b1dd:ac09:d724] has quit [Remote host closed the connection]
13:55 < cdecker> For all I care it can mandate a feerate-increase of 10%+ in order to be considered, that can act as a DoS mitigation, by forcing exponential feerate increases
13:55 < BlueMatt> cdecker: right, yea, that solves it too.
13:56 < cdecker> But the non-linearity is really painful
13:56 -!- t-bast [~t-bast@2a01:e34:efde:97d0:a0dd:b1dd:ac09:d724] has joined #lightning-dev
13:56 < ariard> cdecker: how do you broadcast higher fees with a pre-committed model ? Attacker may manipulate feerate/absolute fee of latest state through update_fee/dust htlcs
13:56 < BlueMatt> cdecker: eltoo solves this whole quagmire quite nicely....as with everything, apparently.
13:56 < ariard> cdecker: to avoid solving non-linearity for now I was meaning by limited-package-relay, one limited to one-parent child
13:57 < cdecker> Oh, I'm thinking more towards an all-anchors / eltoo world which we want anyway, right? Requiring predicting the future feerate is a bad choice
13:57 < ariard> like introduce a package-relay with a policy limitation on package topology to avoid DoS issues for now
13:57 < cdecker> BlueMatt: careful, don't become an eltoo-hypeman like me :-)
13:58 < ariard> what do you mean here by predicting a future feerate ? But yes we want all-anchors here, and maybe eltoo if we can solve implementation complexity hurdles on the mempool-side
13:58 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
13:58 < cdecker> I mean committing to a feerate by including the fee in the commitment means we have to predict what a useful feerate will be at a later time, when we need to broadcast
13:58 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
13:58 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
13:58 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
13:59 < niftynei> hey all we're at about an hour now, i think we forgot to call startmeeting? lol
13:59 < ariard> okay so implementing package-relay feerate-based would alleviate this because you adjust feerate via the malleable CPFP
14:00 < ariard> at broacast when you need and you can adjust it
14:01 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
14:01 < niftynei> was there any other urgent business that needs to be discussed?
14:01 < cdecker> Yep, anchor outputs are a huge improvement, both in terms of overallocation of fees, but also flexibility to react to things
14:01 < ariard> yes with regards to anchor outputs, I think we should split spec in 2, the congestion-part and the security-part
14:02 < cdecker> @all: sorry for taking up all the air in the room with the RBF pinning issue, but I think we made some progress :-)
14:02 < rusty> niftynei: yeah, I am planning on just reading the logs once I am awake.
14:02 < ariard> should we add a remote anchor output if the security efficieny is hard to gauge with regards to whole previous discussion
14:03 < t-bast> I think it was a very interesting discussion, don't mistake our silence for boredom, we're listening/reading closely ;)
14:03 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
14:04 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
14:04 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
14:04 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
14:04 < ariard> has anyone look on anchor output script? I'm not sure if the spending-path for anyone-can-spend is standard wrt to MINIMALIF
14:05 -!- t-bast [~t-bast@2a01:e34:efde:97d0:a0dd:b1dd:ac09:d724] has quit [Remote host closed the connection]
14:06 -!- t-bast [~t-bast@2a01:e34:efde:97d0:a0dd:b1dd:ac09:d724] has joined #lightning-dev
14:06 < ariard> is anyone of LL here? what's their opinion on re-scoping a bit the spec to congestion-only ? I.e dropping remote anchor output and CSV in script
14:08 < BlueMatt> I dunno if droping remote anchor is a great idea. i mean it *is* useful if you detect the commitment tx in the mempool.
14:08 < ariard> but it opens a vector attack for me to broadcast my remote commitment and you locking a bumping-utxo for nothing
14:09 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
14:09 < ariard> i your security rely on bumping commitment tx, you should really care about tracking your bumping utxo and have enough to cover all your channel in case of worst-case scenario
14:09 < ariard> I think for us to learn about CPFP and those utxo management is also a good reason to scope the PR
14:10 < BlueMatt> ariard: hmm? I dont quite get the issue here?
14:11 < ariard> BlueMatt: I broadcast few remote commitment transactions in your mempool, you see the anchor output and try to CPFP-bump them, at some point you don't have available utxos anymore
14:12 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
14:12 < BlueMatt> "few"? they conflict, you can only broadcast one?
14:12 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
14:12 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
14:12 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
14:12 < BlueMatt> oh, you mean across channels? I dont see how this is different on remote anchor vs not
14:12 < BlueMatt> like, you have to assume you may need an anchor per channel just for broadcasting latest local state anyway
14:12 < ariard> no on one channe, so you assume the remote commitment tx you see is the one seen by other network mempools ?
14:13 < BlueMatt> or, at least, if you dont have that that you run some risk.
14:13 < BlueMatt> if its just one channel you can reuse the same utxo over and over
14:13 < BlueMatt> all the parent txn conflict so no different
14:13 < ariard> yes you need one utxo to feed the CPFP to bind on any anchor for all your channel, I think
14:13 < ariard> but you don't know which parent txn is effectively in other network mempools
14:14 < BlueMatt> right, but for any given node only one parent can be in the mempool, so using the same utxo for bumping will not change propagation whatsoever
14:14 < ariard> it's quite related to pinning, but you may in fact CPFP a useless remote tx
14:14 -!- rdymac [uid31665@gateway/web/irccloud.com/x-dfsjarzdtjaixoop] has quit [Quit: Connection closed for inactivity]
14:15 < cdecker> ok, gotta go, see you all around on the interwebz :-)
14:15 < ariard> cdecker: see you :)
14:15 < t-bast> same here, see you on github!
14:16 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
14:16 -!- t-bast [~t-bast@2a01:e34:efde:97d0:a0dd:b1dd:ac09:d724] has quit [Quit: Leaving]
14:16 < BlueMatt> yea, I should probably get back to "real" work. anyway, we should probably have some kind of video/phyical-eventually chat about all this stuff. there's a lot here and it would be nice to decide if/which version of anchor it makes sense to make progress on.
14:16 < ariard> my concern is the remote anchor output give the ability for your counterparty to lock one of your utxo and I wonder how it can exploited
14:16 < BlueMatt> cause there are now several different ideas :/
14:17 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
14:17 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
14:17 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
14:19 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Ping timeout: 246 seconds]
14:20 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
14:22 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
14:25 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 246 seconds]
14:25 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
14:25 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
14:25 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
14:26 -!- renepick [54d313e5@cm-84.211.19.229.getinternet.no] has quit [Remote host closed the connection]
14:27 -!- pretyflaco1 [~k3m@82.102.16.91] has joined #lightning-dev
14:27 -!- pretyflaco [~k3m@185.213.155.168] has quit [Ping timeout: 260 seconds]
14:28 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ilaigwvrmumreyqt] has joined #lightning-dev
14:30 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]
14:31 -!- shesek [~shesek@185.3.145.28] has joined #lightning-dev
14:31 -!- shesek [~shesek@185.3.145.28] has quit [Changing host]
14:31 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
14:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Ping timeout: 256 seconds]
14:44 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
14:45 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
15:01 -!- pretyflaco1 [~k3m@82.102.16.91] has quit [Ping timeout: 265 seconds]
15:02 -!- pretyflaco [~k3m@82.102.16.91] has joined #lightning-dev
15:07 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
15:08 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
15:20 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
15:25 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
15:28 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
15:29 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev
15:30 -!- _flow_ [~none@salem.informatik.uni-erlangen.de] has quit [Ping timeout: 244 seconds]
15:34 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
15:38 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
15:39 -!- _flow_ [~none@salem.informatik.uni-erlangen.de] has joined #lightning-dev
15:39 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #lightning-dev
15:39 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
15:41 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
15:41 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
15:41 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
15:44 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
15:47 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
15:48 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
15:52 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has quit [Remote host closed the connection]
15:57 -!- hiroki_ [01210b86@pl31366.ag2001.nttpc.ne.jp] has joined #lightning-dev
16:02 -!- mrostecki [~mrostecki@gateway/tor-sasl/mrostecki] has joined #lightning-dev
16:04 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
16:07 -!- rorp [68fe5c3e@104.254.92.62] has quit [Ping timeout: 245 seconds]
16:07 -!- hiroki_ [01210b86@pl31366.ag2001.nttpc.ne.jp] has quit [Remote host closed the connection]
16:07 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Read error: No route to host]
16:07 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
16:11 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
16:14 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Remote host closed the connection]
16:30 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has joined #lightning-dev
16:30 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
16:31 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Read error: Connection reset by peer]
16:31 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
16:32 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Remote host closed the connection]
16:32 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
16:33 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Remote host closed the connection]
16:34 -!- proofofkeags [~proofofke@c-65-50-169-164.hs.gigamonster.net] has quit [Ping timeout: 246 seconds]
16:34 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
16:35 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 240 seconds]
16:43 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
16:46 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
16:48 -!- pretyflaco [~k3m@82.102.16.91] has quit [Ping timeout: 256 seconds]
16:48 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 265 seconds]
16:48 -!- slivera [~slivera@103.231.88.10] has joined #lightning-dev
17:00 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
17:05 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 272 seconds]
17:06 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
17:09 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 240 seconds]
17:09 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
17:25 -!- gojiHmPFPN [~textual@c-73-47-220-190.hsd1.ma.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
17:38 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
17:42 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 240 seconds]
17:42 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
17:43 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
17:43 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 260 seconds]
18:01 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
18:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
18:15 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
18:20 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 256 seconds]
18:26 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
18:29 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Ping timeout: 240 seconds]
18:30 -!- AbramAdelmo [~AbramAdel@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 264 seconds]
18:35 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Quit: %bye%]
18:37 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
18:50 -!- harrigan [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has joined #lightning-dev
18:50 -!- harrigan- [~harrigan@ptr-93-89-242-235.ip.airwire.ie] has quit [Read error: Connection reset by peer]
18:56 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
19:05 < zmnscpxj__> Late to the party, but it seems to me there is a mild disconnect here: you cannot depend on peers with whom you have channels with for any information about channels, because peers-with-channels have an incentive to attack you
19:05 < zmnscpxj__> so you would want to connect to peers you have no channels with to get that information because it is those peers who do not *yet* have incentive to attack you, but then why would you need to change the *Lightning* spec
19:07 < zmnscpxj__> it might be better to have a separate piece of infrastructure for this get-information-about-chain-shenanigans thing
19:13 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has joined #lightning-dev
19:33 < ariard> zmnscpxj__: you're right about distrusting peers-with-channels, as some point we mention automatic selection of such monitoring peers, it didn't imply we would open a channel with every of them
19:34 < ariard> at least you need to change the spec to have a common format about preimage message
19:34 -!- Relis [~Relis@cpc96290-lewi18-2-0-cust910.2-4.cable.virginm.net] has quit [Quit: This computer has gone to sleep]
19:34 < ariard> a separate piece of infrastructure means harder to get it deployed and adopted, for security mitigations even if they profit the network and not you first, it's better to bundle thing IMO
19:36 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
19:37 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
19:40 < zmnscpxj__> thing is, something like a CoinSwap market might be interested in similar mitigations as well, as I expect similar problems to arise there
19:41 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Ping timeout: 240 seconds]
19:44 -!- th0th1 [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
19:49 <+roasbeef> ariard: don't follow this utxo scarcity thing, that seems totally up to the wallet to manage their utxos possilby 
19:50 <+roasbeef> re needing to know which commitment has entered the chan, in our impl, we just try to anchor all of our possible commits (and at times theirs) down, as only one can be confirmed in the end 
19:50 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #lightning-dev
19:51 <+roasbeef> I don't see why the anchro stuff needs to be dropped at all, these conversations (particularly the eclipse stuff) fees a bit overly academic 
19:51 <+roasbeef> let's just focus on solving the main issue at hand, allowing users to actually bump the fees on their commitments 
19:53 <+roasbeef> fees are low again as of recent, but that shouldn't make us complacent 
19:54 <+roasbeef> our version of anchors in 0.10 (our latest release) still requires a big tag, but we may just elevate it, as it's literally been ready for months now 
19:54 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
19:55 <+roasbeef> > so why not just do what eltoo does in reaction to everything: broadcast the latest state. If it doesn't confirm, rebroadcast with higher fees, until it eventually confirms
19:55 <+roasbeef> how's this any diff from what can be done w/ anchors? this is what we do rn, a bumpfee call is exposed to users who can use it to increase the fee accordingly 
19:56 <+roasbeef> or I guess this is about RBF instead? 
20:00 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
20:07 -!- gojiHmPFPN [~textual@c-73-47-220-190.hsd1.ma.comcast.net] has joined #lightning-dev
20:13 -!- th0th [~th0th@gateway/tor-sasl/th0th] has quit [Remote host closed the connection]
20:13 -!- th0th [~th0th@gateway/tor-sasl/th0th] has joined #lightning-dev
20:34 -!- rdymac [uid31665@gateway/web/irccloud.com/x-ilaigwvrmumreyqt] has quit [Quit: Connection closed for inactivity]
20:58 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Remote host closed the connection]
20:59 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #lightning-dev
21:20 -!- vasild_ [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev
21:23 -!- vasild [~vd@gateway/tor-sasl/vasild] has quit [Ping timeout: 240 seconds]
21:23 -!- vasild_ is now known as vasild
21:32 -!- ThomasV [~thomasv@unaffiliated/thomasv] has quit [Read error: Connection reset by peer]
21:44 -!- gojiHmPFPN [~textual@c-73-47-220-190.hsd1.ma.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:04 -!- gojiHmPFPN [~textual@c-73-47-220-190.hsd1.ma.comcast.net] has joined #lightning-dev
22:20 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Remote host closed the connection]
22:38 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
22:41 -!- gojiHmPFPN [~textual@c-73-47-220-190.hsd1.ma.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
22:44 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
22:51 -!- gojiHmPFPN [~textual@c-73-47-220-190.hsd1.ma.comcast.net] has joined #lightning-dev
22:59 -!- gojiHmPFPN [~textual@c-73-47-220-190.hsd1.ma.comcast.net] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
23:00 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has joined #lightning-dev
23:05 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev
23:10 -!- proofofkeags [~proofofke@71-218-146-180.hlrn.qwest.net] has quit [Ping timeout: 256 seconds]
23:15 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds]
23:17 -!- Pavlenex [~Thunderbi@141.98.103.251] has quit [Quit: Pavlenex]
23:24 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Remote host closed the connection]
23:41 -!- t-bast [~t-bast@2a01:e34:efde:97d0:a0dd:b1dd:ac09:d724] has joined #lightning-dev
23:44 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
23:53 -!- Pavlenex [~Thunderbi@141.98.103.251] has joined #lightning-dev
23:57 -!- ThomasV [~thomasv@unaffiliated/thomasv] has joined #lightning-dev
--- Log closed Tue Jun 09 00:00:45 2020