--- Log opened Mon Dec 09 00:00:31 2019 00:30 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 00:31 -!- rh0nj [~rh0nj@88.99.167.175] has joined #lightning-dev 00:50 -!- marcoagner [~user@bl11-16-162.dsl.telepac.pt] has joined #lightning-dev 01:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 01:13 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 250 seconds] 01:20 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 01:44 -!- ir0nbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has joined #lightning-dev 01:47 -!- ironbutt [~LiberLive@82.142.166.82] has quit [Ping timeout: 250 seconds] 01:58 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #lightning-dev 02:03 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds] 02:03 -!- jonatack [~jon@213.152.161.35] has joined #lightning-dev 02:16 -!- DavidMitchell[m] [davidfedii@gateway/shell/matrix.org/x-iydihdzkmxnbgebj] has quit [Quit: killed] 02:16 -!- JoKe[m] [jokesharek@gateway/shell/matrix.org/x-zhiikedboqpsslki] has quit [Quit: killed] 02:16 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-wxrohdduzwaukypa] has quit [Quit: killed] 02:16 -!- electric-sheep[m [electric-s@gateway/shell/matrix.org/x-hdrpwcfnomtklspv] has quit [Quit: killed] 02:16 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-ryoynkydptscroby] has quit [Quit: killed] 02:56 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has quit [Quit: My MacBook has gone to sleep. ZZZzzz...] 02:57 -!- dr-orlovsky [~dr-orlovs@194.230.155.171] has joined #lightning-dev 03:15 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev 03:16 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 265 seconds] 03:21 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 03:31 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 03:33 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 03:33 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 03:41 -!- nobody123 [~nobody123@141.98.102.172] has joined #lightning-dev 03:42 -!- nobody123 [~nobody123@141.98.102.172] has quit [Remote host closed the connection] 03:46 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has joined #lightning-dev 03:47 -!- TheFuzzStone[m] [thefuzzsto@gateway/shell/matrix.org/x-ifkcvjejbfejtdgi] has joined #lightning-dev 03:47 -!- JoKe[m] [jokesharek@gateway/shell/matrix.org/x-efiwoiekeqflprfc] has joined #lightning-dev 03:47 -!- electric-sheep[m [electric-s@gateway/shell/matrix.org/x-wqqidciwzwqkrxbi] has joined #lightning-dev 03:47 -!- interfect[m] [interfectm@gateway/shell/matrix.org/x-cmyecwtjehzgvzqm] has joined #lightning-dev 03:47 -!- DavidMitchell[m] [davidfedii@gateway/shell/matrix.org/x-qecgjnmarvmriufr] has joined #lightning-dev 04:09 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Read error: Connection reset by peer] 04:35 -!- diogosergio [~diogoserg@212.36.34.126] has joined #lightning-dev 04:37 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 245 seconds] 04:41 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 04:52 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 04:56 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 04:57 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 05:33 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has quit [Remote host closed the connection] 05:50 -!- reallll is now known as belcher 06:08 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 06:08 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 06:08 -!- __gotcha1 is now known as __gotcha 06:20 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 06:24 -!- jonatack [~jon@213.152.161.35] has quit [Read error: Connection reset by peer] 06:42 -!- capitalisnn [~natebrune@2601:47:4001:59c5::3dc] has joined #lightning-dev 06:47 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 06:55 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 07:04 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Remote host closed the connection] 07:09 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 07:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 07:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 07:46 -!- tryphe_ [~tryphe@unaffiliated/tryphe] has joined #lightning-dev 07:47 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection] 07:52 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 07:55 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #lightning-dev 07:58 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 07:59 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #lightning-dev 08:00 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 08:01 -!- ir0nbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has quit [Remote host closed the connection] 08:07 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 08:08 -!- diogosergio [~diogoserg@212.36.34.126] has quit [Ping timeout: 240 seconds] 08:13 -!- diogosergio [~diogoserg@212.36.34.126] has joined #lightning-dev 08:17 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #lightning-dev 08:28 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev 08:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 268 seconds] 08:36 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined #lightning-dev 08:40 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev 08:42 -!- t-bast [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Read error: Connection reset by peer] 08:43 -!- t-bast-official [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has joined #lightning-dev 08:45 -!- t-bast-42 [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Ping timeout: 250 seconds] 08:48 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Quit: Sleep mode] 09:01 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined #lightning-dev 09:02 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Client Quit] 09:06 -!- diogosergio [~diogoserg@212.36.34.126] has quit [Ping timeout: 245 seconds] 09:15 -!- t-bast-official [~t-bast@ec2-35-180-216-238.eu-west-3.compute.amazonaws.com] has quit [Quit: Leaving] 09:27 -!- laptop500 [~laptop@212.203.87.198] has joined #lightning-dev 09:44 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined #lightning-dev 09:50 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 09:50 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Quit: Sleep mode] 09:52 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #lightning-dev 09:54 -!- andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Ping timeout: 260 seconds] 09:56 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 10:11 -!- t-bast [~t-bast@2a01:e34:ec2c:260:54db:5aaa:c59a:295f] has joined #lightning-dev 10:16 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has joined #lightning-dev 10:16 -!- michaelfolkson [~textual@host-92-13-61-152.as43234.net] has quit [Client Quit] 10:27 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 10:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 10:31 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 10:33 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 10:44 -!- laptop500 [~laptop@212.203.87.198] has quit [Quit: Leaving] 10:48 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 10:49 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 10:58 -!- sstone_ [~sstone@185.186.24.109.rev.sfr.net] has joined #lightning-dev 11:00 < rusty> Hello everyone! 11:00 * t-bast waves at the crowd 11:01 < cdecker> Hi all ^^ 11:01 < sstone_> Hi! 11:01 < bitconner> hello 11:02 < niftynei> hello!!! 11:02 < t-bast> I was thinking that tonight we can start with "easy" PRs and then do a hangout for anchor outputs (if BlueMatt is here)? 11:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 250 seconds] 11:02 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 11:03 < joostjgr> Hi 11:03 < BlueMatt> hi 11:03 < cdecker> SGTM 11:03 < bitconner> ^^ 11:03 < BlueMatt> t-bast: is there a way to record hangouts? 11:03 < bitconner> screen capture? 11:04 < t-bast> I guess that should do the trick yeah 11:04 < t-bast> Unless there may be a built-in tool, let me check 11:04 < cdecker> There used to be a Hangouts on Air that'd stream directly to youtube and record at the same time, no idea if that's still a thing 11:05 < BlueMatt> right, that 11:05 < t-bast> It seems to be built-in to Hangout, there hsould be a "record" button 11:05 < bitconner> nice 11:05 < t-bast> shall we start then and stay on IRC for the first PRs? 11:05 < BlueMatt> sg 11:05 < t-bast> #startmeeting 11:05 < lightningbot> Meeting started Mon Dec 9 19:05:45 2019 UTC. The chair is t-bast. Information about MeetBot at http://wiki.debian.org/MeetBot. 11:05 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 11:05 < t-bast> I just stole the chair 11:06 < t-bast> Let's start with two related small ones 11:06 < cdecker> No problem, Ikea has cheap ones... 11:06 < t-bast> ... 11:06 < t-bast> #topic Message extensions 11:06 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/705 11:07 < t-bast> This is a proposal similar to what we did with onion TLV, to create a "safe range" of message types for experiments 11:07 < t-bast> There are two things to discuss: whether to assign a range like that and whether the range I chose makes sense :) 11:08 < rusty> Ack from me, seems like a no-brainer. 11:08 < cdecker> Yep, sounds good 11:09 < t-bast> Cool, I'll let Joost or Conner chime in for LL 11:09 < bitconner> ack from me! 11:09 < joostjgr> i am not so familiar with this area. 65535 is the max I assume? Maybe random is not enough to prevent collisions? 11:10 < bitconner> yes the message types are uint16s 11:10 < t-bast> Exactly, 65535 is the max. Random may not be enough indeed to avoid collisions, but I don't know if we can do much better 11:10 < t-bast> Do you have an idea on how to help people chose? 11:10 < rusty> People manage to avoid stepping on each other with TCP port numbers, in practice. 11:10 < niftynei> it might be nice to have a wiki page where devs can 'signal intent' to use a type number, but i don't think that needs to go in the spec 11:10 < t-bast> rusty: xD 11:10 < joostjgr> yes, maybe just the wording of 'random' could be something that hints to a little more coordination 11:10 < t-bast> niftynei: good idea, this can be a Github issue 11:10 < t-bast> similar to the feature bit waiting room 11:11 < niftynei> sgtm 11:11 < t-bast> Allright, thanks for the feedback I'll update that wording and create an issue to track signaling 11:11 < cdecker> I like the idea of a Wiki where we track these 11:11 < t-bast> #action t-bast update the wording on "random" choice 11:11 < cdecker> (an issue is also good, and users could at least comment there) 11:12 < t-bast> #action t-bast create a wiki or issue to track used message IDs 11:12 < t-bast> Thanks, let's do the second one that's linked to this one now :) 11:12 < t-bast> #topic Message TLV extensions 11:12 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/714 11:13 < cdecker> SGTM 11:13 < t-bast> This PR adds to the spec that the ignored data at the end of messages must be a TLV stream 11:13 < t-bast> The main reason I'd like to get that in sooner than later is that I realized that if we let some people use a TLV stream there and others use something else, this might lead to nasty conflicts 11:13 < t-bast> Much nastier than if everyone just uses a TLV stream and the TLV rules 11:13 < t-bast> WDYT? 11:15 < rusty> Well, this has always been the case. If you extend things in incompatible ways, you lose. 11:16 < bitconner> are we certain all of today's messages readily support this sort of extension? 11:16 <+roasbeef> stuff like the init message potentially can't 11:16 < bitconner> wondering if it has weird interactions with any of the optional fields we've added 11:16 < t-bast> Bolt 1 currently states that everyone should ignore the trailing bytes of all Lightning messages 11:16 < cdecker> It's a rather nice consolidation imho 11:16 < t-bast> init message already can, there's a PR that adds a TLV stream at the end awaiting interop 11:16 <+roasbeef> there's also an assumption that impls that follow this have already impleemented _all_ the current "optional" fields 11:17 <+roasbeef> t-bast: not really, it has two variable length fields 11:17 < t-bast> roasbeef: that's completely orthogonal to that...? 11:17 < rusty> Yeah, there are some optional fields which make this trickier. 11:17 < cdecker> But both are length-prefixed roasbeef that's not an issue 11:17 < t-bast> True that current optional things may mess this up (maxHtlcAmount for example) 11:17 <+roasbeef> t-bast: i mean that if the feature bits are large enough, ther's no space left 11:18 < cdecker> It'd be nice to consolidate the optional trailing fields into TLVs 11:18 <+roasbeef> but also see the optional fields thing, until now, none of them have been optional 11:18 < t-bast> roasbeef: gotcha, true, you have to deal with only the remaining space left 11:18 <+roasbeef> so we need to gate the tlv extensions on observance of all the currently optional fields 11:18 < cdecker> roasbeef: but that's fully under the sender's control 11:18 < bitconner> for example, i think shutdown scripts may have to be mandatory in order to extend open_channel 11:18 <+roasbeef> as in, if you don't implement upfront shutdown for example, you can't add extensions to the open channel message 11:19 < joostjgr> standardize on tlv for extensions sgtm. does this also translate cleanly to extending the htlc failure message with tlv? (realizing this is not exactly the scope of this pr) 11:19 < cdecker> Isn't the presence of the shutdown script gated on a feature bit? 11:19 < cdecker> joostjgr: that'd be indeed nice 11:19 <+roasbeef> cdecker: yes, so if you don't have that set, then you can't set extensions 11:19 < t-bast> that's a good point roasbeef, not sure how we should handle priority there 11:19 < t-bast> joostjgr: we can potentially do that indeed, I'll think about it 11:20 <+roasbeef> joostjgr: not really, unless there's a tuneling aspect to it 11:20 < rusty> A quick grep indicates that if we assume static_commitment or dataloss_protect and option_upfront_shutdown_script, that's it. 11:20 < bitconner> cdecker, just because i say i support it doesn't mean the field is actually present 11:21 < cdecker> Right, how about we just re-bundle those fields into a TVL stream then? Might be painful for a while, but once we are upgraded we can simplify massively 11:21 < rusty> cdecker: naah, just make them compulsory. 11:21 < bitconner> i think at this point everyone has implemented those three? 11:21 < sstone_> roasbeef: why can't you use extensions on open_channel if the upfront feature bit is not set ? 11:21 < cdecker> Also fine by me :-) 11:22 <+roasbeef> sstone_: will the other party check for the address, or try to parse the tlv extension? 11:22 <+roasbeef> while decoding the message 11:22 < niftynei> total aside, but the v2 of open_channel that i've been working on does exactly this (moves the optional fields into a tlv) 11:22 < sstone_> roasbeef: parse the tlv extension 11:22 < rusty> sstone_: lnd objected to feature-dependent parsing before, which is why the redundant field is left there for option_simplified_commitment. 11:22 < t-bast> niftynei: if only you'd done that before we added these optional fields :D 11:22 < niftynei> (not really useful for existing msgs tho) 11:23 <+roasbeef> sstone_: why? it's possible to set the bit (optional), but then not set any addr at all, however I signal that I can parse yours to extract the addr 11:23 <+roasbeef> it's a side effect of the prior optional fields not actually being optional at all to build on top of 11:23 < bitconner> niftynei: perhaps put all fields in tlv to start, optional or otherwise? 11:24 < sstone_> roasbeef: ok I see :( 11:24 < bitconner> roasbeef: yes i think that's the case 11:24 < t-bast> Do you think we should do a full pass on all those optional fields and decide on a case-by-case whether they should become mandatory or be inside an extension stream? 11:24 < cdecker> +1 on to the TLV-everything proposal :-) 11:24 < bitconner> :D 11:24 < niftynei> bitconner, not sure if trolling or... :P 11:24 < bitconner> niftynei: not trolling, promise :) 11:24 < cdecker> (sounds a lot like the protobuf 2 to protobuf 3 migration btw, where they decided that all fields must be optional) 11:25 < t-bast> I can spend some time on all relevant fields and send a recap', and we decide what we do for each 11:25 < cdecker> SGTM t-bast 11:25 < bitconner> t-bast: sgtm, hopefully there aren't too many instances 11:25 < rusty> t-bast: there are only a few fields, see above. We should simply make them all compulsory and move on, making all extra data TLV. 11:25 < t-bast> Allright, I'll do a new pass on that and will update the PR 11:26 < t-bast> There's another small point in this PR 11:26 < rusty> (dataloss_protect is already compulsory on the network in practice, and everyone support upfront_shutdown too) 11:26 < t-bast> Is the stream length-prefixed or not? 11:26 < rusty> no. 11:26 < t-bast> rusty: perfect, that's what I'm leaning towards too 11:26 < cdecker> Let's keep it simple and force TLV extensions only in the future -> no length prefix 11:26 < t-bast> especially if we don't need to allow a secondary extension mechanism, I don't see a reason for length prefix 11:27 < rusty> At some point you have to fish or cut bait. We can always renumber the messages if we want Fancy New Format. 11:27 < t-bast> bitconner, roasbeef, joostjgr, do you agree with that? 11:27 < t-bast> agreed rusty 11:28 <+roasbeef> if no length, there's a hard conflict with the prior extensions mechanism of "jsut add stuff to the end" 11:28 < bitconner> is there a possibility that we mant to not set any of those three in the future? 11:28 < bitconner> if so, it would break all extensions 11:28 < bitconner> (or at least the ones on the relevant messages) 11:28 < t-bast> roasbeef: true, it effectively replaces that by "just add tlv records to the end" 11:29 < bitconner> in general tho i like the change 11:29 < cdecker> It's a minor restriction, but makes things so much better behaved and less hand-wavy 11:29 < joostjgr> "add stuff to the end" could then again be a special field in the tlv stream... 11:29 < t-bast> bitconner: I'll try to summarize for each of those the reasons why we may want to turn them off in the future and we'll see 11:29 < rusty> TBH, this is what "we can append stuff" was *for*: when we knew how to use it. 11:29 < t-bast> joostjgr: exactly! 11:29 <+roasbeef> was brought up last time, but I think we need to step back and think about how we extend the spec and make it more readable in light of the steady changes, so basically just making git tags to snapshot things, with the current feature bits basically being implictly assumed for each version, and points to prior versions for existing behavior 11:30 < t-bast> that's a good point roasbeef: do we want to have some of us draft a proposal for next meeting? 11:31 < t-bast> I think that's how it would be most efficient: let some of us prepare a proposal we can chew on before discussing it next time 11:31 < t-bast> *proposals (better if many do it in parallel) 11:32 <+roasbeef> not sure if it requires immediate action, just something we should be cognizant over, it really became apparent to me when reviewing the anchor outputs pr 11:32 < rusty> I agree with roasbeef: once a feature is made compulsory, all mention of it should be cleaned up as if it were always compulsory. 11:32 <+roasbeef> rusty: if we basically have a psuedo-programming-markup langauge in there right now lol 11:32 < niftynei> +1 11:33 < t-bast> #action t-bast add proposal on how to handle current optional fields (probably make them all mandatory) 11:33 < t-bast> #action t-bast remove the length prefix 11:33 < niftynei> (to 'versioning by commit/current rev only") 11:33 < t-bast> #action all keep thinking about ways to clean-up the spec 11:33 < rusty> roasbeef: yeah, specs kinda always get this way unless you remove obsolete support. But I agree at some point you go "look at the git history for reasons", and some features are no-brainers. 11:34 < cdecker> I'd still like to move to a proposal -> changes -> living document process for the specs 11:34 < bitconner> the days of initial_routing_sync are numbered 11:35 <+roasbeef> cdecker: what's living doc mean? 11:35 < t-bast> cdecker: what do you mean? 11:35 <+roasbeef> isn't tha what we have rn? no strong bounds between "versions" 11:35 < cdecker> Each change that is substantial needs a document accompanying it that explains the rationale in a single place, and then has pointers into the spec where changes were applied 11:35 <+roasbeef> also there's a question of bolt extension or new docs all together 11:35 < cdecker> Reconstructing the rationale from the git history and the few breadcrumbs left in the various rationale blocks is terribly confusing 11:35 <+roasbeef> then like stich them all together using some script to make a mega doc 11:35 < rusty> bitconner: +1! 11:35 < t-bast> For significant changes I agree: we're missing having the rationale high-level view in a single place -> maybe we should add wiki pages for that 11:36 < bitconner> cdecker: so new proposals would be their own documents more like bips? 11:37 < cdecker> Yes, but once the logic of the change has been debated we can then apply changes to the bolts, and link the rationale in, so that there is a doc to read the big-picture of why certain things were done 11:37 < cdecker> And the bolts would be the living documents (basically a materialization of all the proposals being applied) 11:38 < t-bast> I'd like that, especially since we'll be adding more "big" features now that the basics are there 11:38 <+roasbeef> still leaves the question of how to handle extension of existing bolts, or creating new ones 11:38 < rusty> Personally, I like git commit logs for this, but they've got to be more verbose than currently. 11:38 < t-bast> For anchor outputs I think it would make a lot of sense to have such a doc for newcomers 11:38 <+roasbeef> the current cut itself was never really examined for consistency and independence of presentation 11:38 < cdecker> Just bolting on additional bullets to the rationale sections in the bolts without ever giving the bigger pictures is really confusing (at least to me) 11:38 <+roasbeef> by cut I mean the split of stuff between the docs, we kinda just all ran w/ it 11:39 < t-bast> roasbeef: that's true, some of them are kinda big now 11:39 < cdecker> rusty: you can't have a discussion in git commits 11:39 < cdecker> roasbeef: exactly 11:39 < rusty> cdecker: no, but the final commit msg which goes into master should have it embedded IMHO. 11:39 < cdecker> Right, that can certainly be done 11:40 < bitconner> t-bast: should we continue with another pr? :) 11:40 <+roasbeef> ok for the sake of time, let's cap the meta discussion to move on? great points all around tho 11:40 < cdecker> Anyway, that's for the overall process if we are changing it up. Didn't want to sidetrack the discussion :-) 11:40 < t-bast> yep, great discussion let's keep going 11:41 < joostjgr> t-bast, what is your time line for the irc part and the hangouts parts of this meeting? 11:41 < rusty> (Looking fwd to snapshots of IRC discussions in future spec commit msgs....) 11:41 < t-bast> Is there another "smallish" PR some of you want to go over before we move to anchor outputs? 11:41 < t-bast> There are a bunch of trivial PRs over there, but maybe each of us can go through them outside of the meeting for the sake of time? 11:41 < bitconner> 641? 11:42 < rusty> 711? 11:42 < cdecker> I think #697 can be applied (we all fixed it iirc) 11:42 < bitconner> is it time to revisit? 11:42 < bitconner> +1 for 697 11:42 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 11:42 < t-bast> Oh yeah we haven't implemented 697 yet but will be simple 11:43 < t-bast> ACK, can be applied 11:43 < t-bast> #topic https://github.com/lightningnetwork/lightning-rfc/pull/641 11:43 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/641 11:43 < t-bast> I think 711 is a no-brainer, please just ACK it people :) 11:43 < t-bast> bitconner can you refresh our minds on 641? 11:43 < bitconner> sure 11:44 < t-bast> and then we move to anchor @joostjgr ;) 11:44 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 11:44 < bitconner> atm the spec says we _should_ reply with historical data when people set very wide gossip filters 11:44 < cdecker> Ack'd 711 :-) 11:44 < bitconner> this change removes that altogher, since it be pretty expensive 11:44 < rusty> bitconner: so do we still support for the very first time they set filter? 11:44 < bitconner> it forces people to us the queries rather than simply asking for everything 11:45 < bitconner> the filter then is still applied to updates that we receive from other peers 11:45 < rusty> Because we currently (if we have no gossip) pick a node and ask for filter from 0. 11:45 < t-bast> thx, sstone probably has more to say than me on that subject 11:45 < bitconner> rusty: and don't use the query mechanism? 11:46 < cdecker> Hm, asking for everything sounds legit though 11:46 < rusty> bitconner: we'll fall back to it to double-check. 11:46 < sstone_> well it lgtm 11:46 < bitconner> the whole reason for adding gossip_queries was to avoid the DOS vector of intial_routing_sync 11:46 < cdecker> If the peer really needs all the gossip why not allow it to just query it this way rather than mandating multiple roundtrips? 11:46 < rusty> bitconner: sure, but if you really *do* want to bootstrap, gossip_queries is way less efficient. 11:47 < cdecker> Yes, but in this case it's the recipient (which was getting DoSd) that opts in explicitly 11:47 <+roasbeef> rusty: it has rate limiting built in tho 11:47 < bitconner> idt 5 more control messages really is gonna make a difference 11:47 <+roasbeef> vs getting a massive dump on the wire 11:47 < sstone_> rusty: how much worse ? 11:47 < bitconner> again, we wanted to remove the inefficient sync method by adding gossip_queries. keeping this behavior just degrades it back to what we had before 11:47 < rusty> For us, sending you all the gossip is literally scanning a file and sending it; it's pretty efficient. 11:48 < BlueMatt> the idea that dos should be reduced by telling the sender to slow down in-protocol seems to have missed...the entire point of tcp? 11:48 <+roasbeef> rusty: but what about the receiver? with the queries they can rate limit the resposnes they get 11:48 < BlueMatt> like, the sender should trivially be able to say "oh, tcp socket full, let me not send this low prio crap" 11:48 < cdecker> Yes, that's the point, if a node asks for everything with a really large timestamp range, they explicitly opt into getting a lot of messages 11:49 < cdecker> The sender of the gossip is free to throttle however they like 11:49 < sstone_> BlueMatt: yes but it's the same socket for everything 11:49 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #lightning-dev 11:49 < rusty> bitconner: there's an intermediate step here, where we should not go backwards: i.e. if you didn't specify a filter before, sure, we'll look from the start, but if you specify a new one we're going to send yo histortical records. 11:49 < bitconner> i'm more concerned with the seender side, this is the biggest allocation of bandwidth i see on my node by far 11:49 < BlueMatt> sstone_: sure, but sending different messages in different order is trivial. its not like you can load the whole thing into a buffer the second you connect anyway (if you do that on the sender side you will oom yourself) 11:50 < rusty> bitconner: well, (recent) c-lightning will only do that if it doesn't have any gossip. 11:50 < bitconner> rusty: so that only prevents sending duplicates on the same connection? 11:51 < rusty> bitconner: yeah, but in our implementation we scan all the gossip again if you send a new filter, which is kinda sucky, 11:52 < bitconner> all this scanning can be eliminated if we wish :) 11:52 < BlueMatt> i guess my question is: its a bunch of outbound bandwidth, but does that *matter* 11:52 < BlueMatt> like, outgoing bandwidth that doesnt interfere with other operation shouldnt matter 11:52 < bitconner> when you're connected to 300 peers, yes 11:52 < BlueMatt> why? 11:52 <+roasbeef> I need to go in 10 mins, so will say this on anchor outputs: would be nice if we can at least agree on scripts so if to use the miniscript optimizations or not (which change the witness), as that would let impls move forward. On the topic of the anchor output size, I'm not sure why we need strict conformance given that since the sender pays for them, they only need to sure the responder's values aren't below dust and "too high" (so a cap on size based 11:52 < BlueMatt> bitconner: it shouldnt ever interefere with other stuff, it just may be slow to send to peers? 11:53 < BlueMatt> and if its the case that you dos yourself by sending lots of data, gossip_queries doesnt fix that, it just makes the attacker have to work a tiny bit harder 11:53 * niftynei is a under the weather today, so is going to log off a bit early. looking forward to watching the anchor outputs recording later :wave: 11:53 < t-bast> roasbeef: noted 11:53 < bitconner> BlueMatt: not saying it does, but it's generally just wasteful 11:54 < BlueMatt> sure, definitely should hve nodes prefer to use things that use less bandwidth, but...well, what isnt at this point? 11:54 < rusty> bitconner: so at startup we pick one peer and ask for everything from some starttime, which defaults to (last-changed-time-of-gossip-store minus 60 seconds) or 0 if we have no gossip at all. 11:55 < rusty> That seems pretty optimal if you restart your node. We don't have a timestamp filter for other queries, so I'm not sure how to replace this other than by asking for, everything? 11:57 < bitconner> gotcha, i thought cl had switch entirely to gossip queries and not rely on the full dump at all. in that case this change could still be premature 11:57 < t-bast> Let's keep the discussion on Github then and move on to Anchor Outputs TM? 11:58 < t-bast> And please have a quick look at 711 which needs some love? 11:58 < rusty> bitconner: This is the only case left: seemed a good fit. The rest of the time we got for "stream on" or "stream off". I'm happy to change, just got to figure out what we shuld do. 11:58 < cdecker> Well, we could always chunk the "dump everything on me" query into smaller ranges and incrementally ask for them, but it'd still be the same end-result with added latency for issuing the queries 11:58 < bitconner> rusty: sounds good we can discuss more on the pr :_) 11:59 < cdecker> t-bast: yes, let's move on to AO 11:59 < rusty> cdecker: yeah, you need to query by scid range than ask about those scids. But that doesn't work for "I've been down 1 hour, what happened?' 11:59 < BlueMatt> I mean responses to a full sync query might as well already be the same as that, just done on the sending side 11:59 < BlueMatt> cause, like, you have to implement it that way to avoid dos'ing yourself anyway 11:59 < BlueMatt> and its the same amount of data sent 11:59 < t-bast> #action keep discussing on the PR to summarize pros and cons 11:59 < t-bast> #topic Anchor Outputs 11:59 < t-bast> #link https://github.com/lightningnetwork/lightning-rfc/pull/688 11:59 < rusty> BlueMatt: Yeah, we already stream gossip reponses at low prio, though TCP buffering makes that less useful than you'd hope. 11:59 < t-bast> #link https://meet.google.com/vyt-qnjg-bnm?pli=1&authuser=0 12:00 < t-bast> Please join the hangout link for anchor outputs, I may need to manually accept each one of you 12:00 < BlueMatt> can you not make it "public"? 12:00 < t-bast> I don't think so... 12:01 < cdecker> Ok, just checked, Hangouts on the Air was discontinued, maybe we can setup something on Zoom next time? 12:27 < t-bast> #info ACK on the scripts with small changes (CLTV=16) 12:27 < t-bast> #info ACK on using a symmetric delay with max (using current negotiation) 12:29 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 12:29 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 12:34 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 12:37 < t-bast> #info leaning more towards a constant value for the anchor outputs 12:37 < t-bast> Thanks everyone for the progress made! 12:37 < t-bast> #endmeeting 12:37 < lightningbot> Meeting ended Mon Dec 9 20:37:10 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 12:37 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-12-09-19.05.html 12:37 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-12-09-19.05.txt 12:37 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-12-09-19.05.log.html 12:38 -!- t-bast [~t-bast@2a01:e34:ec2c:260:54db:5aaa:c59a:295f] has quit [Quit: Leaving] 12:43 < BlueMatt> bitconner: plz pr audio to https://github.com/TheBlueMatt/bitcoinninja/ 12:58 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving] 12:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 13:09 < bitconner> BlueMatt: will do 13:24 -!- sstone_ [~sstone@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving] 13:25 -!- b33rkeg [~b33rkeg@ptr-7svqdluasl8xv67b114.18120a2.ip6.access.telenet.be] has joined #lightning-dev 13:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 245 seconds] 13:32 -!- b33rkeg [~b33rkeg@ptr-7svqdluasl8xv67b114.18120a2.ip6.access.telenet.be] has quit [Quit: Quit] 13:48 -!- xLE1CwWbY6 [9e4515b0@176.21.69.158.rdns.lunanode.com] has joined #lightning-dev 13:54 -!- xLE1CwWbY6 [9e4515b0@176.21.69.158.rdns.lunanode.com] has quit [Remote host closed the connection] 14:11 -!- satoshi_calabres [~immortal_@185.117.118.188] has joined #lightning-dev 14:26 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer] 14:27 -!- satoshi_calabres [~immortal_@185.117.118.188] has left #lightning-dev [] 15:12 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 15:19 -!- hiroki_ [7c92eec7@pl21447.ag2001.nttpc.ne.jp] has joined #lightning-dev 15:26 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 15:28 -!- marcoagner [~user@bl11-16-162.dsl.telepac.pt] has quit [Ping timeout: 268 seconds] 15:29 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 15:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 15:43 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 15:55 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 16:01 -!- slivera [slivera@gateway/vpn/privateinternetaccess/slivera] has joined #lightning-dev 16:01 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 16:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 16:43 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 245 seconds] 16:43 -!- hiroki_ [7c92eec7@pl21447.ag2001.nttpc.ne.jp] has quit [Remote host closed the connection] 16:44 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #lightning-dev 16:46 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 17:23 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 17:34 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 17:34 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has quit [Remote host closed the connection] 17:35 -!- _andrewtoth_ [~andrewtot@gateway/tor-sasl/andrewtoth] has joined #lightning-dev 17:41 -!- arij [uid225068@gateway/web/irccloud.com/x-ecaignnfbyjimxsh] has joined #lightning-dev 18:11 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has joined #lightning-dev 18:42 -!- riclas [~riclas@77.7.37.188.rev.vodafone.pt] has quit [Ping timeout: 246 seconds] 18:44 -!- wullon [~wullon@241.243.86.88.rdns.comcable.net] has quit [Quit: Ping timeout (120 seconds)] 18:46 -!- cryptoso- [~cryptosoa@gateway/tor-sasl/cryptosoap] has joined #lightning-dev 18:46 -!- cryptosoap [~cryptosoa@gateway/tor-sasl/cryptosoap] has quit [Ping timeout: 260 seconds] 18:47 -!- wullon [~wullon@241.243.86.88.rdns.comcable.net] has joined #lightning-dev 18:59 -!- capitalisnn [~natebrune@2601:47:4001:59c5::3dc] has quit [Ping timeout: 245 seconds] 20:46 -!- nobody123 [~nobody123@141.98.102.172] has joined #lightning-dev 21:01 -!- diogosergio [~diogoserg@176.24.23.243] has joined #lightning-dev 21:08 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 240 seconds] 21:30 -!- ryjen [~irc@nullstruct.com] has joined #lightning-dev 21:31 -!- zerogue [~irc@nullstruct.com] has quit [Ping timeout: 276 seconds] 21:32 -!- ryjen is now known as zerogue 21:34 -!- capitalisnn [~natebrune@2601:47:4001:59c5::3dc] has joined #lightning-dev 22:18 -!- capitalisnn [~natebrune@2601:47:4001:59c5::3dc] has quit [Ping timeout: 250 seconds] 23:08 -!- kabaum [~kabaum@2001:9b1:efd:9b00::281] has quit [Ping timeout: 250 seconds] 23:11 -!- arij [uid225068@gateway/web/irccloud.com/x-ecaignnfbyjimxsh] has quit [Quit: Connection closed for inactivity] 23:23 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 23:36 -!- jungly [~quassel@79.8.200.97] has joined #lightning-dev 23:50 -!- vasild [~vd@gateway/tor-sasl/vasild] has joined #lightning-dev --- Log closed Tue Dec 10 00:00:33 2019