--- Log opened Mon Nov 11 00:00:04 2019
00:00 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
00:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]
00:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev
00:39 < aj> rusty: passing sigs on also forces you to keep the R value the same, so you just correlate on that, i think
00:39 < aj> rusty: haven't had any luck making pairing be helpful either
00:46 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 268 seconds]
00:49 -!- marcoagner [~user@2001:8a0:6a5f:5700:7bb3:6296:d274:7295] has joined #lightning-dev
01:05 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]
01:09 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #lightning-dev
01:29 -!- openoms [~quassel@185.174.156.219] has joined #lightning-dev
01:38 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 276 seconds]
01:45 -!- ViresNumeris21 [~viresnume@gateway/tor-sasl/viresnumer21] has joined #lightning-dev
02:29 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #lightning-dev
02:42 -!- yaslama [~yaslama@bzq-218-78-150.red.bezeqint.net] has quit [Remote host closed the connection]
02:46 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 276 seconds]
02:50 -!- yaslama [~yaslama@bzq-218-78-150.red.bezeqint.net] has joined #lightning-dev
02:51 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev
03:41 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:c4e0:5e7b:afa3:c47f] has joined #lightning-dev
03:41 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:c4e0:5e7b:afa3:c47f] has quit [Client Quit]
03:41 -!- diogosergio [~diogoserg@212.36.34.126] has joined #lightning-dev
03:48 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
03:50 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has joined #lightning-dev
03:54 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has quit [Client Quit]
04:05 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
04:14 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has joined #lightning-dev
04:19 -!- diogosergio [~diogoserg@212.36.34.126] has quit [Ping timeout: 240 seconds]
04:20 -!- diogosergio [~diogoserg@212.36.34.126] has joined #lightning-dev
04:28 -!- diogosergio [~diogoserg@212.36.34.126] has quit [Ping timeout: 265 seconds]
04:29 -!- diogosergio [~diogoserg@212.36.34.126] has joined #lightning-dev
04:32 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has quit [Quit: Sleep mode]
04:39 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has joined #lightning-dev
04:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
04:59 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
05:10 -!- ViresNumeris21 [~viresnume@gateway/tor-sasl/viresnumer21] has quit [Quit: Leaving]
05:28 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has quit [Quit: Sleep mode]
05:29 -!- arij [uid225068@gateway/web/irccloud.com/x-scvxljhpoapxacek] has quit [Quit: Connection closed for inactivity]
05:49 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has joined #lightning-dev
05:56 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 246 seconds]
06:07 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #lightning-dev
06:15 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 265 seconds]
06:17 -!- shesek [~shesek@unaffiliated/shesek] has quit [Quit: Leaving]
06:17 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
07:15 -!- michaelfolkson [~textual@2a00:23c5:be04:e501:8c35:5b5d:b899:25b] has quit [Quit: Sleep mode]
07:52 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
08:09 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
08:11 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
08:43 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #lightning-dev
08:45 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
08:45 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
08:45 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
08:47 -!- michaelfolkson [~textual@46.233.77.109] has joined #lightning-dev
08:47 -!- michaelfolkson [~textual@46.233.77.109] has quit [Client Quit]
08:49 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 265 seconds]
09:03 -!- whitez00 [whitez00@gateway/vpn/protonvpn/whitez00] has joined #lightning-dev
09:16 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Quit: jonatack]
09:28 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev
09:29 -!- diogosergio [~diogoserg@212.36.34.126] has quit [Ping timeout: 268 seconds]
09:30 -!- joosth [~joost@142.93.140.5] has left #lightning-dev []
09:33 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #lightning-dev
09:39 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
09:44 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
09:49 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 240 seconds]
09:55 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
10:00 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 265 seconds]
10:10 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
10:22 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
10:23 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
10:24 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
10:25 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds]
10:43 -!- tuxcanfly [~tuxcanfly@68.183.231.167] has joined #lightning-dev
10:52 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
10:54 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has joined #lightning-dev
10:55 -!- alko [~alko@cpe-85-10-28-138.static.amis.net] has quit [Remote host closed the connection]
10:55 -!- alko [~alko@cpe-85-10-28-138.static.amis.net] has joined #lightning-dev
10:55 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
10:59 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
11:00 -!- hiroki_ [6f5923d6@pl94934.ag2001.nttpc.ne.jp] has joined #lightning-dev
11:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
11:00 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has joined #lightning-dev
11:00 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
11:02 -!- ysangkok [janus@anubis.0x90.dk] has joined #lightning-dev
11:03 < niftynei> are we having a spec meeting today?
11:03 < cdecker> We should, yes :-)
11:03 < rusty> niftynei: I hope so!  Ofc DST events might have shaken some people off!
11:03 < niftynei> it's also a holiday in the USA
11:03 < cdecker> Welp, c-lightning team present, might as well decide on all pending things :-)
11:04 < BlueMatt> I'm here
11:04 < sstone> Hi everyone!
11:04 < BlueMatt> so that makes two "implementations", right :p
11:04 < bitconner> hola!
11:04 < rusty> niftynei: oh, ofc, I forgot!
11:04 < niftynei> i see a ACINQ o.O, that makes 3 ;)
11:04 < joostjgr> hi
11:04 < cdecker> And that's the fourth :-)
11:05 < cdecker> Congrats on the WhatSat PoC joostjgr ^^
11:05 < bitconner> joostjgr on irc for real now :)
11:06 < joostjgr> yes, needed to proof i can still do it after my last usage 15 years ago :)
11:06 < rusty> Next meeting on WhatSat! :)
11:06 < niftynei> Proof of Chat
11:06 < joostjgr> I'm surely in for that, haha
11:07 < cdecker> joostjgr: so that's a feature request: implement group chat ^^
11:07 < bitconner> wen gifs
11:07 < joostjgr> there are more weekends coming, so who knows
11:08 < joostjgr> ok, can we add a (really) variable onion feature bit for gifs :)
11:08 < niftynei> getting everyone to switch chat platforms, now that's what i'd call an 'interactive group challenge'
11:08 < joostjgr> no need to do further obfuscation, because it is so variable anyway
11:08 < cdecker> lol, let's rather have a chunking mechanism for files joostjgr 
11:08 < joostjgr> every switch on the internet will ask for an htlc to get out of bed
11:09 < bitconner> cdecker: that's what mpp is for
11:09  * rusty gets back to work on that up-front payment proposal before we start streaming video over LN...
11:09 < rusty> Who's up to chair, BTW?
11:09  * bitconner gets back to work on hornet so we can have a real data layer
11:09 < BlueMatt> rusty: sounds like you are, since you asked first! :p
11:10 < rusty> BlueMatt: I chaired last time, though.
11:10 < lndbot> <johanth> this bridge working now?
11:10 < bitconner> johanth: yes
11:10 < lndbot> <johanth> Ok nice
11:11 < bitconner> okay i will chair
11:11 < rusty> bitconner: thanks!
11:11 < bitconner> #startmeeting
11:11 < lightningbot> Meeting started Mon Nov 11 19:11:20 2019 UTC.  The chair is bitconner. Information about MeetBot at http://wiki.debian.org/MeetBot.
11:11 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
11:12 < bitconner> okay first up
11:13 < bitconner> #topic flat features https://github.com/lightningnetwork/lightning-rfc/pull/666
11:13 < bitconner> i think this is pretty much gtg
11:13 < rusty> Ack!
11:13 < bitconner> mostly touch ups, are there any concerns about overall design?
11:14 < bitconner> i implemented this last week and it was quite nice to have only one namespace
11:14 < rusty> Just acked t-bast's minor touch-ups, too.
11:15 < rusty> bitconner: yeah, it's nice to remove code!
11:15 < bitconner> rusty: to clairfy, invoice features have the same namespace as everything eles, yes?
11:16 < rusty> bitconner: yep, though the actual implementation of that is in the MPP PR IIRC.
11:16 < bitconner> awesome! i'm sold
11:16 < bitconner> ack
11:17 < rusty> Yay!
11:17 <+roasbeef> yeh in the end, just nice to have one namespaces, we could've used a more compact encoding for feature bits at the start, but kinda of too late to apply one to the existing fields 
11:18 < bitconner> sstone: thoughts?
11:19 < cdecker> Pretty much, makes things just context-free and easier to interpret :-)
11:19 < sstone> ack from us too :)
11:19 < bitconner> cool :)
11:19 < bitconner> #action rusty to touch up lingering comments
11:20 < bitconner> #agreed flat feature design is solid
11:20 < bitconner> nice worky rusty!
11:20 < bitconner> #topic base amp https://github.com/lightningnetwork/lightning-rfc/pull/643
11:21 < bitconner> primary discussion seems to be around signaling and feature bits now?
11:22 < rusty> Yeah, I'm going through them.
11:22 < rusty> I don't think we should require basic_mpp support for secret support.
11:23 < rusty> Hence we need separate BOLT11 features, one to say "I support MPP" and one to say "I support/need secret".
11:24 <+roasbeef> it's possible to have one feature bit, then clients just cancel back if they ever get a partial payment when they can't handle combination 
11:24 < bitconner> i would prefer two distinct feature bits to overloading var_onion_optin :)
11:25 <+roasbeef> so one bit for I can combine and the other for include the payment addr? 
11:25 < bitconner> yep
11:25 < joostjgr> i prefer just one feature bit that signals it all: tlv+mpp+secret
11:26 < cdecker> Agreed, returning an error and then having to retry is really disruptive
11:26 < sstone> joostjgr: but there are use cases for secret without mpp
11:26 < niftynei> joostjgr, that would require supporting all 3 simultaenously, no?
11:26 < cdecker> We have the feature bits for something, let's make use of them
11:26 < rusty> The idea of feature bits is fast failure: if you don't understand one, you can tell user immediately "I don't understand feature 12!" and they can google etc.
11:26 < joostjgr> if we are all agreeing that we implement tlv+mpp+secret, why is that flexibility needed. perhaps we ain't gonna need it
11:27 < joostjgr> the test matrix is bad enough already
11:28 < rusty> joostjgr: there are other implementations too...  I mean, I'm happy to combine, but since we're going to make secret compulsory as fast as we can, that implies MPP will be compulsory.
11:29 < bitconner> compulsory mpp still seems kinda vacuous to me
11:29 <+roasbeef> sstone: seems those cases can just make the total amount the same as their first payment, so it's single shot 
11:29 < cdecker> joostjgr: the compulsory feature bits can help reduce the test matrix again
11:29 < rusty> bitconner: I mean, you'll have to support it, not that they'll have to use it (though such signalling is possible, if you don't have suff incoming capacity in a single channel)
11:30 <+roasbeef> side point on naming: the what's called the payment secret right now isn't reaaally secret in that's it's in the invoice, ppl post invopies, etc on twitter all the time. imo a better name is payment addr 
11:31 < rusty> roasbeef: payment nonce?  People love reusing addresses :)
11:31 < cdecker> Ouch, calling it an addr is worse
11:31 < cdecker> Agreed that `nonce` is better here
11:31 < rusty> "Paymenbeef"!
11:31 < niftynei> payment noise?
11:32 < bitconner> it's only a nonce for one-time invoices
11:32 < cdecker> reference?
11:33 < bitconner> the amp proposal will include the payment addr/nonce/secret on each payment attempt
11:33 < niftynei> that hurts decorrelation, no?
11:33 < bitconner> nope bc it's only in the final hop's payload
11:33 < niftynei> kkk
11:34 < bitconner> in the amp case it's more like a routing/account number
11:34 <+roasbeef> can be used to identify stuff like subscription payments or exchange deposits 
11:34 < cdecker> Well, let's debate naming on the PR, and continue here about the concept :-)
11:34 < rusty> payment_atgnwt (all the good names were taken).
11:34 < joostjgr> i favor payment address. it is an id that means something to the receiver
11:34 < bitconner> lol
11:34  * cdecker will veto address
11:34 < bitconner> #action defer naming of payment_atgnwt to the pr
11:34 < cdecker> :-)
11:35 < joostjgr> another issue is the timing, although that isn't really a protocol thing. "SHOULD wait for at least 60 seconds after the initial HTLC." we are also thinking about resetting the timer with every set htlc that comes in
11:35 -!- arij [uid225068@gateway/web/irccloud.com/x-kkdsmkmwjaelsttj] has joined #lightning-dev
11:36 < rusty> joostjgr: yeah, I wasn't sure about that, which is why it's specified so vaguely.  Resetting o every htlc would meet that requirement.
11:36 < joostjgr> ah, "at least"
11:36 < joostjgr> we can also leave it vague indeed and figure it out in practice
11:36 < rusty> joostjgr: agreed!
11:36 < rusty> (That makes us look smart, too :)
11:37 < bitconner> re: feature bits, do we agree on not overloading `var_onion_optin`?
11:37 < cdecker> Isn't timing an implementation detail? We'll try to pay as fast as possible, if we can't complete in whatever the recipient thinks is acceptable we can't pay
11:37 < rusty> Back to feature bits, we need *some* feature bit so we can make it compulsory later to force secret use, right?
11:37 < cdecker> If you reset the timer on each HTLC you are basically replicating the slow loris attack...
11:38 < bitconner> rusty: yes
11:38 <+roasbeef> would need to have additional mitigations ofc, wouldn't consier this an exhuastive list, just as we don't enumerate all the possible things that nodes need to defend against in the spec cdecker  
11:38 < rusty> I chose to abuse var_onion_optin, which is not exposed in BOLT11 so far, and avoided adding YA feature bit.  Happy to revisit.
11:39 < cdecker> roasbeef: but why specify that particular detail then?
11:39 < rusty> (Since eventually, secret will be compulsory on final hop, as will var_onion_optin, dammit...)
11:39 < joostjgr> cdecker: if the goal is to plug up the commitment tx slots, there are still ways to do that without a resetting timer
11:39 <+roasbeef> cdecker: so you'd rather specify no timeout precautions? 
11:40 < cdecker> Yep, at least that doesn't suggest that it's in any way covering all issues
11:40 < rusty>       - MUST fail all HTLCs in the HTLC set after some reasonable timeout.
11:40 < rusty>         - SHOULD wait for at least 60 seconds after the initial HTLC.
11:40 < rusty> ^ This pretty much covers it, without being prescriptive about stuff we don't know yet.
11:40 < bitconner> rusty: indeed, tho still feels like we should keep them isolated, o/w it's kinda confusing that certain features have "side-effects" if you will
11:41 < bitconner> unintended* side-effects
11:41 < cdecker> Awesome the spec already covers slow loris then, no need to add hypothetical additional things like resetting a timer and then explaining the fallout that might ensue :-)
11:42 < rusty> bitconner: yeah, I had to invent an otherwise-useless-who-cares mpp feature to use in BOLT11 to indicate support already, in the assumption that we wouldn't be forcing final nodes to support.
11:43 < rusty> We can add a specific "payment_atgnwt_required" feature instead?
11:43 < rusty> s/required//
11:43 < bitconner> +1
11:44 < bitconner> so then we have payment_atgnwt and multi_path bits?
11:44 < rusty> That is basically only important in bolt11, but hell, put it everywhere else so we can measure adoption.  And it means "mpp and secret" or just "secret" and have YA feature for mpp?
11:44 < joostjgr> i still think the maximum number of new feature bits per spec PR should be 1
11:44 < rusty> Yeah, I think we keep mpp bit.  I like the separation, since I've implemented secret and not mpp so far.
11:44 -!- jnewbery [~john@4.53.92.114] has joined #lightning-dev
11:45 < rusty> joostjgr: nice rule :)
11:45 < bitconner> its usefull on node announcments if you want to do keysend and don't have an invoice
11:45 < rusty> bitconner: but then you don't have a secret either?
11:45 < bitconner> sender generates it
11:45 < bitconner> or you mean payment secret?
11:45 < rusty> bitconner: yeah.'
11:46 < bitconner> payment secret isn't really required for keysend because theree's no invoice to probe
11:46 < bitconner> so sender just picks a random one
11:46 < rusty> bitconner: yeah, so knowing it requires payment_atgnwt doesn't really help does it?
11:46 < bitconner> if someone tries to probe ahead of a keysend payment then they are just donating to everyone they try
11:46 < bitconner> rusty: i was referring to mpp
11:47 < rusty> bitconner: oh, mpp right!  Yeah, that makes sense.
11:47 < bitconner> but in general, invoice features are useful on the node ann for cases like keysend
11:48 < rusty> OK, so separate feature bits.  Since that PR hasn't been rebased, the feature numbers are wrong.  Shall we allocate 14/15 to payment_atgnwt and 16/17 to base_mpp?
11:48 < bitconner> sgtm
11:49 < bitconner> #action rusty to update pr and assign 14/15 for payment_thing, 16/17 to base_mpp
11:49 < cdecker> ack
11:49 < rusty> joostjgr: would you prefer me split the PR into two as well?  Back into one for payment_notaddress and one for base_mpp?
11:49 <+roasbeef> imo there's enough momentum on the single PR to warrant just keeping it unified 
11:49 < joostjgr> no, that will be the same outcome :)
11:50 < bitconner> ack for combined pr, there is already light in this tunnel :)
11:50 < rusty> joostjgr: phew, yeah, I agree they're kinda tangled.
11:50 < joostjgr> rusty: i understand that you now have secret and not yet mpp and want to release perhaps, but this temp. situation will live on for quite some time on the network
11:51 < joostjgr> i think there are costs associated with that
11:51 < rusty> joostjgr: Naah I'll never do a release with just one, that would suck,
11:51 < rusty> joostjgr: but it's nice for testing to do one at a time
11:51 < joostjgr> then i definitely wouldn't split the bits
11:51 < joostjgr> but i guess i am alone with my opinion
11:52 < bitconner> why not? payment_thing is low hanging fruit that has tangible security/privacy benefits
11:52 < joostjgr> test matrix. if we never release them separately anyway
11:52 < rusty> joostjgr: last time we didn't split the bits, we had a bug which made things nasty; we said we'd go more finegrained so we could disable one thing if necessary.
11:52 < joostjgr> ok
11:53 < bitconner> ternary features ftw
11:53 < joostjgr> do we have time for a quick anchor state of things?
11:53 < bitconner> sure
11:54 < bitconner> #topic anchor outputs https://github.com/lightningnetwork/lightning-rfc/pull/688
11:54 < joostjgr> i've summarized the delta in the pr description. anyone seeing something there that doesn't look right?
11:55 < joostjgr> the discussion on update_fee yes/no ended kind of open. but it seems that there is no perfect solution atm and that with update_fee we at least have a better chance at getting the commit conf'ed
11:56 < rusty> It covers everything.  I'm a bit reluctant to leave update_fee, but OTOH it's already existing logic (though we've seen more bug reports of bag signatures recently, so maybe it's just damn toxic).
11:56 < ariard> but if you use update_fee so do not use anchor outputs
11:57 < joostjgr> our idea is that we initially target an emergency exit
11:57 < joostjgr> so keep everything as is and if an important confirm is needed, you can manually anchor down the tx
11:57 < ariard> I mean combo update_fee + anchor outputs is only useful if you bump feerate of commitment tx enough to get in mempool
11:58 < ariard> but if it's enough to get in, it's really likely your fee estimator give you a feerate to get in the confirme-soon tier
11:58 < joostjgr> next steps are to automate that process and go to lower commit_tx fees
11:58 <+roasbeef> not, this is about getting into the block 
11:58 <+roasbeef> ariard: your confidence in fee estimators surprises me...
11:58 <+roasbeef> idea for this is to just low ball, then bump based on your time prefernce 
11:58 <+roasbeef> forget the crowd
11:59 < ariard> roasbeef: but the whole point of update_fee is to trust fee_estimator
11:59 <+roasbeef> but ofc, you may also have incoming HTLCs as well, so that's your other main signal 
11:59 <+roasbeef> update_fee becomes relaxed from: enough to get into the next block or soon, to: enough to get into the mempool 
11:59 <+roasbeef> later on once we have full packaged relay, we can phase it out possibly (update_fee) 
12:00 < ariard> agree it's a relaxation of update_fee requirement, but it seems a really slight coverage
12:01 < ariard> and going to be useless once package relay is there
12:01 <+roasbeef> it's a big deal on practice for deployed implementations, fees on idle commitments can now be much lower, no more users complaining about how most of their channel is somehow allocated for fees 
12:01 < BlueMatt> but the issue is that update_fee doesnt do anything *today*
12:01 <+roasbeef> BlueMatt: how so?
12:01 < BlueMatt> and there's only a very narrow band of fee changes where it makes sense
12:01 <+roasbeef> ariard: have any notion on how far along the dev of that is? seems like a long ways away, and this is an issue today 
12:01 < BlueMatt> cause its not practically enforced by a counterparty, and fees swing wildly from the time you send a payment to a month later
12:02 < BlueMatt> so it only makes sense if, eg, a feerate goes up some small percentage from the time you do a commitment update to when you want to broadcast
12:02 < ariard> roasbeef: https://github.com/bitcoin/bitcoin/pull/16401 
12:02 < BlueMatt> which is....a completely useless requirement
12:02 <+roasbeef> dunno what you mean by it isn't enforced, the rbf blocking stuff? 
12:02 < ariard> IMO can go in 0.20, need more review (on DoS vectors) but general mechanism should work
12:03 < BlueMatt> like, you cant properly restrict your counterparty from sending you update_fees that are too high, and cause issues or too low, and cause issues, cause you cant even possibly *pick* an update_fee that makes sense
12:03 < rusty> update_fee still allows you to adjust to slow changes, however, if they were to occur.  For example, slowly rising fees.  It is not completely useless.
12:03 < ariard> Just to avoid the burden of change commitment transaction format again in six-months, a year to drop update_fee
12:03 <+roasbeef> ariard: so that's maybe bitcoin 21 or something? imo we should just deploy things as soon as we can in order to not have dependancies on stuff getting into bitcoin or miner block selection, this is an issue today, would rather not wait years before we can improve the situation today that users/devs/companies cite as pain points 
12:03 <+roasbeef> ariard: it wouldn't need to change, we can just drop it 
12:03 < BlueMatt> rusty: right, but we've never seen such things, in practice
12:03 <+roasbeef> i can send you some logs ;) 
12:04 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:04 < BlueMatt> rusty: so...I dunno, its a) incredibly hard to implement "right" (arguably no implementations have today), b) its useful for only some scenario that we may never see (and have never seen)?
12:04 < ariard> logs of txn being stucked in the mempool ?
12:04 <+roasbeef> logs of commitments being updated to slow fee rises 
12:04 < BlueMatt> I dont think rbf is required to get rid of it
12:04 < cdecker> Let's just minimize the size of the changes we do in one go, otherwise we're compounding the chances to introduce errors
12:04 <+roasbeef> y'all are proposing something completely independent to the anchor changes 
12:04 < BlueMatt> roasbeef: maybe your fee predictor assumes slowly rising fees, but...uhhh, getting into the mempool doesnt require those?
12:04 <+roasbeef> if you have a mechanims to handle fes better on commitments and also coop closing, then please propose that independently 
12:05 < BlueMatt> cdecker: I wouldnt call it "canges" more like "get rid of useless shit"
12:05 < BlueMatt> like, if we're gonna clean it up, lets clean it up
12:05 < cdecker> Well, it's still a change from the currently implemented logic, so let's not rush those out all at once
12:05 < joostjgr> i think the anchor outputs are a good safety mechanism. you'll always have a handle to push your commit tx forward. without update_fee, we're stuck with the opening ceremony fee for the rest of the channel life
12:06 < BlueMatt> I dont think its practically doable, today, for an automated program to make any better fee predictions on what is gonna get into the mempool next week than I can, just sitting here.
12:06 < cdecker> Otherwise I'll start advocating for bundling sighash_noinput with taproot again xD
12:06 < BlueMatt> cdecker: ehh, they're highly related
12:06 <+roasbeef> anchor as is makes a pretty significant step for safety in the network, let's not delay things more than we need to, a bigger fee overhaul is an independent change 
12:06 < BlueMatt> update_fee, as horribly broken as it is today, is all that exists, with anchor outputs we have a strictly better solution
12:06 < BlueMatt> with rbf its *even better*, but thats kinda separate
12:06 <+roasbeef> in any case, it's a link level change, so it can be rolled out at will, since it doesn't require a synchronized internal network update 
12:07 < BlueMatt> roasbeef: anchor outputs *are* the "big fee overhaul"
12:07 <+roasbeef> not really 
12:07 < BlueMatt> I dont see why that should also include removing cruft related to the old fee model.
12:07 <+roasbeef> it's just allowing you to bump fees, when you can't right now 
12:07 < BlueMatt> right, and allowing you to bump fees is the thing that you need to get rid of the old cruft
12:07 < BlueMatt> its not like update_fee actually, well, allows you to reliably broadcast
12:08 < BlueMatt> anchor outputs make progress
12:08 <+roasbeef> works pretty well in practice today, anchor makes things better, let
12:08 <+roasbeef> let's keep making forward progress 
12:08 < BlueMatt> it works cause fees are 0 today
12:08 < BlueMatt> thats a completely bogus argument
12:08 <+roasbeef> even when they haven't been 
12:08 < BlueMatt> yes, makes things better, so remove the useless ccruft :p
12:09 < joostjgr> besides this point, symmetric csv ok? and anchor script locked to funding key with csv locked cleanup path?
12:09 < lndbot> <johanth> I think we all agree update_fee is not ideal, but we can't just remove it today
12:09 < BlueMatt> lndbot: why not?
12:09 < rusty> joostjgr: yes, I like symmetry.
12:09 <+roasbeef> ok, if y'all have a complete proposal for how to remove update_fee and also revamp the coop close logic, then please propose it on the mailing list, I havent' seen any such proposal, and see no reason why it should block improving the current state of the network 
12:09 < ariard> roasbfee: works pretty well, but is there any adversarial peer stopping to sign bumped commitment txn in case of fees spikes?
12:10 < BlueMatt> "works pretty well" == a broken turst model :(
12:10 <+roasbeef> ariard: if they don't sign, we have the past commitment so can anchor things down 
12:10 < BlueMatt> come on...
12:10 <+roasbeef> if they won't sign state updates, then it's a useless channel 
12:10 < lndbot> <johanth> How do you determine the commit tx fee without?
12:10 < BlueMatt> errr, trust.
12:10 < ariard> roasbeef: assuming the past commitment can get in the mempool
12:10 < BlueMatt> lndbot: fix it? you dont actually have to go very high to get into the mempool even at its absolute peak.
12:11 < BlueMatt> you can be orders of magnitude below the next block fee to get into the mempool
12:11 <+roasbeef> ariard: yes that's a base assumption, packged relay can relax that assumption eventualy, packaged relay doesn't exist 
12:11 < BlueMatt> which approxamates rbf
12:11 < BlueMatt> so you seriously dont need to assume rbf for it to be useful to kill update_fee
12:11 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
12:12 < BlueMatt> lndbot: you could realistically use like 5sat/vbyte or something....nice round number, dont have to worry about it.
12:12 < cdecker> Sorry, notebook froze
12:12 < cdecker> joostjgr: +1 for symmetric fees
12:12 < joostjgr> i am not sure how we're doing time wise, but we'd welcome some review/comments from the eclair and cl teams on the pr as well
12:12 <+roasbeef> symmetric fees? 
12:12 <+roasbeef> main meeting is prety much over at this point 
12:12 < joostjgr> symmetric csv
12:13 < cdecker> Ah sorry, symmetric delays
12:13 < ariard> joostjgr: what's about the delay for csv, 10 blocks?
12:13 < joostjgr> yes, i think it can be a lot longer too
12:13 < joostjgr> give the channel parties some time to do their thing with the anchor
12:13 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
12:13 < ariard> agree on this, would let you aggregate sweeping 
12:13 < BlueMatt> yea, I'm kinda curious what other folks think the utility of update_fee is? rusty or cdecker?
12:13 < joostjgr> the sweepers are patient i think?
12:13 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
12:14 < ariard> joostjgr: sweepers can scan blockchain once a month, for utxo pollution IMO that's ok
12:14 < BlueMatt> maybe I'm missing something....why 10 blocks? the anchor only matters for next-block (ie csv 1)
12:15 < joostjgr> ok, change to 4096 blocks?
12:15 < joostjgr> this is for anyone can spend
12:15 <+roasbeef> this is the trap door for the rest of the world 
12:15 < BlueMatt> right, once you have 1 conf, the anchor output has done its job
12:15 < joostjgr> if it is economical for a sweeper, it may also be for the channel party
12:15 < niftynei> my understanding of anchors is that if they're unused (to anchor a tx) then they're anyone can spend?
12:15 < BlueMatt> (unless we're assuming they have enough value that the actual owners want the funds)
12:15 < cdecker> BlueMatt: like I mentioned above, I don't like bundling changes, and removing update_fee is more than necessary
12:15 -!- openoms [~quassel@185.174.156.219] has quit [Ping timeout: 240 seconds]
12:15 < ariard> yes anyone can spend if channel party doesn't act
12:16 < rusty> BlueMatt: I hate update_fee, and long to see the day when it's banished forever.  But if other implementers feel they still want it, I can wait.
12:16 < BlueMatt> cdecker: so....add a separate feature bit for it and merge it in 2 weeks? :p
12:16 < ariard> joostjgr: yes seems good to me, would be a magic number anyways
12:16 < joostjgr> wondering if that sweeper business will make me rich
12:16 < niftynei> the question seems to be are they 'anyone can spend immediately' or 'anyone can spend after a timedelay allowing the originating parties to claim it'
12:17 < joostjgr> niftynei: yes, the proposal is now anyone can spend after x blocks. and discussing x
12:17 < lndbot> <johanth> sgtm adding a longer delay
12:17 < niftynei> i don't grok the rationale for a delay
12:17 < joostjgr> if it is economical for a sweeper, it may also be for the channel party
12:17 < ariard> joostjgr: nop but youo would act for the sake of the blockchain :p
12:17 < BlueMatt> I guess I dont really care. If you think the value is enough that you want the original owners to claim the funds, ok, but hopefully its low enough that we dont care so its not worth discussing :)
12:17 < joostjgr> so channel party gets the first exclusive option to sweep
12:18 < niftynei> but .. .why?
12:18  * niftynei is clearly not someone you want managing your petty cash drawer
12:18 < joostjgr> is it always a noop? channel parties proposed their dust limit, which is the anchor value
12:19 < BlueMatt> I mean the channel parties get the first exclusive option to sweet no matter what cause its > 0
12:19 < joostjgr> in the case that they are offline when the commit tx confirms
12:19 < bitconner> given that channel parties need to provide a signature while sweepers don't, i'd be interested in the exact threshold where it is profitable to claim or not
12:19 < lndbot> <johanth> They might be offline
12:19 < BlueMatt> (and, hopefully, the value is low enough that it has ~0 value)
12:19 < BlueMatt> at least once you consider the next tx fee
12:20 < bitconner> perhaps deriving that threshold can inform whether or not counterparties are even likely to claim them
12:20 < niftynei> my understanding of anchors is that they're intentionally non-economic; introducing additional latency assumes some economic-ness to them
12:20 < rusty> BlueMatt: I hope not, or it'll spam forever
12:20 <+roasbeef> it's mostly conjecture really, the amount will be de minimis 
12:21 < BlueMatt> rusty: ok, well only marginal value, sameish point applies
12:21 < rusty> I want them economic, otherwise we're spamming the blockchain because they won't be spent.  It's an important distinction, let's not foul our own nest.
12:22 < BlueMatt> I kinda assumed they may have value at fee of 1-5 sat/vbyte, but 0 value above that...for that purpose you'll neverish claim next-block (assuming bitcoin is functional)
12:22 < lndbot> <johanth> they might be economic, they might not be. You don't know, since you don't know when it Will be broadcast
12:22 < BlueMatt> so csv 1 == csv 1024
12:22 < joostjgr> in the current version of the pr, parties pick their anchor size during opening
12:22 < BlueMatt> wut
12:22 < BlueMatt> please no
12:22 < niftynei> adding an additional delay feels like an unnecessary complication imo, for unclear benefit
12:22 < rusty> BlueMatt: I've been arguing to just pick a value, too.  Since there's no good number, KISS.
12:23 <+roasbeef> constants should really be avoided at all costs imo, which lends to parties picking their own values 
12:23 < niftynei> CSV 1 is easy to reason about, and semi-self descriptive in that the rationale for it is built into its value
12:23 < BlueMatt> thats just another update_fee - you're now trying to decide what the minimum economic value is when they close the channel at the time they open the channel
12:23 < BlueMatt> picking it is absolutely impossible, just hardcode it
12:23 < BlueMatt> roasbeef: only if its actually *possible* to make an informed decision at runtime, which you cannot.
12:24 < niftynei> '1' has semantic meaning in this case; '1024' is meaningless
12:24 <+roasbeef> BlueMatt: why can't you? based it off of the current widely recognized dust threshold (which can even change in node's mempools in high water scenarios)
12:24 <+roasbeef> otherwise what value would you pick that you can be sure won't cuase any issues in the future w.r.t output redemption? 
12:25 < BlueMatt> roasbeef: then just hardcode it?
12:25 < BlueMatt> cause that number ~doesn't change.
12:25 <+roasbeef> this is about parties picking their value at the start 
12:25 < BlueMatt> also, the dust threshold has not changed in about 5 years
12:25 < BlueMatt> the mempool watermark does *not* change the dust threshold
12:25 < BlueMatt> for this very reason
12:26 <+roasbeef> i'd have to check again, but last I did, it created a new floor 
12:26 < ariard> does it mean now if we update dust threshold we want to be sure to not break LN commitment txn ?
12:26 < BlueMatt> it creates a fee floor - not a dust value floor
12:26 <+roasbeef> in any case, deciding on a csontant seems hard, so just let the nodes pick one, in the future we may converge in a single value 
12:26 < BlueMatt> deciding a constant is strictly easier than writing code to dynamically pick one
12:26 < BlueMatt> by, like, two orders of magnitude
12:26 <+roasbeef> ariard: parties pick their dust threshold at the start as is, but it can't be updated once the channel is open 
12:26 < BlueMatt> that threshold has a massively different meaning
12:26 < ariard> roasbeef: know that, was speaking more on the core side
12:26 <+roasbeef> BlueMatt: lol us talking about this right now shows it isn't very easy to arrive at a constant 
12:27 <+roasbeef> i mean, just look at bitcoin in 2017 or so 
12:27 < BlueMatt> roasbeef: we aren't debating what the value is? I think any one of us can calculate a value and we'd all be within 5x of each other right now.
12:27 < BlueMatt> roasbeef: that *does not change* the dust value
12:27 <+roasbeef> ariard: last change was actually it being lowered kinda, due to segwit 
12:27 < BlueMatt> bitcoin *today* and bitcoin 2017 had the same dust value
12:27 <+roasbeef> lol that was a ref in the difficulty of picking constants 
12:28 < ariard> roasbeef: so it means if core increase dust_fee in the future it may render some LN commitment txn unbroadcastable ?
12:28 < BlueMatt> "just make it dynaic" is not a solution for issues like this, and its kinda depressing to see it suggested
12:28 < BlueMatt> dynamic
12:28 <+roasbeef> ariard: as is yes that's the case, but they can ofc still be included in a block 
12:29 <+roasbeef> we're not saying make it dynamic, we're saying both parties choose their values at the start, just as we do for every other paramter for channel funding 
12:29 <+roasbeef> but in anycase, g2g now
12:30 < BlueMatt> sorry, phrasing, "pick it at the open" is not a solution for something you cannot pick dynamically
12:30 < joostjgr> this value is already picked to decide whether htlcs should materialize on the commit tx. we are reusing this for the anchor, no new field is added. there is no change at all to the funding msgs in the pr as is
12:30 < cdecker> How is that not directly contradicting with joostjgr's desire to reduce the test matrix? Let's start with a fixed value and introduce negotiation once we see the need for it, and not otherwise
12:30 < BlueMatt> joostjgr: nope, thats a very different limit!
12:30 <+roasbeef> cdecker: it's easy to have it float, them impls agree to a value vs caping it then adding an ability to allow it to float 
12:30 < BlueMatt> joostjgr: thats a economic limit that you expect to be economic at the time you broadcast +/-
12:31 < BlueMatt> this limit is a limit that you expect to be economical at some point over the next 6-12 months
12:31 < BlueMatt> which is massively different
12:31 < niftynei> what's the fear with choosing a constant? that the bitcoin spec will move against it?
12:31 < BlueMatt> niftynei: bitcoin hasnt chaned it in many years, because of issues like this :p
12:32 < BlueMatt> and I cant imagine it chaning (at least in the upwards direction) without lots of timelag cause people will point out it breaks *lots* of software
12:32 < BlueMatt> lightning is not at all uniqe here
12:32 < niftynei> right, i'm just trying to understand what the context is around fixed values
12:32 < lndbot> <johanth> How do you know the constant will be economical in the next 6-12 montsh?
12:32 < cdecker> roasbeef: no, if we allow it to float we need to be able to handle it when our counterparty choses to use another value. If our response is to just slam the door in their face we've just created a netsplit...
12:32 < BlueMatt> lndbot: assume at some point you can claim something with 5sat/vbyte, and move on with your life :)
12:33 < lndbot> <johanth> That might not be true
12:33 < cdecker> Negotiations are a necessary evil some times (*cough*update_fee*cough*) but should be avoided imho if there isn't a really good reason for them
12:33 < BlueMatt> well you cant predict it any better at runtime in software for a channel you'll close in 12 months anyway :p
12:33 < niftynei> would making it variable as to the bitcoin standard be reasonable?
12:33 < lndbot> <johanth> And if the fee level stays there, then we would need to change the constant
12:33 < BlueMatt> sure, it may not be true, but if you cannot possibly predict it better in software, why are we debating this?!
12:34 < lndbot> <johanth> My software can predict it better in 12 months then I can do now
12:34 < niftynei> at least in terms of how the spec is written? it seems like if we're worried what's economic will change, and the economicness is determined by the bitcoin standard, then we could just pin it to the bitcoin standard in spec and call it done
12:35 < cdecker> Anyway, got to go, and I don't see us agreeing on this today :-)
12:35 < cdecker> See you guys next time ^^
12:35 < bitconner> bye cdecker!
12:35 < niftynei> tchau cdecker!
12:35 < BlueMatt> niftynei: sure, but that == hardcoding it :)
12:35 < BlueMatt> cdecker: fwiw, I'm not suggesting that update_fee isnt required in *today's* lightning, I agree its a neccessary evil today, just that I dont think it will be soon :p
12:35 < BlueMatt> lndbot: wut? I promise you this is not the case :)
12:36 < lndbot> <johanth> hehe
12:36 < BlueMatt> see y'all
12:36 < lndbot> <johanth> Have you seen my code lol
12:36 < BlueMatt> well, I can predict best: my prediction is 1sat/vbyte will at some point in the next 12 months be mined :)
12:36 < BlueMatt> perfect!
12:37 < joostjgr> thanks for the input here. please keep commenting on the pr
12:37 < bitconner> say goodbye to your htlcs lol
12:37 < ariard> anyway if any lightning dev wants to concept review package relays it's here : https://github.com/bitcoin/bitcoin/pull/16401
12:37 < joostjgr> btw, any other teams actively implementing any of this?
12:37 < joostjgr> we are
12:38 < bitconner> having a fixed threshold where the whole network becomes crippled seems less than desirable
12:38 < BlueMatt> we'd like to, but we still mostly dont feel like implementing update_fee cause its so broken (and doubly hard to get right if you arent writing your own fee estimator, which we are not)
12:38 < BlueMatt> bitconner: huh? no one is proposing a fixed dust threshold for htlcs
12:38 < BlueMatt> bitconner: this is for the anchor outputs, which, as described above, is a very different type of dust
12:39 < bitconner> what is the worst case outcome if that value is too low?
12:39 < BlueMatt> they sit in the utxo set forever
12:39 < BlueMatt> and the utxo set has more uneconomical crap in it (it already has lots, sadly, but not exactly world-ending)
12:39 < bitconner> got it, was thinking this was about commitment fee rate
12:40 < BlueMatt> nah, thats the update_fee discussion :p
12:41 < bitconner> heh, we have a ways to go before ln creates as many unspendables as coinbase lol
12:41 < lndbot> <johanth> Bye all!
12:41 < bitconner> adios!
12:42 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev
12:42 < joostjgr> see you all
12:42 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving]
12:42 < bitconner> #endmeeting
12:42 < lightningbot> Meeting ended Mon Nov 11 20:42:35 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
12:42 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-11-11-19.11.html
12:42 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-11-11-19.11.txt
12:42 < lightningbot> Log:            http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-11-11-19.11.log.html
12:44 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds]
12:52 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has quit [Ping timeout: 265 seconds]
12:54 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 252 seconds]
12:54 -!- ohmyfromage [~pi@pool-71-114-76-86.washdc.fios.verizon.net] has left #lightning-dev []
12:56 < niftynei> re: "heh, we have a ways to go before ln creates as many unspendables as coinbase lol" ?
12:58 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Read error: Connection reset by peer]
12:59 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
13:00 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
13:03 <+roasbeef> ariard: glanced a the PR, and it looks imcomplete? (also still is marked draft), seems there also needs to be a distinct p2p extension to allow relaying conjoined transctions 
13:17 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection]
13:27 < jnewbery> Does the bech32 length-extension weakness affect lightning invoices? https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-November/017443.html
13:27 < jnewbery> (apologies if it's been asked already. I don't hang out here much)
13:33 -!- reallll is now known as belcher
13:47 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
13:55 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
13:58 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection]
14:15 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev
14:28 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
14:31 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
14:33 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev
14:33 -!- hiroki_ [6f5923d6@pl94934.ag2001.nttpc.ne.jp] has quit [Ping timeout: 260 seconds]
14:36 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 240 seconds]
14:39 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 265 seconds]
15:05 -!- nobody123 [~nobody123@139.28.219.102] has quit [Ping timeout: 240 seconds]
15:07 -!- nobody123 [~nobody123@139.28.219.102] has joined #lightning-dev
15:08 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev
15:13 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 268 seconds]
15:22 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []
15:54 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev
15:54 -!- marcoagner [~user@2001:8a0:6a5f:5700:7bb3:6296:d274:7295] has quit [Ping timeout: 245 seconds]
16:04 -!- arij [uid225068@gateway/web/irccloud.com/x-kkdsmkmwjaelsttj] has quit [Quit: Connection closed for inactivity]
16:20 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 265 seconds]
16:27 -!- arij [uid225068@gateway/web/irccloud.com/x-bcjkimwlgzeprbtt] has joined #lightning-dev
16:28 -!- whitez00 [whitez00@gateway/vpn/protonvpn/whitez00] has quit [Quit: Konversation terminated!]
16:40 -!- diogosergio [~diogoserg@176.24.23.243] has joined #lightning-dev
16:51 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds]
16:53 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Read error: Connection reset by peer]
17:05 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #lightning-dev
17:19 < rusty> bitconner: meeting actions didn't say explicitly to merge flat features once those two changes (1 typo, one to inc gfeatures allowance from 11 to 13) were made.  I have pushed that change, should I now rebase and squash in prep for merge?
17:19 < rusty> (Then I can rebase base-amp on top and life is much nicer all around)
17:19 < rusty> roasbeef, bitconner: Re naming: payment_handle?  
17:24 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 265 seconds]
17:25 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev
17:36 < rusty> niftynei: how's the protocol testing update going?  I want to write thorough tests for update_fees, since it seems to be having problems (again, sigh)
17:40 -!- riclas [riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev
17:47 -!- CCR5-D32 [~CCR5@s91904421.blix.com] has joined #lightning-dev
17:55 < ariard> roasbeef: even simplier than coinjoined, one-CPFP multiple commitment txn isn't covered by this PR, that's aiming to a minimal change
17:55 < ariard> you can do a p2p extension or a bit more of mempool hacking to let enable it in future PRs
17:56 < ariard> roasbeef: yes still WIP, if you think about any flagrant corner cases or incompletness to go forward your input is welcome :)
17:59 <+roasbeef> I mean conjoined, as in two transactions that are dependent on each other ariard  
18:00 <+roasbeef> ariard: yeh I just mean that it seems premature to create a dependnacy on what we're doing, based on an incomplete PR that still needs p2p extensions is all, I prefer to minimize as many external deps as possible generally as they're areas where unforseen circumstances can hold everything up 
18:07 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
18:21 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Remote host closed the connection]
18:27 < ariard> roasbeef: ah conjoined not coinjoin, well this PR implements a 2-tx conjoin, both unconfirmed
18:28 < ariard> roasbeef: yep but waiting for the more general p2p extension means in the while lighting isn't secure, a bit bit better with anchor outptus but won't hold really adversarial attackers
18:29 < ariard> roasbeef: so maybe package relay receiving-side only now, and latter package relay p2p extension + better carve-out
18:30 -!- CCR5-D32 [~CCR5@s91904421.blix.com] has quit [Remote host closed the connection]
18:30 -!- CCR5-D32 [~CCR5@s91904421.blix.com] has joined #lightning-dev
18:30 < ariard> agree with dependency, but as LN users are the more enlightned users for these mechanism they feedback is really good, indenpendently of what we decide for bolts
18:31 -!- CCR5-D32 [~CCR5@s91904421.blix.com] has quit [Client Quit]
18:34 -!- CCR5-D32 [~CCR5@s91904427.blix.com] has joined #lightning-dev
18:38 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds]
18:55 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
19:00 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 265 seconds]
19:18 -!- CCR5-D32 [~CCR5@s91904427.blix.com] has quit [Quit: CCR5-D32]
19:33 -!- CCR5-D32 [~CCR5@s91904428.blix.com] has joined #lightning-dev
20:01 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev
20:01 -!- CCR5-D32 [~CCR5@s91904428.blix.com] has quit [Quit: CCR5-D32]
20:06 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 265 seconds]
20:44 -!- arij [uid225068@gateway/web/irccloud.com/x-bcjkimwlgzeprbtt] has quit [Quit: Connection closed for inactivity]
21:58 -!- wsm [~wsm@gateway/tor-sasl/wsm] has quit [Ping timeout: 260 seconds]
21:58 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 260 seconds]
22:03 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #lightning-dev
22:04 -!- wsm [~wsm@gateway/tor-sasl/wsm] has joined #lightning-dev
22:28 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.]
23:55 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev
23:58 -!- shesek [~shesek@185.3.145.80] has joined #lightning-dev
23:58 -!- shesek [~shesek@185.3.145.80] has quit [Changing host]
23:58 -!- shesek [~shesek@unaffiliated/shesek] has joined #lightning-dev
--- Log closed Tue Nov 12 00:00:05 2019