19:00:15 #startmeeting 19:00:15 Meeting started Thu Feb 28 19:00:15 2019 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:00:15 Useful Commands: #action #agreed #help #info #idea #link #topic. 19:00:22 hi 19:00:23 hi 19:00:25 hi 19:00:43 hi 19:01:12 #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb 19:01:19 hi 19:01:42 PSA: tomorrow the 0.18 split-off is planned 19:01:58 bitcoin-dev mailing list has been having issues and it's broken 19:02:13 i have escalated to warren who knows linux foundation people but apparently they don't believe in email anymore 19:02:27 hmm... 19:02:35 hi 19:02:57 kanzure: no eta for a fix? 19:03:11 email has been dead for a while just not everyone has noticed yet 19:03:19 no eta for fix 19:03:29 i don't know anyone at linux foundation and i don't know who maintains this on their end 19:03:41 kanzure: any alternatives that we can move to? 19:03:50 nothing good.... 19:03:59 [13bitcoin] 15ken2812221 opened pull request #15503: msvc: Use a single file to specify the include path (06master...06msvc-include-fix) 02https://github.com/bitcoin/bitcoin/pull/15503 19:04:04 #topic bitcoin-dev mailing list 19:04:16 groups.io isn't that nice in my opinion; i don't think we would like it as a group. 19:04:17 would self-hosted be an option or would that be to "centralized"? 19:04:22 Could do it over an association 19:04:27 hi 19:04:28 self-hosted would be fine but someone would have to maintain it and fix email delivery problems etc 19:05:21 I can look into possible options/strategy for a self-hostes (eventually semi) option... in case LF list falls appart 19:05:28 *hosted 19:05:34 that would be helpful thank you 19:05:49 kanzure: if you can summarize quickly, what sort of issues does groups.io face? 19:06:00 I have a bunch of RPi laying around and a 512kb connection... *duck* 19:06:06 gwillen: sort of forces you into a web browser environment 19:06:26 hmm, really? 19:06:30 I propose to keep the UX (mailman) 19:06:36 or maybe it's time to move to something else than a mailing list 19:06:52 hi 19:07:07 If there would just be a decentralied IM service 19:07:22 it's a bit unfortunate that this discussion is held here, but the place it should be held (the ML...) isn't really an option 19:07:31 ensuring deliverability in a self-hosted setup is going to be a chalenge, the world of email has gotten increasingly hostile 19:07:41 gwillen: yea... it's dead alright 19:07:51 email is owned by google now 19:07:54 Indeed... thanks to the big players 19:08:15 I host my own email but I smarthost through a gmail account outbound 19:08:16 Well, mostly thanks to the spammers I think. 19:08:24 might as well just run a discourse forum and have all the usability advantages 19:08:26 would bring it to github (different organization) be an option? 19:08:32 provoostenator: there is enough blame to go around. :) 19:09:11 I don't think blame is the point of discussion here anyway, how do we move on ? 19:09:12 not going to solve this in this meeting, I suspect! 19:09:31 true 19:09:33 I also would like it to stay mailman. 19:09:38 (or similar) 19:09:55 A publicly readable forum seems like a reasonable solution, but chat seems terrible. Both because it's distraction and because I want to be able to respond to stuff said months ago, so it needs threads. 19:09:56 I guess someone needs to try to find out if its coming back or if we really do need to find an alternative. 19:10:06 we can try groups.io some more, we have a test group and we can just add a few more people to the test and see what people think 19:10:12 go back to bitcointalk *ducks* 19:10:21 achow101: damn I was just about to make that comment! 19:10:31 #action message kanzure if you want to be added to the groups.io test group 19:10:33 kanzure: can you add me to the test group 19:10:51 I'm really not excited about groups.io. 19:11:07 email should get everyone excited! 19:11:30 gmaxwell: supposedly mailman is unmaintained and broken-ish, according to LF? 19:12:38 self hosted mailman seems superior to groups.io 19:12:38 self-hosted mailman requires someone to become an email server administrator 19:12:38 that is an _extremely_ unfun volunteer job 19:12:38 Yes. 19:12:38 self-hosted by whom ? who's going to babysit this 19:12:38 can we pay someone to do work? 19:12:38 heh. 19:12:38 But I self-host my email since a couple of years and it's possibble 19:12:38 I already do maintain my own email server, but from the sound of it, ML makes it much harder 19:12:53 biggest problem with hosting email these days is that everyone randomly blocks you. 19:12:55 jonasschnelli: do you do your own outbound mail? No deliverability problems to gmail users, no dnsbl issues? 19:13:13 gwillen: I do 19:13:18 No problems 19:13:19 hm, very good 19:13:23 right-personal email is easier, though still not trivial; less traffic, and the only person to complain when messages don't arrive is yourself 19:13:31 I'm glad it's still possible 19:14:07 But with ML the spamlist (dnsbl, etc.) become more of a problem.. 19:14:09 I used to run my own email server, but gave up when gmail blackholed my last vps host 19:14:15 But better to manage that than no ML at all 19:14:41 3-4 IPv4 addresses to switch over to makes it more robust... 19:15:01 we could just put text files in a git repository 19:15:10 if you're going through that trouble might as well pay some service to do it 19:15:24 I also don't think we mind too much if the ML suffers a little from users own servers blacklisting it. There are public archives. 19:15:25 There are also managed mailman hosting 19:15:41 I think a paid professional service is fine, as long as the archives are public and we have a way of detecting censorship. 19:15:41 someone does managed mailman hosting services? 19:15:53 Can we please just get a definitive from LF before we sink tons of effort into this? 19:16:08 linux foundation has consistently said they are killing this 19:16:11 according to warren 19:16:18 Agree with gmaxwell... (before continue this discussion) 19:16:26 Can we please not filter everything through warren? 19:16:35 well LF's moderation has been offline for quite some time now, I don't think it's coming back tbh, especially as they've already warned months before that this was going to end 19:16:50 i'd be happy to get in contact with someone at linux foundation myself if i knew who to pester 19:16:50 How are the linux kernel lists and such running? 19:17:08 let's ask rusty, he's the resident kernel hacker 19:17:11 If you are having trouble using the lists, please contact mailman@lists.linuxfoundation.org. 19:17:17 (from https://lists.linuxfoundation.org/mailman/listinfo) 19:17:29 admindb is returning "503 first byte timeout" 19:18:25 can't we pretend that bitcoind is a gpu driver and get a freedesktop list ... 19:18:32 I think we should have moved off the list when it was still working. Now there is no way to notify subscribers that it will move to a different place 19:18:34 wumpus: a few years too late :p 19:18:43 sipa: hehe 19:19:09 MarcoFalke: but who would have expectes it to break like this, with solution in sight, with no warning? 19:19:27 They warned us months ago, multiple times. No? 19:19:40 they warned 19:19:46 they warned 19:19:49 That's what kazure claims warren says. 19:20:06 I only ever heard warren saying stuff and it didn't sound credible. 19:20:07 that's what i claim provoostenator says i claim warren claims 19:20:25 (e.g. it was mixed up in mania about jeff garzik being on their board) 19:20:29 i have emailed mailman@lists.linuxfoundation.org as of a few moments ago 19:21:37 What was the reason against a google group? 19:21:42 At least it would be reliable 19:21:56 oh noo 19:21:57 help killing email further? 19:22:04 I won't use it. 19:22:04 i don't think they intend to support google groups forever 19:22:08 Google tends to shut down useful services with crazy short notice. 19:22:22 I'd so prefer a self-hosted discourse forum to that 19:22:41 anyway, we're still testing groups.io so others should feel free to email warrentest@groups.io 19:22:42 at least it doesn't require a google account 19:22:43 you mean bitcointalk.org? :/ 19:22:50 btw, re linux kernel ML - it's not hosted by LF it looks like 19:22:54 any help in reaching linux foundation would be appreciated by me 19:22:58 also don't forget that it needs to be acceptable to a lot of pelple who aren't here 19:23:03 and someone should ask rusty about lkml 19:23:09 http://vger.kernel.org/majordomo-info.html 19:23:16 to be honest 19:23:19 yea, can we get something on vger.kernel.org? 19:23:19 majordomo, isn't that older than me? 19:23:22 this isn't a *bitcoin core* topic at all 19:23:24 that seems to be where everything else is 19:23:30 wumpus: that's my point 19:23:36 this is about bitcoin protocol discussion 19:23:45 ok, -> #bitcoin-dev 19:23:55 oh god useless zombie channel 19:24:00 and it shoudl be organized separately 19:24:01 the intetnet is busted. so sad. 19:24:04 We could revive Usenet. 19:24:04 okay thanks for tolerating the topic for a few minutes; i'll keep you updated. 19:24:15 Lets all just email kanzure from now on and he can forward to everyone? :P 19:24:22 gmaxwell: ack 19:24:30 i sort of already do that so... yes. 19:24:38 heh.. the real "mailman" 19:24:42 please send mail via github pr to bitcoin.ninja 19:25:01 do we have anything else to discuss? 19:25:13 how about actual bitcoin core things? 19:25:28 http://www.smbc-comics.com/index.php?db=comics&id=2305 kanzure: a transistional superintelligence. 19:25:40 0.18 split off tomorrow... any 0.18 things left to discuss? 19:26:13 "yay" 19:26:22 there are 0.18 tagged things that need review. 19:26:35 gmaxwell: heh 19:26:49 https://github.com/bitcoin/bitcoin/milestone/35 19:27:01 In particular #15486 is very new. 19:27:01 they can go in after fork off of coirse 19:27:03 https://github.com/bitcoin/bitcoin/issues/15486 | [net] Allow feeler connections to go to the same netgroup as existing outbound peers by sdaftuar · Pull Request #15486 · bitcoin/bitcoin · GitHub 19:27:09 #15497 #15486 #15402 19:27:10 https://github.com/bitcoin/bitcoin/issues/15497 | Consistent range arguments in scantxoutset/importmulti/deriveaddresses by sipa · Pull Request #15497 · bitcoin/bitcoin · GitHub 19:27:11 https://github.com/bitcoin/bitcoin/issues/15486 | [net] Allow feeler connections to go to the same netgroup as existing outbound peers by sdaftuar · Pull Request #15486 · bitcoin/bitcoin · GitHub 19:27:14 https://github.com/bitcoin/bitcoin/issues/15402 | Granular invalidateblock and RewindBlockIndex by sipa · Pull Request #15402 · bitcoin/bitcoin · GitHub 19:27:29 Otherwise, I don't think there is anything to say? 19:28:33 sure, things can be backported after the 0.18 fork, but that's intended for last-minute bugfixes and such we don't know about yet 19:28:59 the idea is that everything tagged 0.18 is merged before the fork 19:29:07 aight 19:29:24 so, please help review ^^ 19:30:11 I think the hardest to review is the P2P one by sdaftuar 19:30:48 cfields_ if you're there please take a look at it ^^ 19:31:38 sdaftuar: for easier review the PR description, or comment, could use a crash course in what feeler connections are and such. 19:32:14 not that sipa's are trivial 19:32:14 I think I vaguely understand what's going on based on the back and forth discussion though. 19:32:57 provoostenator: #8282 19:33:01 https://github.com/bitcoin/bitcoin/issues/8282 | net: Feeler connections to increase online addrs in the tried table. by EthanHeilman · Pull Request #8282 · bitcoin/bitcoin · GitHub 19:33:02 provoostenator: best source is PR 8282. 19:33:26 Thanks, will give that a read and then review tommorrow. 19:33:28 Also, in particuarly, the stuff being changed here is try before evict which IIRC was a different PR. 19:33:37 #9037 19:33:41 https://github.com/bitcoin/bitcoin/issues/9037 | net: Add test-before-evict discipline to addrman by EthanHeilman · Pull Request #9037 · bitcoin/bitcoin · GitHub 19:33:53 Thanks. 19:34:00 #6355 and 9037 19:34:02 https://github.com/bitcoin/bitcoin/issues/6355 | Added test-before-evict discipline in Addrman, feeler connections. by EthanHeilman · Pull Request #6355 · bitcoin/bitcoin · GitHub 19:35:26 yes if you have any questions about it, just ask 19:35:32 any other topics? 19:36:00 is there a wallet meeting tomorrow? We postponed last week's 19:36:23 do we have meshcollider? 19:36:25 good question; meshcollider, jonasschnelli ? 19:36:45 I thought we were just skipping last week's 19:36:45 It's it up for vote, I vote yes please 19:36:50 I think I never participated on one of those meetings (shame on me) 19:37:04 if you have pressing wallet topics to discuss we should have a wallet meeting 19:37:21 [announcement] In the last 8 days I've merged 17 PRs in libsecp256k1 and closed about twice as many issues. So if anyone was holding back on offering improvements because there wasn't much activity there, thats no longer the case. (Also, most of what remains isn't getting merged quickly, so if you were expecting otherwise please feel free to ping on that repo) 19:38:02 gmaxwell: good to know, I still intend to make a risc-v asm implementation of some things 19:38:53 \O/ 19:38:58 oh nice 19:39:23 I should get a risc-v VM going then. :) 19:39:24 Nothing urgent wallet wise from my end. I started a very, very rough draft of a descriptor based wallet in #15487. I'll ping people when that's a bit further along. 19:39:25 https://github.com/bitcoin/bitcoin/issues/15487 | [WIP] descriptor based wallet by Sjors · Pull Request #15487 · bitcoin/bitcoin · GitHub 19:39:30 yes :) 19:40:33 Nice! provoostenator... I'll take a closer look soon 19:40:50 If someone wants to whip up a Descriptor instance method that can scan the blockchain for relevant transactions that would help. 19:41:07 provoostenator: that looks interesting 19:41:20 gmaxwell: there's apparently $8 RISC-V hardware now (not much memory, but maybe irrelevant for just libsecp256k1) 19:41:38 provoostenator: that sounds like the wrong approach; descriptors shouldn't need to know about the blockchain 19:41:48 easier to debug on a VM than a microcontroller. :P 19:41:59 provoostenator, we're already using descriptor-based detection when scanning blocks I thought 19:42:03 and it shouldn't ne needed either, as you can compute the sPKs and scan for those 19:42:09 for detecting used keys at least 19:42:10 instagibbs: nope 19:42:14 yes 19:42:18 but not for ismine 19:42:22 sipa: somethign should do such scanning, I don't care what. 19:42:31 right, but I'm saying I'm not sure what the big leap is :) 19:42:38 details aside 19:43:53 luke-jr: yea for just that the amount of memory doesn't matter, I was eventually able to test most of secp256k1 on the HiFive board with 16kB of memory (+ lots of read-only flash) 19:44:30 but yes VM is definitely easier for debugging than JTAG+openocd 19:46:26 no more topics I guess? 19:46:57 provoostenator, I'll take a look at your WIP for tomorrow if I get the time 19:46:58 provoostenator: the hardest part is getting an equivalent of the keypool, i think - we still need lookahead to find gaps, but it needs to be something consisting of sPKs (and related indexes into descriptors) rather than just keys 19:47:39 "(and related indexes into descriptors)" hm? 19:47:57 so that we can remember how far the expand them 19:48:25 ah, numbers, not like txindex indexes 19:48:39 ah yes 19:49:21 In my WIP I added a WalletDescriptor class in walletdb.h, which I image could track the last seen and/or last resevered (with getnewaddress) index. 19:49:22 somehow I think "indices" disambiguates it even though they're technically identical 19:49:28 Maybe it doesn't need a new class. 19:50:06 provoostenator: it needs a lot more 19:50:21 i have a gist that describes the necessary things i think 19:50:27 I added a lot a restrictions to the initial attempt that makes things a bit easier. 19:50:37 No private keys for example :-) 19:50:52 But of course we still need to architect it in a way that's not a dead end. 19:51:30 yeah 19:52:04 Another shortcut I took was serializing the descriptor as a string, which is also not a good long term solution I think. 19:52:49 I found myself needing unique identifiers... 19:52:57 (maybe your gist already covers all that) 19:55:07 I guess we can close the meeting? 19:55:29 yeah 19:55:31 #endmeeting