--- Log opened Mon Jan 18 00:00:18 2021
00:06 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
00:19 -!- shesek [~shesek@unaffiliated/shesek] has quit [Remote host closed the connection]
00:38 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
00:39 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
00:48 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
01:36 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
01:51 -!- midnight [~midnight@unaffiliated/midnightmagic] has quit [Ping timeout: 258 seconds]
01:53 -!- midnight [~midnight@unaffiliated/midnightmagic] has joined #lightning-dev
01:56 -!- laptop [~laptop@ppp-2-6.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
02:01 -!- ulrichard [~richi@pub151248168243.dh-hfc.datazug.ch] has joined #lightning-dev
02:04 -!- kexkey [~kexkey@static-198-54-132-170.cust.tzulo.com] has quit [Ping timeout: 240 seconds]
02:44 -!- guntha [~guntha@188.166.221.196] has joined #lightning-dev
02:45 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 268 seconds]
02:45 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
02:46 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
02:55 -!- arij [uid225068@gateway/web/irccloud.com/x-ibeslswbmefmdcmc] has quit [Quit: Connection closed for inactivity]
03:06 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Quit: __gotcha]
03:07 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
03:24 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
03:31 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Remote host closed the connection]
03:31 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has joined #lightning-dev
03:36 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #lightning-dev
03:37 -!- laptop_ [~laptop@ppp-2-180.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
03:39 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 256 seconds]
03:40 -!- laptop [~laptop@ppp-2-6.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 246 seconds]
03:43 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
03:53 -!- r1clas [~riclas@77.7.37.188.rev.vodafone.pt] has quit []
03:53 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
03:58 -!- Setherson [~Setherson@108-255-110-61.lightspeed.tukrga.sbcglobal.net] has quit [Ping timeout: 240 seconds]
04:33 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Remote host closed the connection]
04:33 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
04:41 -!- lndbot [~lndbot@138.197.213.35] has quit [Remote host closed the connection]
04:41 -!- lndbot [~lndbot@138.197.213.35] has joined #lightning-dev
04:44 -!- belcher_ is now known as belcher
04:44 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Ping timeout: 268 seconds]
04:45 -!- mblackmblack [~matt@178.128.230.221] has quit [Ping timeout: 256 seconds]
04:46 -!- nibbier [~quassel@mx01.geekbox.info] has quit [Quit: No Ping reply in 180 seconds.]
04:47 -!- mblackmblack [~matt@178.128.230.221] has joined #lightning-dev
04:47 -!- nibbier [~quassel@mx01.geekbox.info] has joined #lightning-dev
04:48 -!- berndj [~berndj@ns1.linksynergy.co.za] has quit [Quit: ZNC - http://znc.in]
04:48 -!- berndj [~berndj@ns2.linksynergy.co.za] has joined #lightning-dev
04:56 -!- Netsplit *.net <-> *.split quits: xwvvvvwx, sr_gi, drolmer, BlueMatt, gwillen
04:59 -!- drbrule [sid395654@gateway/web/irccloud.com/x-paaykgotjsetujxc] has quit [Ping timeout: 264 seconds]
04:59 -!- Netsplit over, joins: gwillen, drolmer, BlueMatt, sr_gi, xwvvvvwx
05:00 -!- drbrule [sid395654@gateway/web/irccloud.com/x-giisfptxuqrnwclp] has joined #lightning-dev
05:03 -!- martindale [ericfabric@gateway/shell/matrix.org/x-ksmyyuajnokcdbfd] has quit [Ping timeout: 240 seconds]
05:08 -!- cameron[m] [cameronots@gateway/shell/matrix.org/x-iputcloqrqqrfzub] has quit [Ping timeout: 268 seconds]
05:12 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
05:14 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has quit [Remote host closed the connection]
05:15 -!- kloinka [~quassel@223.177.233.220.static.exetel.com.au] has joined #lightning-dev
05:21 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Remote host closed the connection]
05:21 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev
05:22 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
05:27 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
05:31 -!- zmnscpxj_ [~zmnscpxj@gateway/tor-sasl/zmnscpxj] has quit [Ping timeout: 268 seconds]
05:43 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 265 seconds]
05:50 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
05:56 -!- martindale [ericfabric@gateway/shell/matrix.org/x-cuzfqrxjlsikssmb] has joined #lightning-dev
06:01 -!- cameron[m] [cameronots@gateway/shell/matrix.org/x-lfmafolmroevkaqt] has joined #lightning-dev
06:07 -!- ulrichard [~richi@pub151248168243.dh-hfc.datazug.ch] has quit [Quit: Ex-Chat]
06:22 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Read error: Connection reset by peer]
06:23 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
06:23 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
06:32 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev
06:37 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Quit: __gotcha]
06:37 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
08:08 -!- mol [~mol@unaffiliated/molly] has quit [Ping timeout: 246 seconds]
08:13 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
08:14 -!- mol [~mol@unaffiliated/molly] has joined #lightning-dev
08:41 -!- tiker[m] [tikerfunky@gateway/shell/matrix.org/x-ewyhcncgehyojacx] has joined #lightning-dev
08:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
08:42 -!- r1clas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
08:42 -!- ThomasV__ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
08:42 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev
08:43 -!- musdom1 [~Thunderbi@202.184.0.102] has joined #lightning-dev
08:44 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 256 seconds]
08:44 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Ping timeout: 256 seconds]
08:44 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 256 seconds]
08:44 -!- musdom1 is now known as musdom
08:45 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
08:56 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev
09:15 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""]
09:38 -!- arij [uid225068@gateway/web/irccloud.com/x-wuazgzqtlfpeymjb] has joined #lightning-dev
09:46 -!- ThomasV__ [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 260 seconds]
09:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 240 seconds]
10:15 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 256 seconds]
10:18 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 264 seconds]
10:28 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
10:29 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
10:54 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev
10:58 < cdecker> Good evening everyone ^^
10:59 < t-bast> Good evening guys!
10:59 < jkczyz> hello
10:59 < gleb> hi
11:01 < t-bast> I've put a tentative agenda here: https://github.com/lightningnetwork/lightning-rfc/issues/831 but there's not much new, let me know if you want to take the opportunity to discuss something else for a change!
11:05 < t-bast> cdecker: I've provided a lengthy answer to your comments on the trampoline PR, the TL;DR is that I think it's the right time to use new routing hints ;)
11:06 < ariard> bonjour
11:06 < cdecker> Seems we're missing the US side of the spec team, quick let's change all examples to Euros
11:06 < ariard> t-bast: offers? I had a first look today
11:06 < cdecker> t-bast: thanks I'll reply on the PR :-)
11:07 < t-bast> europe FTW
11:07 -!- ThomasV__ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
11:07 < t-bast> we cannot discuss offers without rusty in the room, that would be rude
11:08 < ariard> yes, he might come
11:09 < lndbot> <johanth> hi, all :slightly_smiling_face:
11:09 < t-bast> hey johanth
11:09 < ariard> t-bast: what your support plan around `option_zero_htlc_tx_fee` I would like to jump RL directly to it before production deployment
11:09 < ariard> and drop support for legacy formats
11:09 < bitconner> hola
11:10 < t-bast> ariard: I'm going to work on finalizing the anchors work for eclair, we should be able to enable it soon-ish
11:10 < t-bast> so it should be ok if you don't support legacy formats, we're making that some choice in our kotlin lightning implementation
11:11  * t-bast waves at bitconner, at last a US citizen in this room
11:11 < ariard> t-bast: sweet, we hope to deploy mid/end S1
11:11 < bitconner> t-bast: yeah it's a holiday here in the US (MLK day) so idk how many others will join
11:11 < jkczyz> t-bast: forgot about me :P
11:11 < t-bast> ariard: nice, that would be your prod-ready release?
11:12 < t-bast> jkczyz I didn't know where you're from xD, sry
11:12 < ariard> t-bast: yep alpha one for mainet modulo security caveats we'll know about
11:12 < t-bast> ok, didn't know it was a holiday in the US, looks like they all happen on mondays!
11:12 < bitconner> hi jkczyz!
11:13 < bitconner> t-bast: yeah probalby 3-4 meetings a here fall on monday holidays
11:13 < t-bast> I think rusty is not there yet, but shall we start with the PRs in the agenda?
11:13 < ariard> yessss
11:14 < t-bast> #startmeeting
11:14 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/issues/831
11:14 < bitconner> side note: planning to update/replace the current amp draft PR this week
11:14 < t-bast> #topic Bolt 3 test vectors
11:14 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/539
11:15 < t-bast> bitconner: nice!
11:15 < t-bast> jkczyz I see you merged to rust-lightning the test vectors, so it looks like they worked on your end?
11:15 < jkczyz> yes, hi verified the new test vector for RL. thanks for helping out t-bast!
11:15 < t-bast> great!
11:16 < t-bast> cdecker do you know if someone tested them in c-lightning?
11:16 < t-bast> shall we merge them or wait for another ACK?
11:16 < cdecker> Not sure, we're putting the finishing touches on a new release, so a lot of things in flight atm
11:17 < t-bast> Allright, there's no hurry to merge this PR, we can wait for you to test it out after your release
11:17 < t-bast> I'll tag rusty for that
11:18 -!- rdymac [uid31665@gateway/web/irccloud.com/x-egpflvuxyltuygug] has joined #lightning-dev
11:18 < t-bast> #action wait for c-lightning to verify the test vectors after their release
11:18 < t-bast> #topic Sync complete flag
11:18 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/826
11:18 < t-bast> Quick update on that one: I've made the changes in eclair to correctly set `sync_complete`
11:18 < t-bast> lnd already does this
11:19 < t-bast> what about rust-lightning and c-lightning?
11:19 < t-bast> once all implementations have merged support for correctly setting the field, we can start interpreting it and later split blocks across queries
11:19 < ariard> not yet implemented, I think bmancini is working on it
11:21 < cdecker> c-lightning still implements the old behavior
11:22 < cdecker> Opening a new PR on our side to get this back on the radar
11:22 < t-bast> Cool thanks, probably for after your release. Let's keep this item on the agenda and we'll get there.
11:22 < t-bast> #topic anysegwit
11:23 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/672
11:23 < t-bast> Has someone implemented this yet (apart from c-lightning)?
11:23 < t-bast> We had a concept ACK, it's simply pending an interop test once someone has time to implement it.
11:24 < bitconner> not yet for lnd, probalby 0.13
11:25 < t-bast> :+1:
11:25 < ariard> I'll open an issue in RL
11:26 < t-bast> Ok then, let's keep it on the agenda to track when we've got interop testet
11:26 < t-bast> *tested
11:26 < t-bast> #topic 0-fee htlc anchor outputs
11:26 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/824
11:26 < t-bast> I've seen that lnd merged support for this already
11:27 < t-bast> Has someone finalized another implementation and been able to do an interop test?
11:27 < bitconner> yes it will be available in 0.12
11:27 < bitconner> but opt-in
11:27 < t-bast> by default you'll keep using the standard commitment format?
11:28 <+roasbeef> yeh we want to expieriment w/ a few diff ways of ensuring utxos are available or able to be tacked on 
11:28 < t-bast> ok great, that gives us more time to catch up xD
11:28 <+roasbeef> as otherwise stuff like sendall would start failing overnight for ppl if it were made the default
11:28 <+roasbeef> so wanted to soften that change on wallets, etc 
11:29 < t-bast> cool, makes sense, don't hesitate to share what you learn there (on the PR or elsewhere)
11:30 <+roasbeef> yeh my fave solution to the UTXO reservation in general is ppl using stuff like Loop Out to be able to move funds from existing channels, but then you still have an edge case when you only have that one channel that's inactive or w/e that you want to force close 
11:31 < ariard> or ask for reserve bumping UTXO at channel funding, automatically splitted from the funding
11:31 <+roasbeef> in the end, it pushes the problem a bit out into the future, but lets you better utilize the funds in a channel until that point (which may never come also since it's a force close scenario) 
11:31 <+roasbeef> ariard: yeh we have that impl'd rn, if someone tries to use sendall, we insert another output if there's no c hange to resreve for the channel 
11:31 < bitconner> there still needs to be a solution that doesn't depend on third-party service
11:31 <+roasbeef> Q ofc is how big you should reserve there 
11:31 <+roasbeef> sure, it's just an easy way for those that're already using it 
11:32 < ariard> roasbeef: that's a really good question have you heard fractional reserve ?
11:32 <+roasbeef> big Q is how big the UTXOs should be that you reserve, which kiiinda gets you back to "guess fees ahead of tiem" 
11:32 < bitconner> (which is why node should implement some sort of on-chain fee reserve)
11:32 <+roasbeef> tho in this case it's an exceptional thing, and you can still recover if able to get more funds into the wallet 
11:32 < ariard> game-theory you would like to have the full-channel value available too burn in fees
11:32 < ariard> but that's not realistic on the economic-side
11:32 <+roasbeef> possibly on the API level, this can be exposed to users as another "on chain reserve" for a channel 
11:32 < bitconner> there are also some edge cases around initial funding: should you accept an anchor channel if you have no utxos?
11:33 < ariard> roasbeef: you bumping utxo reserve can be shared across channel
11:33 < t-bast> it opens a huge can of worms :)
11:33 < bitconner> you may need funds to sweep a disputed htlc
11:33 < ariard> it works if you don't have to close all of them as the same time
11:33 <+roasbeef> ariard: mhmm, so q is do you always aggregate it each funding attempt, or leave them as diff utxos which increases costs at force close stime slightly 
11:33 < ariard> bitconner: the bumping utxo can be either attached to the CPFP on anchor or aggregate with second-level
11:33 < ariard> at least my implementation is doing this
11:34 < bitconner> ariard: how do you do that with no utxos?
11:34 <+roasbeef> yeh that's how we do it as well, works pretty good in practicve so far, and we can also just aggregrate the htlc second lvl w/ other sweeps or w/e going on at the time 
11:34 < t-bast> he's a bitcoin core dev, he doesn't need utxos
11:34 < ariard> roasbeef: yeah this q should also encompass your onchain activitty if you have an unified wallet
11:35 <+roasbeef> the main reason we didn't do it by default was wasan't very confident in the down stream UX for developers and those running services, etc -- as some things they're doing rn would possilby just be prevented or work in a slightly diff way 
11:35 < bitconner> we just need a magic opcode that will sweep htlcs for free :)
11:35  * roasbeef dials up f2pool
11:35 < lndbot> <johanth> that would be cool :slightly_smiling_face:
11:35 < ariard> bitconner: you ask them to reserve utxos at channel opening, forcing a reserve from the channel value they want to open
11:36 < t-bast> that's an issue we've raised right from the beginning: anchor outputs moves the complexity away from estimating the on-chain fee to reserving utxos efficiently but safely, which is really hard to put in a nice UX for a mobile wallet
11:36 < ariard> I agree, we're going to grope a bit here...
11:36 < t-bast> it's especially hard for "small" nodes
11:37 < t-bast> in particular for the case bitconner mentionned: if you're a small node, what do you do if many people want to open channels to your but you don't have that many utxos?
11:37 < ariard> t-bast: you mean for the ones buying channels, like phoenix?
11:37 < ariard> which don't have utxo at all
11:37 < t-bast> it's awesome to get incoming liquidity so you shouldn't brush it off, but are you taking a risk there?
11:38 < t-bast> I meant for all small nodes/wallets, that have limited funds but want to maximize the utility of their btc, without having too much unused capacity
11:38 < bitconner> t-bast: it's not so bad if you're not a routing node, worst case is you leave a timeout on chain that can be swept later if funds are added
11:38 < ariard> t-bast: you can have one bumping utxo for all your channels, and chain your CPFP for closing if multiples have to be closed
11:38 < t-bast> bitconner: true, it's better for wallet since they don't relay, many attack vectors simply disappear there
11:39 < ariard> but beware not hitting the mempool packages limit
11:40 < t-bast> ariard: I think it can still be exploited, if someone opens many channels to you, then slowly closes them as you bump: the RBF rules may make it very hard for you to adapt your sweep to additional channels being closed
11:40 <+roasbeef> t-bast: imo matters a bit less for mobile nodes, since they likely aren't forwarding payments, so there's no worst case scenario where they lose funds due to not being able to claim on time 
11:41 < t-bast> Mallory opens 10 channels to you, closes one: you use your utxo to bump, then Mallory closes a second one, you need to either chain or RBF, then she repeats until you hit mempool limits or can't RBF because you can't afford the minimum increment
11:41 < t-bast> roasbeef: yes I agree, it's not very risky for mobile wallet, but small-ish routing nodes may have issues there
11:41 <+roasbeef> t-bast: as long as the utxo is confirmed you can add that as a new input to your RBF transaction 
11:42 < t-bast> right, you can wait for a few blocks if you have high enough cltv_expiry_deltas
11:42 <+roasbeef> idk doesn't seem like something to be too worried about...mallory needs to also spend an amt of chain fees in the same order of mag 
11:42 < t-bast> it still makes me uneasy, coupled with a period of high on-chain fees, this feels dangerous for small nodes
11:42 <+roasbeef> someone's gonna get something confirmed eventually
11:42 <+roasbeef> it's waaay better for small nodes, they can actually adaptnow 
11:43 < ariard> I don't think Mallory needs to spend here, you just hold on channel update to force your honest counterparty to close
11:43 <+roasbeef> but yes adapting properly needs to be carefully implemented, but before they'd be fucked and have no way to update things at all 
11:43 < t-bast> you just don't ACK a fulfill for example, forcing the remote to close
11:43 < bitconner> yes but if you're not forwarding payments then you don't lose money if you can't get confirmed in time
11:43 < ariard> roasbeef: yes you can aggrregate and thus stay under mempool package limits
11:43 <+roasbeef> goes back to the "...are we still talking about fees" questrions -- yes, fees are hard at the end of the day 
11:44 < ariard> it's 2021 we're still talking about fees :p
11:44 < bitconner> nothing is certain but death and fees
11:44 < ariard> xD
11:44 < t-bast> It's really the hardest thing about lightning, it always boils down to "is the assumption that you're able to settle on-chain in time holds"?
11:44 < t-bast> But there's clearly no silver bullet there
11:45 < t-bast> We'll have to deal with this with trade-offs (as always) :)
11:45 < ariard> t-bast: even worst you have to consider systematic risks like mempool getting full, people starting to preempttively close channels
11:45 < ariard> fees getting higher, nodes running out of bumping utxos, closing more channels...
11:45 < cdecker> Agreed, and I think it's ok to set up some (explicit) assumptions for our security model
11:47 < ariard> side-note: I do have a gist listing tx-relay jamming vulns if interested: https://gist.github.com/ariard/7e509bf2c81ea8049fd0c67978c521af
11:47 < ariard> and the kind of works required core-side to patch them 
11:48 < t-bast> But don't get me wrong, it's great to be working on these, it's a net improvement from the standard commitment format
11:48 <+roasbeef> t-bast: def
11:48 < ariard> cdecker: it's hard to modelize, you have to adapt to your counterparty behavior which might not be known because mempools aren't global
11:50 < cdecker> Agreed, we should come up with a good attacker model, explicitly write it down, and then work up to that line, but not beyond
11:51 < ariard> cdecker: yeah I should motivate myself to write such paper this year...already thought about it
11:52 < cdecker> Hehe, not saying it has to be you, but you're the one whose most knowledgeable about these pitfalls
11:52 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
11:52 < t-bast> Back to something you mentioned roasbeef about looping out to help that scenario: it would be very cool if you could, via a lightning payment, directly bump an anchor. You would ask the loop server to do a swap out to your address, adding a specific anchor as input. Does that make sense?
11:53 < cdecker> Nice idea ^^
11:53 < ariard> t-bast: it's third-party security like watchtower but yes interesting to explore
11:53 < t-bast> You could use off-chain funds to make up for your lack of utxos
11:53 < cdecker> I think we were playing with a couple of things in that direction, with the PSBT support
11:54 < bitconner> t-bast: yes that's correct
11:54 <+roasbeef> t-bast: yeah that works rn w/ our loop out as implemented: you can sweep the HTLC directly into your bump transaction 
11:54 <+roasbeef> the daemon doesn't do so yet, but as we can package loop+lnd in a single binary it can be adapted to do so easily or even remotely if needed since you can do custom signing w/ the lnd APIs 
11:54 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
11:55 <+roasbeef> so I like it as a fall back plan if w/e else fails before that 
11:55 < t-bast> right, you mean that you do a normal loop out then add this (new) utxo of yours as input to your HTLC tx
11:55 <+roasbeef> mhmm, seems like you want more coordination to save that exta transaction (?) 
11:55 -!- ThomasV__ is now known as ThomasV
11:55 < ariard> or as a CPFP to bump your commitment but you're relying on good confirmation time of your loop out provider
11:55 < cdecker> Could this be short-circuited: have the loop server provide a single-sig input (and corresponding change output) that can then be attached to my close?
11:56 <+roasbeef> well you can use CPFP to anchor down that swap transaction (that one that makes the HTLC), so you can help accelerate the conf ariard  
11:56 < t-bast> cdecker: that's the kind of thing I had in mind
11:56 < cdecker> Gotcha
11:56 <+roasbeef> cdecker: yeh I think so, but then they need to reserve that utxo for your in a sense 
11:56 < cdecker> Right, that's a downside
11:56 <+roasbeef> rn it uses RBF to essentially "add more ppl" to a bastch continually until one of them confirms 
11:57 <+roasbeef> batch*
11:57 < cdecker> We'd also need to communicate how much of my loop out ought to be in fees
11:57 <+roasbeef> on the other end, splicing helps w/ this kinda, as you can move funds from a channel, tho you need a solution still when you only have that one channel left 
11:57 < cdecker> (and single-sig isn't safe either: miners can strip the payload tx, and just keep the fee payer part)
11:57 < ariard> roasbeef: if it's a batch tx it's better to wait for confirmation otherwise a batch member can mempool-junk its utxo to prevent using yours as an input for a CPFP
11:57 < t-bast> yes, do you have a way to trustlessly ensure the loop server uses a given feerate?
11:58 <+roasbeef> t-bast: the on-chain fee rate for the transaction creating the swap htlc? 
11:58 < t-bast> yes, it feels to me you have to trust the loop server to use the right feerate
11:58 <+roasbeef> as defined not really, but at the service level we have a few diff "speeds" ppl can choose from which affects the end fee 
11:58 < t-bast> I don't see how you could force him to use an agreed upon feerate
11:59 < bitconner> if the utxo was reserved in a multisig setup you could do that
11:59 < t-bast> but it's based on trust? Or can the sender verify the tx feerate before sending the lightning payment?
11:59 <+roasbeef> yeh not really, but you can accelerate it somewhat since you can anchor down w/e is there to use to pay for your input 
11:59 < bitconner> so the user knows the fee rate being used bc they also have to sign
11:59 -!- ThomasV_ [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
11:59 <+roasbeef> t-bast: the fee rate as defined rn yeh, also we're free to modify that fee rate in order to get a conf in 
11:59 < cdecker> Well, we could also send the close to the loop server and ask it to make it whole, but that's the same as the taxi.* stuff we have on liquid
11:59 <+roasbeef> the swap serve is also incentivzed to get things confirmed on time as there're time lock risks as a normla htlc 
11:59 < ariard> roasbeef: you have to trust the server, it might have already double-spend the swap but you don't the pinned copies in your local mempool?
12:00 <+roasbeef> ariard: why would it do that? it's sellilng a service -- any other party in the batch can also anchor down the swap transaction to accelerate their loops
12:01 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
12:01 -!- ThomasV_ is now known as ThomasV
12:01 <+roasbeef> or maybe i'm not following, you're saying it is itself onthe other side of the channel and wants to block you? 
12:01 < ariard> roasbeef: security-wise, you have to consider the service as a third-party which might be also your attacker, economic-wise such service won't hold for sure
12:01 <+roasbeef> w/ the way it's impl'd it wouldn't even know that it's you really, each user has an LSAT that identifiers them that they can rotate out if they want 
12:01 < ariard> roasbeff: yes it might be itself the other side of the channel
12:02 <+roasbeef> but it's possible, but prob not something most ppl need to fear
12:02 < ariard> in practice, I agree it's relying on reputation
12:02 <+roasbeef> prob greater risks ppl need to watch out for that're more direclty under their control 
12:03 <+roasbeef> ppl can also make their own, the core mechanic of a sub-swap is pretty simple, but we've added on a lot over time to enchance it and add other uses cases/flows, etc, etc 
12:03 < ariard> well I think the initial discussion was using loop as bumping utxo providers for mobile wallets
12:03 <+roasbeef> imo it's better for routing nodes, mobile wallets aren't really at risk 
12:03 < ariard> mobile wallets aren't designed for high-stakes anyway so they should be fine relying on such loop services
12:04 <+roasbeef> ariard: yeh, should be pretty smol amounts, tho from exp ppl really just like to YOLO into things xD 
12:04 < t-bast> yeah and they'll just end up having txs that are painful to confirm because they need to find utxos to bump, but they shouldn't lose any money
12:04 < ariard> I expect big routing nodes doing their own bumping utxos management...
12:04 <+roasbeef> and sudden price increases can change your risk profile also lol
12:04 < ariard> ...once we know what does it mean :p
12:04 < t-bast> we've seen crazy amounts in mobile wallet channels...#reckless
12:05 <+roasbeef> t-bast: yeh same, then ppl forget it's there and send in support tickets years later once it's worth 10x 
12:07 < t-bast> I had a lightning channel in 2018, I've lost my backups, my seed, my phone and the keys to my appartment, but can you help me recover my funds?
12:07 < t-bast> Those damn boating accidents...
12:07 <+roasbeef> kek
12:07 < ariard> t-bast: sure just give me the property title of your appartment 
12:07 < cdecker> I had a channel bakc in 2005, can you help me?
12:08 <+roasbeef> yeh we officially shut down that old wallet mobile wallet we made this year, have been dealing w/ a lot of those...
12:09 < cdecker> Yeah, lightning could be so cool, if only there weren't these pesky users
12:09 < cdecker> xD
12:09 < t-bast> :D
12:09 <+roasbeef> any other major things on the agenda ppl wanted to get to?
12:09 < ariard> I've already met LN users in real life, they're good people I swear!
12:10 < t-bast> We're already over 1 hour, I don't think we'll start another topic, shall we keep chatting a bit and then close today's meeting?
12:11 < t-bast> I liked that utxo / bumping discussion, I think it's really helpful
12:11 < ariard> have a look on the bitcoin-dev ML, darosior has started a topic around HW support for L2
12:11 < t-bast> right, that's a fun one
12:11 < ariard> and gathering a list of grievances to HW vendors
12:12 < t-bast> HW lightning wallets are another way to open a can of worms
12:12 <+roasbeef> yeh pretty big problem space, but also depends on what you're after...
12:12 <+roasbeef> stuff like being able to *fund* a channel using a HW is pretty much here using PSBT stuff 
12:12 < t-bast> I completely agree with zman that they're not a silver bullet as you need a separate solution to monitor the chain
12:12 < ariard> it's more signing channel operations in a trusted enclave
12:12 <+roasbeef> any other thing you need to come to terms w/ how much auto signing and how much verification you can really do if it's about also signing commitment states 
12:13 < ariard> yeah lightning is harder than vaults due to states
12:13 <+roasbeef> yeh that's a whole thing in itself 
12:14 <+roasbeef> just inserting some validation proxy in front of the signer prob gets you a lot in practice 
12:14 < ariard> devrandom has pretty good documentation on trustless lightning nodes: https://gitlab.com/lightning-signer/docs
12:14 <+roasbeef> but also depends on what kinda of security model yuo're interested in as well 
12:14 < ariard> "If you're main lightning node is compromised are you losing funds"
12:15 < ariard> ideally you might have a number of tower replicas, you're safe if at least one isn't compromised
12:15 < ariard> where compromised is extensively defined as do you still have acces to the chain
12:16 < t-bast> does their proposed solution also encompass the bitcoin wallet?
12:16 < t-bast> I'm thinking in particular for anchor outputs and swaps
12:17 < ariard> wdym?
12:17 < t-bast> It's really hard to a HW wallet to verify you're an attacker is not making it sign txs/htlcs that exfiltrate funds
12:17 < t-bast> *to verify an attacker [...]
12:17 < ariard> it's really hard I agree but you assume access to a UTXO set oracle you can implement something like this
12:18 < t-bast> The flow of funds that must be enforced by the HW wallet is very much non-trivial once it has to deal with both on-chain and off-chain funds
12:18 < ariard> in the far shiny future I hope to have core's validation engine running attached to a L2 signer inside a HSM
12:18 < t-bast> And it has to deal with both on-chain and off-chain, otherwise you can exploit channel close to steal funds
12:18 < ariard> just need a lot of refactoring
12:19 <+roasbeef> t-bast: yeh at that point it's not really a HW wallet anymore, just some like "isolated" process somewhere 
12:19 <+roasbeef> this kinda leads to "the LN impls is *in* the hardware wallet jajaja" 
12:19 <+roasbeef> (yes we laugh in spanish now) 
12:20 < t-bast> haha yes, but if you want the HW to be useful, it has to implement a lot of lightning logic
12:20 < t-bast> if it's only securing your keys, it's not really securing your funds, it's easy to still exfiltrate funds by making it sign whatever
12:20 < ariard> really likely you need to rewrite a micro lightning state machine in your hardware-something
12:20 <+roasbeef> yeh theoretically it could keep track of things like all pending htlcs to validate if something is a forawrd or payment, etc 
12:20 <+roasbeef> create the oniion blob so it knows where the payment is actually going, etc, etc 
12:21 < ariard> if you're a routing node, just always incrase your balances, accounted holistically
12:21 < t-bast> isn't that what devrandom is doing with this project?
12:21 < ariard> roasbeef: you don't care where the payment is going if you're a routing
12:21 < ariard> if you're a sender get user input to authenticate the destination
12:21 <+roasbeef> ariard: you do care that it's "balanced" tho, and not an attempt to send it all elsewhere 
12:21 < t-bast> always increase your balance doesn't work, as lightning nodes may lose money in case too many channels close and they don't collect enough routing fees
12:22 <+roasbeef> i think we're saying the same thing tho 
12:22 < ariard> yes we're saying the same :)
12:22 < ariard> t-bast: yes we're have already landed few chunks in RL
12:23 < ariard> t-bast: this is a different problem IMO, the economic efficiency of your lighting operations
12:23 < ariard> your security cost shoud be part of your ops cost
12:23 < t-bast> yeah but that means your HW cannot use that as a protection to decide whether or not to sign txs
12:23 < t-bast> because it won't work as soon as you're not economically balanced
12:23 < t-bast> and if at that point your HW refuses to sign txs, you're even more screwed
12:24 < ariard> t-bast: in that case sign the txn, the not economically-balanced should have been evaluated at channel opening
12:24 < t-bast> still a lot of fun stuff to figure out xD
12:24 < ariard> okay have to go but was a good meeting, see you :)
12:24 < t-bast> I've gotta go, thank you guys for these discussions!
12:25 < t-bast> See you next time!
12:25 < t-bast> #endmeeting
12:27 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
12:28 <+roasbeef> t-bast: btw the bot never came back after that one time someone "accidentally killed" it? 
12:28 <+roasbeef> does it need to be hosted somewhere else? 
12:30 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
12:33 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Quit: The Lounge - https://thelounge.chat]
12:33 -!- t-bast [~t-bast@5.50.145.86] has quit [Ping timeout: 256 seconds]
12:33 -!- Guest81 [3344c770@gateway/web/cgi-irc/kiwiirc.com/ip.51.68.199.112] has joined #lightning-dev
12:35 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has joined #lightning-dev
12:54 -!- kexkey [~kexkey@static-198-54-132-90.cust.tzulo.com] has joined #lightning-dev
13:24 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Ping timeout: 256 seconds]
13:27 -!- Guest81 [3344c770@gateway/web/cgi-irc/kiwiirc.com/ip.51.68.199.112] has quit [Quit: Connection closed]
13:29 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev
13:51 -!- proofofkeags_ [~proofofke@2601:280:c280:e500:4c74:efe5:2560:74e0] has joined #lightning-dev
13:54 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 256 seconds]
14:33 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 256 seconds]
15:21 -!- rdymac [uid31665@gateway/web/irccloud.com/x-egpflvuxyltuygug] has quit [Quit: Connection closed for inactivity]
15:34 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
15:36 -!- proofofkeags_ [~proofofke@2601:280:c280:e500:4c74:efe5:2560:74e0] has quit [Ping timeout: 264 seconds]
15:36 -!- proofofkeags_ [~proofofke@2601:280:c280:e500:fd6f:314b:42b9:e0a8] has joined #lightning-dev
15:38 -!- proofofkeags__ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has joined #lightning-dev
15:39 -!- proofofkeags [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 272 seconds]
15:41 -!- proofofkeags_ [~proofofke@2601:280:c280:e500:fd6f:314b:42b9:e0a8] has quit [Ping timeout: 264 seconds]
15:46 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has quit [Disconnected by services]
15:48 -!- vtnerd [~vtnerd@50-82-248-114.client.mchsi.com] has quit [Ping timeout: 256 seconds]
15:48 -!- vtnerd [~vtnerd@50-82-248-114.client.mchsi.com] has joined #lightning-dev
15:50 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Ping timeout: 272 seconds]
15:52 -!- jonatack [~jon@88.124.242.136] has quit [Ping timeout: 256 seconds]
15:53 -!- jonatack [~jon@109.202.107.5] has joined #lightning-dev
15:55 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
15:57 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev
15:58 -!- proofofkeags__ [~proofofke@c-73-34-43-4.hsd1.co.comcast.net] has quit [Ping timeout: 264 seconds]
16:00 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #lightning-dev
16:15 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Remote host closed the connection]
16:16 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev
16:27 -!- laptop__ [~laptop@ppp-2-180.leed-a-1.dynamic.dsl.as9105.com] has joined #lightning-dev
16:29 -!- laptop_ [~laptop@ppp-2-180.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 256 seconds]
16:59 -!- proofofkeags__ [~proofofke@174-29-3-187.hlrn.qwest.net] has joined #lightning-dev
17:15 -!- r1clas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 260 seconds]
17:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
17:30 -!- queip [~queip@unaffiliated/rezurus] has quit [Remote host closed the connection]
17:31 -!- queip [~queip@unaffiliated/rezurus] has joined #lightning-dev
17:45 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
17:57 -!- laptop__ [~laptop@ppp-2-180.leed-a-1.dynamic.dsl.as9105.com] has quit [Ping timeout: 264 seconds]
18:35 -!- bitromortac [~admin@gateway/tor-sasl/bitromortac] has joined #lightning-dev
18:38 -!- musdom [~Thunderbi@202.184.0.102] has joined #lightning-dev
18:39 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Ping timeout: 264 seconds]
18:39 -!- bitromortac_ [~admin@gateway/tor-sasl/bitromortac] has quit [Ping timeout: 268 seconds]
18:44 -!- ddustin [~ddustin@unaffiliated/ddustin] has joined #lightning-dev
18:49 -!- lucen[m] [lucenmshrm@gateway/shell/matrix.org/x-qmgtmiruywlbnxvz] has joined #lightning-dev
19:09 -!- ddustin [~ddustin@unaffiliated/ddustin] has quit [Remote host closed the connection]
20:03 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
20:34 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]
20:35 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Ping timeout: 246 seconds]
20:39 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev
20:58 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has quit [Ping timeout: 246 seconds]
21:02 -!- sh_smith [~sh_smith@cpe-172-88-21-24.socal.res.rr.com] has joined #lightning-dev
22:16 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
22:19 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Ping timeout: 268 seconds]
22:21 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has joined #lightning-dev
22:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
23:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 265 seconds]
23:20 -!- ThomasV [~ThomasV@unaffiliated/thomasv] has quit [Ping timeout: 264 seconds]
23:29 -!- musdom1 [~Thunderbi@202.184.0.102] has joined #lightning-dev
23:31 -!- musdom [~Thunderbi@202.184.0.102] has quit [Ping timeout: 256 seconds]
23:31 -!- queip [~queip@unaffiliated/rezurus] has quit [Remote host closed the connection]
23:31 -!- musdom1 is now known as musdom
23:31 -!- queip_ [~queip@unaffiliated/rezurus] has joined #lightning-dev
23:33 -!- queip_ is now known as queip
23:46 -!- t-bast [~t-bast@5.50.145.86] has joined #lightning-dev
23:56 -!- yzernik_ [~yzernik@c-67-169-76-240.hsd1.ca.comcast.net] has joined #lightning-dev
23:59 -!- yzernik [~yzernik@c-67-169-76-240.hsd1.ca.comcast.net] has quit [Ping timeout: 272 seconds]
--- Log closed Tue Jan 19 00:00:25 2021