--- Log opened Mon Oct 28 00:00:49 2019 00:26 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has quit [Ping timeout: 246 seconds] 01:13 -!- halseth [~root@138.68.141.217] has joined #lightning-dev 01:18 -!- halseth [~root@138.68.141.217] has quit [Quit: leaving] 01:21 -!- Guest41243 [~root@138.68.141.217] has joined #lightning-dev 01:22 -!- Guest41243 [~root@138.68.141.217] has quit [Client Quit] 01:22 -!- marcoagner [~user@2001:8a0:6a5f:5700:7bb3:6296:d274:7295] has joined #lightning-dev 01:23 -!- halseth [~root@138.68.141.217] has joined #lightning-dev 01:24 -!- halseth [~root@138.68.141.217] has quit [Client Quit] 01:26 < lndbot> harding: yeah, that's where I had Jeremy's comment from! Sorry should have mentioned :slightly_smiling_face: 01:26 -!- halseth [~root@138.68.141.217] has joined #lightning-dev 01:32 -!- jonatack [~jon@213.152.162.104] has joined #lightning-dev 01:43 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has quit [Quit: = ""] 01:43 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 01:51 < lndbot> bluematt: it is obviously not just as straight forward as just removing all limits, but the idea was that moving to per input limits could be reasonable, which is why I wanted to mention it 01:53 < lndbot> SECURETHEBAD hitting these limits seemed related 01:54 < lndbot> we are moving forward with a commitment format adding 1 CSV to all outputs now, but for future smart contracting applications would be nice to explore if it could be improved upon 02:07 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 02:40 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has quit [Remote host closed the connection] 02:43 -!- ironbutt [~LiberLive@144.49.211.130.bc.googleusercontent.com] has joined #lightning-dev 02:53 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 02:56 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 264 seconds] 02:56 -!- __gotcha1 is now known as __gotcha 03:03 -!- jonatack [~jon@213.152.162.104] has quit [Ping timeout: 240 seconds] 03:07 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has joined #lightning-dev 03:15 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 260 seconds] 03:16 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #lightning-dev 03:18 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 03:20 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Read error: Connection reset by peer] 03:20 -!- __gotcha1 is now known as __gotcha 03:21 -!- jonatack [~jon@54.76.13.109.rev.sfr.net] has quit [Ping timeout: 240 seconds] 03:21 -!- jonatack [~jon@109.202.107.10] has joined #lightning-dev 03:27 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has joined #lightning-dev 03:32 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has quit [Ping timeout: 268 seconds] 03:39 -!- nobody12_ [~nobody123@152.89.163.116] has quit [Remote host closed the connection] 03:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 03:50 -!- jonatack [~jon@109.202.107.10] has quit [Ping timeout: 252 seconds] 04:30 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 252 seconds] 04:41 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 04:46 -!- fox2p [~fox2p@185.212.170.51] has quit [Ping timeout: 240 seconds] 04:50 -!- fox2p [~fox2p@185.183.104.83] has joined #lightning-dev 05:11 -!- laptop500 [~laptop@194.33.98.165] has joined #lightning-dev 05:16 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 245 seconds] 05:37 -!- jonatack [~jon@2a01:e35:8aba:8220:6627:dad:d967:649d] has joined #lightning-dev 05:43 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 06:06 -!- rh0nj [~rh0nj@88.99.167.175] has quit [Remote host closed the connection] 06:30 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has joined #lightning-dev 06:49 -!- arshbot [~arshbot@99-23-136-47.lightspeed.tukrga.sbcglobal.net] has joined #lightning-dev 06:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 250 seconds] 06:56 -!- diogosergio [~diogoserg@212.36.34.126] has joined #lightning-dev 06:59 -!- jungly [~quassel@host97-200-static.8-79-b.business.telecomitalia.it] has joined #lightning-dev 07:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 07:02 -!- __gotcha1 [~Thunderbi@plone/gotcha] has joined #lightning-dev 07:04 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 07:04 -!- __gotcha1 is now known as __gotcha 07:10 -!- captjakk [~captjakk@174-16-221-137.hlrn.qwest.net] has joined #lightning-dev 07:13 -!- potatoe_1ace [~potatoe_f@157.230.27.253] has joined #lightning-dev 07:14 -!- captjakk [~captjakk@174-16-221-137.hlrn.qwest.net] has quit [Ping timeout: 240 seconds] 07:20 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 07:21 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has quit [Client Quit] 07:21 -!- belcher [~belcher@unaffiliated/belcher] has joined #lightning-dev 07:21 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 07:22 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 07:23 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has quit [Client Quit] 07:23 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 07:27 < joostjgr> Reworked version of simplified commitments: https://github.com/lightningnetwork/lightning-rfc/pull/688 07:33 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has quit [Ping timeout: 240 seconds] 07:39 < sword_smith> I am building a publicly available wallet for test net, like htlc.me, and could use around 1 TESTBTC to hand out to new customers so they can use on chain and off chain transactions right away. Can anyone here help me? 07:45 < lndbot> post your testnet address i can send a few 07:48 -!- joostjager [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 07:49 -!- joostjager [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Client Quit] 07:52 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 07:55 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 07:56 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 08:00 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 08:00 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 08:00 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 08:13 -!- hiroki_ [d2a585b4@pl72884.ag2001.nttpc.ne.jp] has joined #lightning-dev 08:13 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has joined #lightning-dev 08:59 -!- hiroki_ [d2a585b4@pl72884.ag2001.nttpc.ne.jp] has quit [Remote host closed the connection] 08:59 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 09:01 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 09:03 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 09:04 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 09:06 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 09:08 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 09:28 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 252 seconds] 09:41 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 09:59 < darosior> conner: in Berlin (just after the meeting) you showed me and Christian the HD wallet derivation path that LND uses for channel seed derivation, could you point me to it please ? 10:02 < darosior> Finally found it! https://github.com/lightningnetwork/lnd/blob/1a0ab538d53c5be57cbbf80b0e48e5a207de9749/keychain/derivation.go#L48 10:12 -!- hamess [~hamess@unaffiliated/hamess] has quit [Quit: leaving] 10:15 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 10:20 -!- hamess [~hamess@unaffiliated/hamess] has joined #lightning-dev 10:20 -!- diogosergio [~diogoserg@212.36.34.126] has quit [Ping timeout: 264 seconds] 10:29 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 10:34 < sword_smith> : If you could send a bit of testnet BTC here, that would be nice :) tb1qex004pkzhwclwufes96t6vkywym3x3vfkzmnvt 10:41 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 10:45 < sword_smith> Thanks! :) 10:45 < lndbot> sword_smith 2 tbtc sent https://testnet.smartbit.com.au/tx/d518c0741418d277194b6151a0ed3d75826c84b679ac91a27d0a08043ce70b28 10:46 < sword_smith> Much appreciated. I am working on something similar to htlc.me and also wanted to give out free TESTBTC to new signups. 10:46 < lndbot> cool, can't wait to see, if you need more, let me know :slightly_smiling_face: 10:47 < sword_smith> : If you are interested, you can already check it out at pilatus.io 10:48 < sword_smith> I haven't implemented the TESTBTC handout yet, though. 10:48 < sword_smith> But there should be a wallet with onchain and offchain functionality. 10:48 < lndbot> hm do we need to provide an email? 10:48 < sword_smith> moli: For this service? Yes. 10:48 < sword_smith> Transaction confirmations are sent to that mail. 10:49 < sword_smith> So it is not as lightweight as htlc.me 11:04 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 11:29 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 240 seconds] 11:31 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has joined #lightning-dev 11:36 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has quit [Ping timeout: 268 seconds] 11:44 -!- gkrizek9 [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has joined #lightning-dev 11:44 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has quit [Read error: Connection reset by peer] 11:57 -!- reallll [~belcher@unaffiliated/belcher] has joined #lightning-dev 11:59 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has joined #lightning-dev 12:01 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 268 seconds] 12:02 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 12:04 -!- hiroki_ [d2a585b4@pl72884.ag2001.nttpc.ne.jp] has joined #lightning-dev 12:04 < cdecker> Hi all, I think we're having a spec meeting or was that moved? 12:04 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 12:05 < sstone> Hi! Yes I think we do 12:05 < rusty> Yep, it's now. But am pretty jet lagged, so... :) 12:05 <+roasbeef> BlueMatt: not throwing rocks at all, just trying to understand all the design rationale and what alternative were considered at the time, as any future contracting applications with large-ish fan outs/ins will bump into these limits, for eaxmple, idk if duplex could've ever been deployed with the limits in place as they are 12:05 < cdecker> Heya sstone, hey rusty :-) 12:06 < cdecker> roasbeef: what about duplex in particular? 12:06 < niftynei> hello 12:06 <+roasbeef> cdecker: talking about the mempool limits w.r.t ancestor and descendent count 12:07 < niftynei> actually wait.. brb 12:07 < cdecker> Yeah, the tree was a bit nasty ^^ 12:07 <+roasbeef> dunno if you're up to date, but rn if we want to do the anchor output stuff, we also need to modify a bunch of other scripts as well (add csv 1 to everything) in order to mitigate an attack that can be launched by creating a large transaction tree to block another 12:07 <+roasbeef> yeh this is the proper time 12:07 <+roasbeef> it was moved back 1 hr 12:07 < cdecker> We were hoping for chains of up to 10 txs, that'd give us 4 billion updates roughly 12:08 <+roasbeef> and next time, it'll move back another hour 12:08 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 12:08 <+roasbeef> cdecker: yeh but the issues that are arising now is that someone else can block you from possibly getting that chain of 10 in 12:08 < cdecker> Hehe, see I'm already on wintertime in sync with AU :-) 12:08 <+roasbeef> or be unable to rbf it (assuming noinput) 12:08 <+roasbeef> heh yeh for us subjetively it changes 12:08 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 12:09 < cdecker> roasbeef: I know, I hadn't thought about the package limits at all back in the day (not sure I was even aware of the concrete limits tbh) 12:09 <+roasbeef> aight let's do this? 12:09 <+roasbeef> cdecker: iirc they didn't exist at that point, and were added later when ppl starting spamming the mempool during all the block size stuff 12:09 < cdecker> Should be a short one, since we already settled everything in Berlin... right...? :-) 12:10 <+roasbeef> well biggest new thing is the anchor output stuff 12:10 <+roasbeef> there seems to be a bunch of things that were ack'd but not merged 12:10 <+roasbeef> i can go through and land some of those 12:10 < cdecker> You mean joost's #688? I was just reading through it 12:10 <+roasbeef> #startmeeting 12:10 < lightningbot> Meeting started Mon Oct 28 19:10:32 2019 UTC. The chair is roasbeef. Information about MeetBot at http://wiki.debian.org/MeetBot. 12:10 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic. 12:10 <+roasbeef> cdecker: yeh it's newish, just was put up today 12:11 < cdecker> Shall we cross off some old favorites first? 12:11 <+roasbeef> #action merged #660 12:11 <+roasbeef> #672 needs a rebase though, but its g2g other than that 12:12 <+roasbeef> (allowing greater segwit versions) 12:12 <+roasbeef> cdecker: which faves? 12:12 < rusty> Ack. 12:12 <+roasbeef> i think we're more or less olidfieid on the mmp payload now? (so combine both value and paymetn addr under a single record) 12:13 < cdecker> Nothing, just wanted to start with the old ones first, before getting off track with #688 :-) 12:13 < cdecker> roasbeef: sounds reasonable to me 12:13 <+roasbeef> gotcha, ok going backwards... 12:14 <+roasbeef> #topic 571 (feature bit renaming) 12:14 <+roasbeef> atually this was replaced byy #666 I think 12:14 -!- reallll is now known as belcher 12:14 <+roasbeef> rusty: can we close 571 in favor of 666? 12:14 < rusty> Yeah, cwithdrawing now. 12:15 <+roasbeef> iirc this is mostly g2g, just need final comement clean up, and also CL and eclair both have some form of this rolled out already 12:16 <+roasbeef> and to ensure backwards compat is maintained (was my main comment) 12:16 < rusty> Yeah, I will update it now. 12:16 <+roasbeef> ok cool 12:16 < cdecker> Nice, that gets one of the oldest open PRs off the list ^^ 12:16 <+roasbeef> #action rusty to update #666 after latest round of comments and meatspace discussion 12:17 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 12:17 <+roasbeef> ok wumbo... 12:17 <+roasbeef> #topic 596 wumbo bit for channels 12:17 <+roasbeef> I guess this is interdependent on #666 right? 12:17 <+roasbeef> as it informs where the bit is placed 12:17 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/596 12:18 < sstone> roasbeef: yes it is 12:18 < cdecker> Needs to be rebased and truncated down to just the changes necessary for the wumbo bit (if any remain after merging #666) 12:18 <+roasbeef> ok gotcha 12:19 <+roasbeef> #info 596 has dep on 666, needs to be rebased as well once 666 is in 12:19 <+roasbeef> #topic 620 12:19 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/620 12:19 <+roasbeef> #info clarification on message placement in bolts (ann sig) 12:20 <+roasbeef> i don't think we ever reached any rough consensus on this? 12:20 < sstone> nope :) 12:20 <+roasbeef> the origin of this was ambiguitiy in which order of messages to expect 12:20 <+roasbeef> (chan reest vs ann sig) 12:21 < cdecker> Yeah, announcement_signature pretty clearly is bound to a channel, and should therefore be subject to the ordering requirement 12:21 < sstone> yes that was our take too, but it' 12:21 < sstone> it's not that obvious in the specs 12:22 <+roasbeef> imo they're on diff levels 12:22 <+roasbeef> chan reest is link re-establishment 12:22 <+roasbeef> ann sig is a gossip message for the broader network 12:22 <+roasbeef> i can use the channel as soon as chan reest is sent, and ann sig isn't bound to that lifecycle 12:22 -!- nobody123 [~nobody123@152.89.163.116] has joined #lightning-dev 12:23 < sstone> but you still need to send funding_locked before ann_sigs 12:24 < sstone> so it's bound to the channel lifecycle 12:24 <+roasbeef> sure, but this is about chan reest and ann sig 12:24 <+roasbeef> even then with funding locked they're distinct imo 12:24 < cdecker> Good point sstone: there are already ordering constraints, so why explicitly relax them here? 12:25 <+roasbeef> as the events can happen concurrently 12:25 < rusty> We have "gossip messages" and "message in bolt 7". They're not synonymous, but not defined. 12:25 <+roasbeef> which only comes into palce past 6 confs 12:25 <+roasbeef> but in general we should also modify that 6 conf value, it doesn't make sense as a blanket value, especially after wumbo 12:25 < rusty> The implication was "gossip messages" are re-xmitted, others are inter-peer. 12:26 < cdecker> Yep, "gossip messages" mean something to others and are broadcast, announcement_signature and the query messages are not broadcast and only have a meaning in the context of the current connection 12:26 < rusty> The spec says" bolt 7 messages" in one place where it means "gossip messages". But these bolt 7 messages are msgs about setting up gossip, so it's confiusing. 12:27 <+roasbeef> doesn't seem like we're really getting anywhere with this, the OP of the PR isn't here, but iirc his intention was to update the spec to match existing behavior in the wild and attempt to make it less ambigious, not sur ehow far we can get since they're not here 12:27 <+roasbeef> the diff in teh PR is also pretty tiny 12:27 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 12:27 <+roasbeef> names that ann sig is independent of the channel life cycle (which it is, you can not send it but the channel is fully usable) 12:28 < cdecker> Yes, but it corrects the wrong way around, really sending the messages in a random order is an implementation error imho 12:28 < rusty> But its exactly wrong. The sentence in BOLT 2 shoujld be changed from "Note that messages described in [BOLT #7](07-routing-gossip.md) are independent of particular channels; their transmission requirements are covered there, and besides being transmitted after `init` (as all messages are), they are independent of requirements here." to "Note that *gossip* messages described...." 12:29 < cdecker> Let's not get hung up on gossip messages vs bolt 7 messages, let's just enumerate all the ones that are permissible: channel_announcement, channel_update and node_announcement, nothing else is permissible 12:29 <+roasbeef> in the end "channel lifecycle" isn't defined anywhere really 12:31 < sstone> ann sigs is already special since it is explicitely defined as "not a gossip message" 12:31 < rusty> cdecker: language tried to be generic for future schnorrstyle msgs. 12:31 <+roasbeef> ok i guesrs we shoudl move on? and maybe export some of this in the PR? this is all about semantics at the end of the day, thigns are ambgiuous in the spec, and we all seem to have diff models of it in our heads 12:32 <+roasbeef> cdecker: permissible as in? 12:34 < rusty> OK,fixed up 666 BTW. 12:35 <+roasbeef> #topic 625 12:35 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/625 12:35 <+roasbeef> this is related lol 12:35 <+roasbeef> attempts to define an ordering 12:35 <+roasbeef> on funding locked and ann sig 12:35 <+roasbeef> since the two events can be triggered concurrently 12:36 < rusty> No, it attempts to undefine the existing ordering. And it's wrong. We can't announce until we agree on the scid, which isn't finalized until funding_locked, 12:37 <+roasbeef> it's saying that if the depth is 15, wait to send the ann sig 12:37 <+roasbeef> don't send it after 6, since funding locked will be sent after 15 blocks 12:37 -!- diogosergio [~diogoserg@176.24.23.243] has joined #lightning-dev 12:38 <+roasbeef> otherwise ann sig is always sent after 6, which would be before funding locked 12:38 < cdecker> Yes, but the dependency on funding_locked is stronger since that also has to wait for the negotiated funding_depth 12:38 <+roasbeef> (once again 6 should be removed imo and just use the min depth for everything) 12:39 <+roasbeef> iirc this was created after 620, so perhaps they're alternatives 12:40 < niftynei> i'm a bit confused by the `max` function in this change, fwiw. i'd expect the `minimum_depth` to supercede the 'default' of 6, but this implies you'd use 6 as the floor regardless of what the minimum_depth is 12:40 < cdecker> If we remove the 6 some implementations might start sending out gossip messages that are not valid according to the broadcast rules, so the 6 in there is a way for us to avoid that 12:40 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has joined #lightning-dev 12:40 < rusty> roasbeef: yeah, 6 is to protect the gossip network from reorgs. But you simply can't exchange sigs until both sides agree the funding tx is final. 12:40 < cdecker> The problem is that the depth of 6 is a global limit, whereas the funding_locked is a local one 12:40 <+roasbeef> cdecker: post wumbo, depending on channel ranges, 6 isn't an acceptable value to use everywhere 12:41 < niftynei> an easier fix would be to just truncate the six confirmations and pin the `announcement_sig` to an exchange of `funding_locked`, no? 12:41 <+roasbeef> it isn't even really well defined what to do in the case of a re-org, as yu'd need to generate a new ann sig and advertisement 12:41 < rusty> niftynei: *it already is*. 12:41 < cdecker> roasbeef: yes, you can use a higher funding_depth value to require more (and implicitly delay the gossip, which is what I was saying) 12:43 < niftynei> what's the motivation here for removing the `funding_locked` exchange requirement? 12:43 < cdecker> Otherwise I don't see how wumbo comes into play here (I expect with higher value channels you'd want more confirmations) 12:43 < rusty> (TBH, I'm not sure what will happen to our gossip with a > 6 reorg, cdecker will we implicitly close re-orged out channels from gossip?) 12:43 <+roasbeef> niftynei: not about removing it, about trying to define a more strict ordering 12:43 < niftynei> this change removes the requirement that `funding_locked` is exchanged 12:44 < rusty> roasbeef: No, this *explicitly* removes the "stricter ordering". 12:44 < cdecker> rusty: good question, I think we might keep the stale entries in gossipd 12:44 <+roasbeef> no, it's even in a diff doc that funding_locked 12:44 < rusty> roasbeef: "but removes the stricter ordering requirements wrt funding_locked and (indirectly) channel_reestablish"... from first para of desc. 12:44 < rusty> And the diff shows it removing that. 12:45 <+roasbeef> 15 mins left, shall we move on? 12:45 <+roasbeef> OP not here again 12:45 -!- thomasanderson [~thomasand@108-91-143-73.lightspeed.rlghnc.sbcglobal.net] has quit [Ping timeout: 268 seconds] 12:45 < cdecker> Yes please :-) 12:45 <+roasbeef> #topic 658 (amp) 12:45 <+roasbeef> err no 12:45 <+roasbeef> #topic #643 (mpp) 12:45 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/643 12:45 -!- joostjgr [~joostjgr@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving] 12:46 <+roasbeef> final thing iirc is unifying the payloads? 12:46 < rusty> Note I got off my butt and finally updated this a few minutes ago :) 12:46 <+roasbeef> i think most of us have some type of prototype of this, so we could start interop testing soon after it lands 12:46 <+roasbeef> ah nice 12:46 <+roasbeef> ok cool I see that it's combined, will comment on the spec PR 12:46 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has joined #lightning-dev 12:46 <+roasbeef> #info payload now combines payment addr and total amt 12:47 < rusty> Yeah, we now are assuming everyone supplies a secret. No point trying to handle the TLV-but-no-secret case. No secret, no AMP for you! 12:47 <+roasbeef> sgtm, e2e security ftw 12:47 < rusty> Ack! 12:48 <+roasbeef> ok, then we'll hash out the rest in the PR ideally to have it on the merge train by the next meeting? 12:48 < cdecker> SGTM 12:48 <+roasbeef> cool 12:48 <+roasbeef> #info review to continue on PR, aiming to catch merge train in 2 weeks 12:48 < rusty> Yep! Two Weeks(TM) should be plenty of time to implement. 12:48 <+roasbeef> hehe 12:48 <+roasbeef> #topic 658 (amp) 12:48 <+roasbeef> I think this was waiting on if the pyalods were gonna be unified 12:48 <+roasbeef> but they are now, so conner can start to update this when he's around again 12:49 <+roasbeef> #action paylaods now unified, conner to update PR to reflect new paylaod structure 12:49 < joostjgr> hi guys, I am present now. i expected the meeting to be just one hour earlier because winter time 12:49 <+roasbeef> joostjgr: heh yeh timezones are the greatest 12:49 <+roasbeef> #topic 671 (invoice secret) 12:49 <+roasbeef> I think we don't need this anymore? 12:49 <+roasbeef> or nah this is for the invoice 12:50 < rusty> Side note: we found a "Bad commit_tx signature" error (it's been *years* since we had one of those!) in our implementation, w/ fee changes and reconnect and simultanous HTLCs. niftynei slid the fix in JIT for current pending release. 12:50 <+roasbeef> rusty: CL to CL? 12:51 <+roasbeef> oh I guess there was a questinon on invoice vs everythign else feature bit namespaces too in berlin 12:51 < rusty> roasbeef: yeah, that clinched it and made me finally stress enough to repro. But we saw some previous CL->LND under load, which shamefully I dismissed and blamed you. 12:51 <+roasbeef> as is, this makes a new namespace (which is correct imo), but som ehave argued that they should all be unified 12:51 < rusty> Yeah, we don't *have* a feature bit for this though. 12:51 <+roasbeef> it uses 0/1 12:51 <+roasbeef> in the PR atm 12:52 < rusty> I mean, there's no "secret" feature bit in bolt 9. 12:52 < rusty> Unless we (ab)use the tlv_onion feature/. 12:52 <+roasbeef> ahh gotcha 12:52 <+roasbeef> well are they to be defined in bolt 11 for invoices or just everything in bolt 9? 12:53 < joostjgr> tbc, the idea is to combine signaling mpp and the secret to a single invoice flag, isn't it? 12:53 <+roasbeef> rn the PR makes a new invoice feature bit namespace essentially 12:53 < rusty> joostjgr: we'd have to make a feature for it. It's really only reqd for bolt 11, so having a "I support MPP" in (say) node_announce is just showing off :) 12:54 < rusty> (Which is not a bad thing, necessarily!) 12:54 < rusty> I'm on the fence, but we can define 12/13 for "MPP", put it in BOLT9 and then use it here? 12:55 <+roasbeef> sounds like that works, no strong feeling on my end, joostjgr ? 12:55 < rusty> (If we want to aim for unification) 12:55 < joostjgr> yes, i understand we need the flag in the invoice. but just double checking that it will just be a single flag that combines mpp and secret. just as we combined it in the tlv payload 12:56 < joostjgr> or is this mpp invoice flag signaling: i support the mpp protocol, but only except single shard payments? 12:56 <+roasbeef> yes it seems so, 671 will need to be updated to reflect the desired semantics 12:56 <+roasbeef> ahh i see what you're saying 12:56 <+roasbeef> so if you signal this, then you also need to be able to combine payment shards 12:56 <+roasbeef> and not just insta settle (which is really important for mpp!!) 12:56 -!- instagibbs [~instagibb@pool-100-15-121-126.washdc.fios.verizon.net] has joined #lightning-dev 12:57 < rusty> joostjgr: Ah, very good point! Yeah, the presence of the *secret* in b11 indicated you support the TLV format. The bit means actually takes MPP. 12:57 < joostjgr> well there are three flavours: old style single shot payments, mpp payments that only have single shard (payload does contain total amt + secret) and mpp payments that consists of multiple shards. the idea of the single shot mpp payments was possibly for low powered devices 12:57 < joostjgr> i am not sold on that single-shot mpp only variation, would rather wait for this to actually emerge 12:58 < rusty> joostjgr: yeah, I'd prefer it not to exist, but is it already in the wild? 12:58 < joostjgr> is it? 12:58 < rusty> Not for c-lightning. 12:58 <+roasbeef> joostjgr: single shot variation/ so only 1 payment? 12:58 < joostjgr> we didn't release anything that decodes mpp payloads 12:59 < joostjgr> single shot mpp is a single htlc that does carry the mpp payload (totalamt = htlcamt and there's a secret) 12:59 <+roasbeef> single shot would be the donation case I think 12:59 < rusty> roasbeef: yeah, do you create TLV onions for final dest at the moment? i.e. w/o secret & total amount ? 12:59 <+roasbeef> the code is there to do so, but it isn't on any api yet 12:59 <+roasbeef> we just support the new/old formats 13:00 < rusty> Hmm, that'd be nice to avoid. We'd never get a TLV payload w/o the secret (and total amount). 13:00 < joostjgr> it is too late for that in lnd 13:00 <+roasbeef> joostjgr: too late for what? 13:00 < joostjgr> we already send tlv payloads without the usual fields 13:01 <+roasbeef> no we don't... 13:01 <+roasbeef> w/o the usual? 13:01 < joostjgr> oh sorry, with the usual 13:01 < joostjgr> so the same old fields in a tlv. that is what you rusty are referring to, isn't it? 13:01 <+roasbeef> yes we can send the tlv payload with only the reqwuired information as is 13:01 <+roasbeef> if you signal it 13:01 < rusty> joostjgr: Ah, if final node's node_announcement indicates support? OK, thought so. 13:02 < joostjgr> yes, if it signals support 13:02 < rusty> OK, no problem. We can eventually remove this, but implementations must handle it. 13:02 <+roasbeef> yeh 13:02 <+roasbeef> #action 671 to clarify being able to signal for mpp (can combine) and just presence of secret that must be included (e2e security for donation case) 13:02 < rusty> (Evenetually we'll be insisting on the secret, so we deprecate this along with legacy I guess) 13:02 <+roasbeef> and the path to do so is the even/odd bits rusty ? 13:03 <+roasbeef> it does allocate a pair 13:03 <+roasbeef> as is 13:03 < rusty> roasbeef: hmm, good q. If we *don't support* MPP, we won't have a feature bit in th b11 invoice. We'll just hve the secret. 13:03 < rusty> (Assuming FB unification). 13:03 <+roasbeef> mhmm 13:04 < rusty> I mean, we'd better not deprecate it until there's ~nobody left using it, but still. 13:05 < rusty> "Correct" solution is YA feature bit, for "suopports secret". 13:05 <+roasbeef> yeh could be even there's some brand new invoice format as well, so would be a way to do the hard hard swtich over 13:05 < rusty> roasbeef: TLV like the offer format, damn tempting. But the churn is annoying... 13:05 <+roasbeef> rusty: if you rebase #672, we can merge it 13:06 <+roasbeef> i'm gonna clsoe #680, we do it in the wild, seems to be compat w/ others, #66 on the way 13:06 < rusty> Ack. 13:06 < rusty> roasbeef: Can we do 682? 13:06 <+roasbeef> ok last one (np if ppl can't stick around) 13:07 <+roasbeef> ah didn't see it labelled 13:08 <+roasbeef> ok actions on this seem to be specyfing what to do w/ unknown chains? 13:08 <+roasbeef> or rather not a complete intersection? 13:08 <+roasbeef> #topic 682 13:08 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/682 13:08 <+roasbeef> hmm shouldn't we have one big tlv namespace at the end? 13:08 < rusty> roasbeef: yeah, I didn't specify. SHOULD close connection? 13:09 <+roasbeef> otherwise parsing can be weird, if you don't support this, but do support w/e the next init extension is 13:09 <+roasbeef> sstone: does the new acinq node add any innt level tlvs? 13:09 < rusty> roasbeef: it does add this field via adding a TLV at end. I'm confused... 13:09 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 13:09 < sstone> roasbeef: no we don't 13:10 <+roasbeef> ah nvm didn't read it properly 13:10 <+roasbeef> thought it meant like "this is where this new tlv goes", rather than "this is where all the init tlvs go 13:10 <+roasbeef> " 13:10 <+roasbeef> conner is the one that looked at it first it seems, btu not here atm, can add an action for him to follow up on it 13:10 <+roasbeef> but no major comments on my end 13:10 < rusty> Ah, I forgot that the spec actually says you MAY fail if no intersection. Don't think we need to go further with partial intersectino, I mean, depends right? 13:11 < rusty> Agreed, let's get bitconner's input here/. 13:11 <+roasbeef> #action wait on input from conner to clarify comments 13:11 <+roasbeef> #topic 688 13:11 <+roasbeef> #info anchor outputs 13:11 < rusty> Ah, he wanted to restrict traffic based on what chains. Makes sense, not to waste others' time & bw. 13:11 <+roasbeef> #link https://github.com/lightningnetwork/lightning-rfc/pull/688 13:12 <+roasbeef> joostjgr: wnana give us an overview, only a few hours old, so don't think anyof us have really looked at it 13:12 < joostjgr> yes, i took your pr rusty and modified with some latest insights 13:12 <+roasbeef> main thing seems to be infection of other scripts by the csv 1, and diff handling for second level htlcs 13:12 < joostjgr> other changes are communicating the anchor addresses in the funding flow 13:12 < rusty> Damn, sorry I haven't reviewed :( Need to go through this thoroughly sorry. 13:13 < joostjgr> and dropping all the tweaks 13:13 < niftynei> "infection" lol 13:13 < joostjgr> yes ofc, I just put it up today. but comments are welcome on the ML or PR 13:14 <+roasbeef> joostjgr: why do they need to be anything but p2wsh op_true? 13:14 <+roasbeef> w/ the sig from a new key 13:14 < rusty> joostjgr: Removing tweaks is a big change. It means that a watchtower, seeing a single unilateral close, can derive the rest of the channel history. 13:14 <+roasbeef> or an existing one 13:15 <+roasbeef> yeh removing those doesn't seem necessary and just expands the scope of it even more (beyond csv 1 infection) 13:15 < joostjgr> op_true w/ the sig? 13:15 < rusty> Yeah, using anchors as P2WPKH is also massive spam. It's *unecomonic* to spend dust. 13:15 <+roasbeef> csv flu 13:16 < rusty> First thing someone will hack in the implementation is to remove spending these. 13:16 < joostjgr> you can set your dust limit 13:17 < rusty> joostjgr: but you're paying for that up-front, and it doesn't vary with fees. 13:17 < joostjgr> hmm, you mean if fees go up, they become uneconomic to spend 13:17 < rusty> Seems like this needs to be debated on issue though. I gtg (found a coffee shop which opens at 5:30, but now have to head back and wrangle kids). 13:18 < rusty> joostjgr: I mean, we should always have some kind of dynamic dust limit, but that's a bigger change, too :( 13:18 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 13:18 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has left #lightning-dev [] 13:19 <+roasbeef> ok just wanted to intro it here, but now that the PR is up, we can hash things out on there 13:19 < joostjgr> yes, sounds good. 13:20 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has quit [Quit: Leaving] 13:20 < cdecker> Yep, I'll read it asap and respond on the PR if I find something ^^ 13:20 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 13:22 -!- Kostenko [~Kostenko@2001:8a0:7293:8900:2485:413e:dc09:c276] has quit [Ping timeout: 264 seconds] 13:23 <+roasbeef> #endmeeting 13:23 < lightningbot> Meeting ended Mon Oct 28 20:23:12 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 13:23 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-10-28-19.10.html 13:23 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-10-28-19.10.txt 13:23 < lightningbot> Log: http://www.erisian.com.au/meetbot/lightning-dev/2019/lightning-dev.2019-10-28-19.10.log.html 13:23 < cdecker> Great, thanks everybody ^^ 13:23 -!- hiroki_ [d2a585b4@pl72884.ag2001.nttpc.ne.jp] has quit [Remote host closed the connection] 13:28 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 13:37 -!- sstone [~sstone@185.186.24.109.rev.sfr.net] has quit [Quit: Leaving] 13:40 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Ping timeout: 252 seconds] 13:47 -!- Kostenko [~Kostenko@2001:8a0:72a7:f600:ec57:2195:2cc3:e7e8] has joined #lightning-dev 13:49 -!- cubancorona [~cubancoro@pool-72-77-31-161.pitbpa.ftas.verizon.net] has joined #lightning-dev 13:54 -!- ianthius [~ianthius@unaffiliated/ianthius] has quit [Ping timeout: 240 seconds] 14:00 -!- ianthius [~ianthius@unaffiliated/ianthius] has joined #lightning-dev 14:04 < sword_smith> I have a main net node running now. Any one want to make channels with me? :D 14:10 -!- mdunnio [~mdunnio@38.126.31.226] has joined #lightning-dev 14:25 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 14:30 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 268 seconds] 14:33 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 14:38 -!- ianthius [~ianthius@unaffiliated/ianthius] has quit [Ping timeout: 276 seconds] 14:39 -!- joostjgr [~joostjag@ip51cf95f6.direct-adsl.nl] has quit [Quit: Leaving] 15:06 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #lightning-dev 15:08 -!- ianthius [~ianthius@unaffiliated/ianthius] has joined #lightning-dev 15:22 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has joined #lightning-dev 15:27 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has quit [Ping timeout: 268 seconds] 15:29 -!- mdunnio [~mdunnio@38.126.31.226] has quit [Remote host closed the connection] 15:41 -!- ianthius [~ianthius@unaffiliated/ianthius] has quit [Ping timeout: 240 seconds] 15:43 -!- marcoagner [~user@2001:8a0:6a5f:5700:7bb3:6296:d274:7295] has quit [Ping timeout: 264 seconds] 15:46 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 276 seconds] 15:47 -!- ianthius [~ianthius@unaffiliated/ianthius] has joined #lightning-dev 16:02 -!- diogosergio [~diogoserg@176.24.23.243] has joined #lightning-dev 16:03 -!- __gotcha [~Thunderbi@plone/gotcha] has joined #lightning-dev 16:07 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has joined #lightning-dev 16:07 -!- diogosergio [~diogoserg@176.24.23.243] has quit [Ping timeout: 276 seconds] 16:15 -!- soju [~soju@204.126.64.99] has joined #lightning-dev 16:15 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:32 -!- laptop500 [~laptop@194.33.98.165] has quit [Ping timeout: 245 seconds] 16:37 -!- __gotcha [~Thunderbi@plone/gotcha] has quit [Ping timeout: 268 seconds] 16:51 -!- alko89 [~alko@cpe-85-10-28-138.static.amis.net] has quit [Ping timeout: 250 seconds] 16:54 -!- alko89 [~alko@cpe-85-10-28-138.static.amis.net] has joined #lightning-dev 16:57 -!- nsh [~lol@wikipedia/nsh] has quit [Max SendQ exceeded] 17:00 -!- nsh [~lol@wikipedia/nsh] has joined #lightning-dev 17:01 -!- niceplaces [~nplace@199.229.250.164] has joined #lightning-dev 17:02 -!- niceplace [~nplace@198.52.36.92] has quit [Ping timeout: 268 seconds] 17:10 -!- nobody123 [~nobody123@152.89.163.116] has quit [Ping timeout: 265 seconds] 17:13 -!- nobody123 [~nobody123@152.89.163.116] has joined #lightning-dev 17:18 -!- soju [~soju@204.126.64.99] has quit [Remote host closed the connection] 17:24 -!- rh0nj [~rh0nj@88.99.167.175] has joined #lightning-dev 17:37 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #lightning-dev 18:08 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Remote host closed the connection] 18:14 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #lightning-dev 18:17 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 276 seconds] 18:24 -!- jb55 [~jb55@gateway/tor-sasl/jb55] has quit [Quit: jb55] 18:44 -!- Kostenko [~Kostenko@2001:8a0:72a7:f600:ec57:2195:2cc3:e7e8] has quit [Quit: Leaving] 18:45 -!- Kostenko [~Kostenko@2001:8a0:72a7:f600:ec57:2195:2cc3:e7e8] has joined #lightning-dev 19:41 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has joined #lightning-dev 19:45 -!- soju [~soju@ip68-228-80-222.oc.oc.cox.net] has quit [Ping timeout: 265 seconds] 20:12 -!- gkrizek9 [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has quit [Quit: gkrizek9] 20:13 -!- gkrizek [~gkrizek@ec2-54-149-179-115.us-west-2.compute.amazonaws.com] has joined #lightning-dev 23:13 -!- rusty [~rusty@pdpc/supporter/bronze/rusty] has quit [Quit: Leaving.] 23:14 -!- bitdex [~bitdex@gateway/tor-sasl/bitdex] has joined #lightning-dev 23:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has quit [Remote host closed the connection] 23:36 -!- tryphe [~tryphe@unaffiliated/tryphe] has joined #lightning-dev --- Log closed Tue Oct 29 00:00:48 2019