12018-09-13T00:05:37 *** grubles has quit IRC
22018-09-13T00:07:15 *** grubles has joined #bitcoin-core-dev
32018-09-13T00:14:55 *** grubles has quit IRC
42018-09-13T00:35:54 *** Kvaciral has quit IRC
52018-09-13T00:42:14 <pierre_rochard> ken2812221: I took a look at #14007 in bitcoinacks.com, I wasn't picking up "tack" or "re-ack" in my parser, that's fixed now. Please don't hesitate to file an issue or PM me if you notice inconsistencies, I do want this to be a reliable tool
62018-09-13T00:42:17 <gribble> https://github.com/bitcoin/bitcoin/issues/14007 | tests: Run functional test on Windows and enable it on Appveyor by ken2812221 · Pull Request #14007 · bitcoin/bitcoin · GitHub
72018-09-13T00:44:04 *** promag has joined #bitcoin-core-dev
82018-09-13T00:49:26 *** promag has quit IRC
92018-09-13T00:51:20 *** promag has joined #bitcoin-core-dev
102018-09-13T00:51:37 *** Kvaciral has joined #bitcoin-core-dev
112018-09-13T00:52:08 *** Chris_Stewart_5 has joined #bitcoin-core-dev
122018-09-13T00:53:14 *** dqx has quit IRC
132018-09-13T00:53:46 *** drexl has quit IRC
142018-09-13T00:54:35 *** Krellan has quit IRC
152018-09-13T00:55:17 *** Krellan has joined #bitcoin-core-dev
162018-09-13T00:55:27 *** promag has quit IRC
172018-09-13T00:59:37 *** grubles has joined #bitcoin-core-dev
182018-09-13T01:14:39 *** jarthur has joined #bitcoin-core-dev
192018-09-13T01:19:46 *** farmerwampum_ has joined #bitcoin-core-dev
202018-09-13T01:21:18 *** farmerwampum has quit IRC
212018-09-13T01:21:18 *** farmerwampum_ is now known as farmerwampum
222018-09-13T01:34:47 *** promag has joined #bitcoin-core-dev
232018-09-13T01:38:55 *** promag has quit IRC
242018-09-13T01:46:22 *** phwalkr has quit IRC
252018-09-13T01:52:47 *** promag has joined #bitcoin-core-dev
262018-09-13T01:57:13 *** promag has quit IRC
272018-09-13T02:00:03 *** grubles has quit IRC
282018-09-13T02:08:27 *** RubenSomsen has joined #bitcoin-core-dev
292018-09-13T02:21:17 *** Chris_Stewart_5 has quit IRC
302018-09-13T02:21:54 *** promag has joined #bitcoin-core-dev
312018-09-13T02:26:09 *** promag has quit IRC
322018-09-13T02:32:12 *** promag has joined #bitcoin-core-dev
332018-09-13T02:36:25 *** promag has quit IRC
342018-09-13T02:51:18 *** phwalkr has joined #bitcoin-core-dev
352018-09-13T02:52:05 *** promag has joined #bitcoin-core-dev
362018-09-13T02:55:51 *** phwalkr has quit IRC
372018-09-13T02:59:21 *** promag has quit IRC
382018-09-13T03:02:58 *** Krellan has quit IRC
392018-09-13T03:03:40 *** Krellan has joined #bitcoin-core-dev
402018-09-13T03:29:44 *** promag has joined #bitcoin-core-dev
412018-09-13T03:34:13 *** promag has quit IRC
422018-09-13T03:52:00 *** miknotauro has joined #bitcoin-core-dev
432018-09-13T03:54:26 *** itaseski has quit IRC
442018-09-13T04:08:24 *** promag has joined #bitcoin-core-dev
452018-09-13T04:12:33 *** promag has quit IRC
462018-09-13T04:12:42 <kallewoof> jimpo: reading https://github.com/bitcoin/bips/pull/725#pullrequestreview-154741923 it looks like you're suggesting the proof of funds should be a (fakeish) transaction, and the messsage signing should not be. Am I understanding that right? If so, it seems like you could just do transaction in both cases to simplify the spec. I.e. for signing message, craft two txs with the latter spending the former and former using
472018-09-13T04:12:42 <kallewoof> scriptPubKey of proof
482018-09-13T04:17:51 *** promag has joined #bitcoin-core-dev
492018-09-13T04:22:12 *** promag has quit IRC
502018-09-13T04:40:03 *** jrayhawk has quit IRC
512018-09-13T04:40:52 *** jrayhawk has joined #bitcoin-core-dev
522018-09-13T04:48:30 *** dongcarl has quit IRC
532018-09-13T05:08:16 *** Krellan has quit IRC
542018-09-13T05:15:10 *** promag has joined #bitcoin-core-dev
552018-09-13T05:19:52 *** promag has quit IRC
562018-09-13T05:23:51 *** YLuRIE9 has joined #bitcoin-core-dev
572018-09-13T05:25:35 *** YLuRIE9 has quit IRC
582018-09-13T05:28:59 *** Krellan has joined #bitcoin-core-dev
592018-09-13T06:08:08 <jimpo> kallewoof: What about the data being signed? If I wanted you to sign an arbitrary message, would it be in an OP_RETURN or something?
602018-09-13T06:09:06 <kallewoof> jimpo: for proof of funds? I am thinking there'd be a txin with prevout=<sighash> and n=0 or something (where <sighash> includes the message)
612018-09-13T06:09:29 <kallewoof> you meant for signmessage, actually. same thing though.
622018-09-13T06:09:30 <jimpo> Yeah, I think you're understanding me right. But I'm suggesting using the fake transaction to generate the sighash, but as for as actual RPC messages and payloads and stuff, end users would just interact with the proof container, not the transaction itself.
632018-09-13T06:10:04 <kallewoof> right
642018-09-13T06:10:04 <jimpo> :-/ For sign message, that just seems overcomplicated
652018-09-13T06:10:56 <kallewoof> I have already had people object to signmessage being a transaction for UI reasons (e.g. the trezor people).
662018-09-13T06:11:15 <jimpo> manufacturing a tx for proof of funds makes sense to me because you are saying that this transaction with these already exiting UTXOs could actually exist
672018-09-13T06:11:25 <kallewoof> Right.
682018-09-13T06:11:44 <jimpo> but for sign message, manufacturing two dummy transactions seems very artificial and I don't see the benefit
692018-09-13T06:12:34 *** Krellan has quit IRC
702018-09-13T06:12:54 <kallewoof> The only benefit would be in that the two protocols "meet up" after the custom tx creation point. It's not a big deal IMO.
712018-09-13T06:13:34 <jimpo> Yeah, I see them meeting up at the sighash point :-)
722018-09-13T06:14:18 <kallewoof> I should probably write the code for this to geta better idea for what is actually necessary.
732018-09-13T06:27:58 *** Guest26637 has quit IRC
742018-09-13T06:28:24 *** jarthur has quit IRC
752018-09-13T06:31:16 *** Krellan has joined #bitcoin-core-dev
762018-09-13T06:53:27 *** promag has joined #bitcoin-core-dev
772018-09-13T06:57:42 *** promag has quit IRC
782018-09-13T07:01:27 *** promag has joined #bitcoin-core-dev
792018-09-13T07:03:07 *** setpill has joined #bitcoin-core-dev
802018-09-13T07:05:34 *** promag has quit IRC
812018-09-13T07:05:57 *** arubi has quit IRC
822018-09-13T07:06:21 *** arubi has joined #bitcoin-core-dev
832018-09-13T07:11:44 *** promag has joined #bitcoin-core-dev
842018-09-13T07:15:53 *** promag has quit IRC
852018-09-13T07:35:08 *** Guyver2 has joined #bitcoin-core-dev
862018-09-13T07:35:09 *** rex4539 has quit IRC
872018-09-13T07:37:41 *** morcos has quit IRC
882018-09-13T07:37:58 *** morcos has joined #bitcoin-core-dev
892018-09-13T07:49:33 *** Krellan has quit IRC
902018-09-13T08:09:44 <wumpus> oh noo another linter
912018-09-13T08:10:35 <wumpus> so tired of this https://github.com/bitcoin/bitcoin/pull/14205#issuecomment-420921267
922018-09-13T08:14:26 <wumpus> can you all please start working on user-facing, or network-facing issues, not this endless fluffing of the source cdoe
932018-09-13T08:18:07 <wumpus> "oh no, someone used the wrong word for NULL, we must make sure this NEVER happens again"
942018-09-13T08:22:34 *** elichai2 has joined #bitcoin-core-dev
952018-09-13T08:24:33 *** timothy has joined #bitcoin-core-dev
962018-09-13T08:25:58 *** phwalkr has joined #bitcoin-core-dev
972018-09-13T08:26:19 *** phwalkr has joined #bitcoin-core-dev
982018-09-13T08:32:43 <wumpus> while issues that people report pretty much go ignored: say, #14200
992018-09-13T08:32:44 <gribble> https://github.com/bitcoin/bitcoin/issues/14200 | bitcoind aborts with boost exception · Issue #14200 · bitcoin/bitcoin · GitHub
1002018-09-13T08:33:55 *** rex4539 has joined #bitcoin-core-dev
1012018-09-13T08:34:58 *** phwalkr has quit IRC
1022018-09-13T08:45:18 <wumpus> sorry :-(
1032018-09-13T08:54:04 *** RubenSomsen has quit IRC
1042018-09-13T08:55:32 <luke-jr> wumpus: you're not wrong
1052018-09-13T08:57:38 *** Zenton has joined #bitcoin-core-dev
1062018-09-13T08:59:12 <luke-jr> wumpus: my manpage has EINVAL as a possible return value..
1072018-09-13T08:59:44 <wumpus> luke-jr: can you pastebin it please
1082018-09-13T09:00:09 <luke-jr> just posted here https://github.com/bitcoin/bitcoin/issues/14200#issuecomment-420935509
1092018-09-13T09:00:14 <wumpus> oh! great
1102018-09-13T09:00:24 <wumpus> apparently you have a much more extensive manpage
1112018-09-13T09:00:48 <luke-jr> IEEE/The Open Group 2013 PTHREAD_COND_TIMEDWAIT(3P)
1122018-09-13T09:01:23 <wumpus> LinuxThreads PTHREAD_COND(3)
1132018-09-13T09:01:36 <luke-jr> interesting
1142018-09-13T09:01:55 <luke-jr> sys-apps/man-pages-posix has a non-standard license; maybe Debian considers it non-free
1152018-09-13T09:02:10 <luke-jr> (it requires deviations from the POSIX standard to be explicitly noted)
1162018-09-13T09:02:49 *** echonaut has quit IRC
1172018-09-13T09:03:11 *** echonaut has joined #bitcoin-core-dev
1182018-09-13T09:03:13 <wumpus> so I guess mine describes linux's specific behavior, and the one you have the standard, which is more useful in this case
1192018-09-13T09:03:37 <luke-jr> well, this EINVAL sounds pretty implementation-specific
1202018-09-13T09:03:48 <luke-jr> unless there's a standard limit on the abstime param
1212018-09-13T09:04:21 <luke-jr> http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_cond_timedwait.html says [EINVAL] The value specified by abstime is invalid.
1222018-09-13T09:05:54 <luke-jr> following the "this version is outdated" link at the top has the explicit limits
1232018-09-13T09:06:28 <luke-jr> Change history has Issue 6: IEEE Std 1003.1-2001/Cor 2-2004, item XSH/TC2/D6/91 is applied, updating the ERRORS section to remove the error case related to abstime from the pthread_cond_wait() function, and to make the error case related to abstime mandatory for pthread_cond_timedwait() for consistency with other functions.
1242018-09-13T09:06:39 <luke-jr> so I guess this was to make the failure deterministic?
1252018-09-13T09:06:48 <wumpus> yes, makes sense
1262018-09-13T09:07:28 <wumpus> an invalid *absolute* time passed in would be really strange
1272018-09-13T09:08:23 <wumpus> I can see relative times ending up all over the place, including negative, but absolute ones
1282018-09-13T09:08:44 <luke-jr> yes, an absolute max is silly here :/
1292018-09-13T09:09:13 <luke-jr> oh, the nanosecond value is a *part*
1302018-09-13T09:09:31 <luke-jr> ie, the 1000mil should overflow into seconds
1312018-09-13T09:10:10 <wumpus> yes, nanoseconds field ending up >= 1000 million would be unequivocally wrong
1322018-09-13T09:10:46 <luke-jr> What's this boost::exception_detail::clone_impl<boost::exception_detail::error_info_injectorboost::condition_error above?
1332018-09-13T09:11:53 <luke-jr> maybe there's an invalid object somewhere?
1342018-09-13T09:11:56 <wumpus> I don't know; if this was simple C code we'd probably already have found the problem, all this c++/boost exception verboseness adds nothing
1352018-09-13T09:12:26 <wumpus> all those conversions between time formats, too
1362018-09-13T09:12:39 <wumpus> what is a boost::chrono::system_clock::time_point, even
1372018-09-13T09:13:26 <luke-jr> does GDB work on WSL?
1382018-09-13T09:13:38 <wumpus> it's not a simple object wrapping seconds and nano/microseconds at least...
1392018-09-13T09:13:46 <luke-jr> maybe he can get a backtrace and/or run some print commands
1402018-09-13T09:14:02 <wumpus> I don't know
1412018-09-13T09:16:18 <wumpus> so it is likely that timeToWaitFor passed to wait_unti is invalid, it would probably help trying to print that
1422018-09-13T09:16:47 <wumpus> assuming this uses the BOOST_VERSION >= 105000 arm, of course
1432018-09-13T09:17:14 <luke-jr> I figure a backtrace will help find out what we're actually using for the timeout object on our end
1442018-09-13T09:17:21 <wumpus> if it uses the other one with toPosixTime, well here be dragons...
1452018-09-13T09:17:29 <luke-jr> no point looking at the post-conversions value, since we can already guess it's invalid
1462018-09-13T09:18:00 <wumpus> timeToWaitFor is the pre-conversion value
1472018-09-13T09:26:34 <wumpus> we could ask what was the last version that did work, and see if there's been changes to that code since
1482018-09-13T09:26:56 <wumpus> appaarently 0.16.x is all broken, but they don't say whether 0.15.x worked
1492018-09-13T09:29:13 <luke-jr> has WSL been around that long? O.o
1502018-09-13T09:29:39 <wumpus> it's been around for a while (as beta feature)
1512018-09-13T09:30:32 <wumpus> even years ago when I still had at least one windows computer
1522018-09-13T09:54:24 *** promag has joined #bitcoin-core-dev
1532018-09-13T10:07:36 *** Giszmo has quit IRC
1542018-09-13T10:07:59 *** ghost43 has quit IRC
1552018-09-13T10:14:48 *** Giszmo has joined #bitcoin-core-dev
1562018-09-13T10:21:04 *** ghost43 has joined #bitcoin-core-dev
1572018-09-13T10:27:52 *** phwalkr has joined #bitcoin-core-dev
1582018-09-13T10:29:14 *** phwalkr has quit IRC
1592018-09-13T10:35:17 *** AaronvanW has joined #bitcoin-core-dev
1602018-09-13T11:16:04 *** setpill has quit IRC
1612018-09-13T11:18:30 *** setpill has joined #bitcoin-core-dev
1622018-09-13T11:30:44 *** RubenSomsen has joined #bitcoin-core-dev
1632018-09-13T11:32:50 *** setpill has quit IRC
1642018-09-13T11:33:21 *** Emcy has quit IRC
1652018-09-13T11:50:43 *** drexl has joined #bitcoin-core-dev
1662018-09-13T12:01:31 *** SopaXorzTaker has joined #bitcoin-core-dev
1672018-09-13T12:04:09 *** da2ce7 has joined #bitcoin-core-dev
1682018-09-13T12:13:05 *** rex4539 has quit IRC
1692018-09-13T12:18:13 *** da2ce7 has quit IRC
1702018-09-13T12:20:16 *** promag has quit IRC
1712018-09-13T12:38:08 *** profmac has quit IRC
1722018-09-13T12:48:57 <ken2812221> pierre_rochard: thanks!!
1732018-09-13T12:49:29 *** rex4539 has joined #bitcoin-core-dev
1742018-09-13T12:56:21 *** rex4539 has quit IRC
1752018-09-13T12:57:22 *** rex4539 has joined #bitcoin-core-dev
1762018-09-13T13:08:27 *** rex4539 has quit IRC
1772018-09-13T13:26:34 *** Mrrt has joined #bitcoin-core-dev
1782018-09-13T13:35:41 *** Chris_Stewart_5 has joined #bitcoin-core-dev
1792018-09-13T14:14:37 *** hebasto has joined #bitcoin-core-dev
1802018-09-13T14:15:39 *** jarthur has joined #bitcoin-core-dev
1812018-09-13T14:26:37 *** promag has joined #bitcoin-core-dev
1822018-09-13T14:35:22 *** michaelsdunn1 has joined #bitcoin-core-dev
1832018-09-13T14:55:15 *** nullptr| has quit IRC
1842018-09-13T14:57:11 *** nullptr| has joined #bitcoin-core-dev
1852018-09-13T15:04:55 *** ExtraCrispy has joined #bitcoin-core-dev
1862018-09-13T16:00:17 *** promag has quit IRC
1872018-09-13T16:30:03 *** esotericnonsense has quit IRC
1882018-09-13T16:30:29 *** belcher has joined #bitcoin-core-dev
1892018-09-13T16:31:29 *** esotericnonsense has joined #bitcoin-core-dev
1902018-09-13T16:42:34 *** jhfrontz has joined #bitcoin-core-dev
1912018-09-13T16:44:47 *** jhfrontz has quit IRC
1922018-09-13T16:44:58 *** jhfrontz has joined #bitcoin-core-dev
1932018-09-13T16:46:55 *** Krellan has joined #bitcoin-core-dev
1942018-09-13T17:03:44 *** Krellan has quit IRC
1952018-09-13T17:08:51 *** jhfrontz has quit IRC
1962018-09-13T17:10:23 *** SopaXorzTaker has quit IRC
1972018-09-13T17:11:44 <wumpus> MarcoFalke: interesting, it looks like we have no direct dependency on LIBSSL at all anymore
1982018-09-13T17:12:06 *** jhfrontz has joined #bitcoin-core-dev
1992018-09-13T17:12:16 <wumpus> (doing a gitian build just to be sure)
2002018-09-13T17:13:13 <wumpus> paymentrequestplus.cpp does some manipulation of certificates, but that appears to be part of crypto, not ssl
2012018-09-13T17:18:26 *** Guyver2 has quit IRC
2022018-09-13T17:22:06 *** promag has joined #bitcoin-core-dev
2032018-09-13T17:25:17 <gmaxwell> \O/
2042018-09-13T17:28:15 *** grubles has joined #bitcoin-core-dev
2052018-09-13T17:31:04 *** jhfrontz has quit IRC
2062018-09-13T17:31:30 *** promag has quit IRC
2072018-09-13T17:38:25 *** timothy has quit IRC
2082018-09-13T17:47:07 *** masonicboom has joined #bitcoin-core-dev
2092018-09-13T17:49:32 *** Zenton has quit IRC
2102018-09-13T18:00:20 *** jarthur has quit IRC
2112018-09-13T18:00:28 *** jarthur has joined #bitcoin-core-dev
2122018-09-13T18:10:26 *** jarthur has quit IRC
2132018-09-13T18:10:32 *** jarthur has joined #bitcoin-core-dev
2142018-09-13T18:19:51 *** grubles has quit IRC
2152018-09-13T18:21:25 *** Victorsueca has quit IRC
2162018-09-13T18:22:33 *** Victorsueca has joined #bitcoin-core-dev
2172018-09-13T18:24:16 *** elichai2 has quit IRC
2182018-09-13T18:24:31 *** Krellan has joined #bitcoin-core-dev
2192018-09-13T18:24:57 *** Krellan has quit IRC
2202018-09-13T18:26:38 *** Krellan has joined #bitcoin-core-dev
2212018-09-13T18:30:06 *** rafalcpp has quit IRC
2222018-09-13T18:30:10 *** d_t has joined #bitcoin-core-dev
2232018-09-13T18:30:18 *** queip has quit IRC
2242018-09-13T18:30:22 *** contrapumpkin has quit IRC
2252018-09-13T18:31:26 *** copumpkin has joined #bitcoin-core-dev
2262018-09-13T18:34:42 *** Krellan has quit IRC
2272018-09-13T18:56:47 *** clarkmoody has joined #bitcoin-core-dev
2282018-09-13T18:57:58 *** promag has joined #bitcoin-core-dev
2292018-09-13T19:00:05 <wumpus> #startmeeting
2302018-09-13T19:00:05 <lightningbot> Meeting started Thu Sep 13 19:00:05 2018 UTC. The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2312018-09-13T19:00:05 <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2322018-09-13T19:00:06 <MarcoFalke> Would have to remove the #include of libssl as well?
2332018-09-13T19:00:13 <MarcoFalke> oh meeting
2342018-09-13T19:00:16 <wumpus> MarcoFalke: yep
2352018-09-13T19:00:17 <provoostenator> hi
2362018-09-13T19:00:24 <promag> hi
2372018-09-13T19:00:36 <MarcoFalke> I wonder if it is possible to build openssl with just libcrypto and not libssl
2382018-09-13T19:01:17 <jnewbery> hi
2392018-09-13T19:01:49 <wumpus> any proposed topics?
2402018-09-13T19:01:54 <jonasschnelli> hi
2412018-09-13T19:01:59 <meshcollider> Hi
2422018-09-13T19:02:04 <MarcoFalke> Have we had issues reported for rc3 of 0.17.0?
2432018-09-13T19:02:04 *** Krellan has joined #bitcoin-core-dev
2442018-09-13T19:02:22 <provoostenator> MarcoFalke: probably not: https://github.com/openssl/openssl/issues/4597
2452018-09-13T19:02:58 <wumpus> MarcoFalke: I don't think so
2462018-09-13T19:02:59 <achow101> hi
2472018-09-13T19:03:07 <achow101> MarcoFalke: there was that thing sipa pointed out
2482018-09-13T19:03:09 <achow101> with psbt
2492018-09-13T19:03:19 <achow101> #14196
2502018-09-13T19:03:20 <gribble> https://github.com/bitcoin/bitcoin/issues/14196 | [0.17][psbt] always drop the unnecessary utxo and convert non-witness utxo to witness when necessary by achow101 · Pull Request #14196 · bitcoin/bitcoin · GitHubAsset 1Asset 1
2512018-09-13T19:03:54 <achow101> I'm not sure if it is necessarily a bug, it is annoying though when encountered
2522018-09-13T19:04:11 <promag> regarding missing pieces for multi wallets, hope to get #13100 and #13339 done shortly
2532018-09-13T19:04:14 <gribble> https://github.com/bitcoin/bitcoin/issues/13100 | gui: Add dynamic wallets support by promag · Pull Request #13100 · bitcoin/bitcoin · GitHub
2542018-09-13T19:04:16 <gribble> https://github.com/bitcoin/bitcoin/issues/13339 | wallet: Replace %w by wallet name in -walletnotify script by promag · Pull Request #13339 · bitcoin/bitcoin · GitHub
2552018-09-13T19:04:34 <MarcoFalke> Ok, we should put that up as high priority and then target rc4 end of next week?
2562018-09-13T19:05:01 <wumpus> yes, good idea
2572018-09-13T19:05:08 <sipa> i encountered this issue while actually trying to use psbt btw :)
2582018-09-13T19:05:23 <MarcoFalke> Also I'd like to see the release notes amended with the list of merged changes. wumpus mind doing that or sharing the script :) ?
2592018-09-13T19:05:36 <wumpus> MarcoFalke: huh didn't I add those?
2602018-09-13T19:05:50 <wumpus> last week was like a blur
2612018-09-13T19:06:03 <sipa> still too busy this week, but if someone could add scantxoutset to the release notes?
2622018-09-13T19:06:07 *** Krellan has quit IRC
2632018-09-13T19:06:49 <wumpus> yes I actually added the PRs and authors: https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes
2642018-09-13T19:06:54 <MarcoFalke> wumpus: Thx. I've misssed yesterdays commit
2652018-09-13T19:08:22 <jonasschnelli> Anyone up for writing a short part about scantxoutset for the 0.17 release notes?
2662018-09-13T19:08:27 <wumpus> as for sharing the script, if you don't mind it's a mess, will push it into devtools soon
2672018-09-13T19:09:25 <promag> I can give a try to scantxoutset release notes
2682018-09-13T19:09:46 <wumpus> promag: thanks!
2692018-09-13T19:10:09 <jnewbery> some quick proposed topics: refactor/linter PRs , wallet maintainer , archiving meeting notes
2702018-09-13T19:10:37 <jonasschnelli> promag: thanks!
2712018-09-13T19:11:10 <wumpus> added 14197 to high prio
2722018-09-13T19:11:32 <promag> #14197
2732018-09-13T19:11:34 <gribble> https://github.com/bitcoin/bitcoin/issues/14197 | [psbt] Convert non-witness UTXOs to witness if witness sig created by achow101 · Pull Request #14197 · bitcoin/bitcoin · GitHub
2742018-09-13T19:11:40 <wumpus> #topic refactor/linter PRs
2752018-09-13T19:11:56 <wumpus> stop it stop it stop it stop it stop it stop it stop it stop it
2762018-09-13T19:11:58 <wumpus> thx :p
2772018-09-13T19:12:07 <jnewbery> I think a lot of people get the sense that there are a lot of refactor/linter PRs these days
2782018-09-13T19:12:50 <wumpus> yes, it's too often
2792018-09-13T19:12:53 <jnewbery> I'd hate to discourage any contributions, but I think it would be a better use of reviewer time and people would enjoy working on the project more if more PRs were focused on features/bugfixes :)
2802018-09-13T19:12:55 <achow101> wumpus: unfortunately practicalswift isn't here to hear that
2812018-09-13T19:13:05 <meshcollider> Lol
2822018-09-13T19:13:15 <promag> we can write a lint to prevent new linters with grep
2832018-09-13T19:13:58 <gmaxwell> I would describe the concern more broadly as there is a significant fraction of all PRs (maybe a majority) with basically no articulable direct or near term benefit to users... or even just exciting changes. In any project there is going to be some amount of house keeping for sure, and I'm super happy people want to work on bits of cleanup.
2842018-09-13T19:14:00 <wumpus> I've told him a few times that tcleanups are okay, but not too often, say once a month or so, but they just keep coming, it's oversnowing the useful PRs
2852018-09-13T19:14:01 <provoostenator> I like linters and other techniques to produce code consistentency, but obviously it shouldn't be become an obsession.
2862018-09-13T19:14:24 <wumpus> it's becoming an obsession for me (in the negative sense)
2872018-09-13T19:14:31 <gmaxwell> I feel really bad about finding myself in a position of saying "NAK. Your code is probably fine, but it's not worth anyones time to review it because it doesn't improve things enough."
2882018-09-13T19:14:37 <wumpus> if this keeps up, I'll close them blindly
2892018-09-13T19:14:42 <ryanofsky> i don't understand why you can't just tag them and look at the tag once a month
2902018-09-13T19:14:47 <provoostenator> Maybe someone should just combine them all in one giant lint PR and come back in a few months?
2912018-09-13T19:15:08 <wumpus> who doesn't he do that himself though?
2922018-09-13T19:15:17 <gmaxwell> ryanofsky: because 'when you look' doesn't change the fact that there is a review/correctness burden.
2932018-09-13T19:15:35 <wumpus> because some of us actually have to look at the list of allPRs and this is really discouraging
2942018-09-13T19:15:50 <jnewbery> I don't think any more needs to be said about any individual contributor, but if we can all rate limit own own refactor PRs, I think we'd appreciate it
2952018-09-13T19:16:30 <wumpus> yes, please
2962018-09-13T19:16:53 <MarcoFalke> ryanofsky: They show up in the list of pulls by default
2972018-09-13T19:16:58 <promag> however those monthly cleanups can be bigger and harder to merge
2982018-09-13T19:17:49 <gmaxwell> Also it's a lot easier to churn out 'safe' refactor/cleanup changes and it's also easier to review/comment on them, so it changes the balance of activity in the project in general.
2992018-09-13T19:17:58 <MarcoFalke> Can we add a pull request GitHub template that asks for clear motivation of the changes?
3002018-09-13T19:18:05 <wumpus> the problem is that our proojct is one big bottleneck, I think if it was divided into hierarchical subsystems like Linux it'd be better, but it's not really possible to have that workflow with github
3012018-09-13T19:18:28 <wumpus> all proposed changes end up in one big list
3022018-09-13T19:18:43 <MarcoFalke> I.e. The changes need to improve user experience or significantly improve developer experience
3032018-09-13T19:18:59 <gmaxwell> wumpus: dunno there, I mean, even if its subsystems, all of them need to be free of exploitable crashes. :) (okay maybe a few subsystems would really be isolated from any possible hostile input...)
3042018-09-13T19:19:10 <wumpus> e.g. https://blog.ffwll.ch/2017/08/github-why-cant-host-the-kernel.html
3052018-09-13T19:19:11 <jnewbery> wumpus: is that true? If wallet and node were better separated, would it be possible to have a master branch and a wallet dev branch for example?
3062018-09-13T19:19:18 <jonasschnelli> should we submodule the test system?
3072018-09-13T19:19:21 <gmaxwell> MarcoFalke: I also was thinking about articulate the benefit.
3082018-09-13T19:19:28 <meshcollider> wumpus: that's the point of GitHub "projects" isn't it
3092018-09-13T19:19:47 <gmaxwell> er, directing people to articulate the benefit.
3102018-09-13T19:19:52 <MarcoFalke> yeah ^
3112018-09-13T19:19:59 <wumpus> ideally I don't want to have to look at every PR individually anymore, in the case of Linux there's subsystem maintainers that make their own tree of updates and it can be merged (or rejected) at one
3122018-09-13T19:20:30 <gmaxwell> I do think we do want general code tidying some too... but those shouldn't be a signficant fraction of the PR flow.
3132018-09-13T19:20:35 <wumpus> jnewbery: this is not a technical issue about separation in the source tree, Linux is also one big tree
3142018-09-13T19:20:54 <jnewbery> wumpus: I'll read the danvet post
3152018-09-13T19:20:56 <wumpus> it's just that top-level PRs don't really scale
3162018-09-13T19:21:28 <wumpus> I can't manually, humanly, handle 200+ PRs, sorry
3172018-09-13T19:21:55 <jnewbery> proposed topic: wallet maintainer
3182018-09-13T19:22:03 <MarcoFalke> I have seen that practicalswift also runs a bot(?) to comment on pull request directly with feedback harvested from clang-tidy
3192018-09-13T19:22:04 <wumpus> and if it keeps going like this, at some point it's going to break down
3202018-09-13T19:22:18 <MarcoFalke> I think these are more useful than linters
3212018-09-13T19:22:40 <sipa> i plan to do more wallet work soon, to push descriptors and other things forward
3222018-09-13T19:22:43 <wumpus> so we need a different way of woring
3232018-09-13T19:22:59 <sipa> now i have to run, sorry; will be back next week
3242018-09-13T19:23:08 <wumpus> later sipa
3252018-09-13T19:23:08 <promag> o/
3262018-09-13T19:23:37 <promag> MarcoFalke: agree ^
3272018-09-13T19:24:21 <wumpus> #topic wallet maintainer
3282018-09-13T19:25:04 <wumpus> MarcoFalke> I.e. The changes need to improve user experience or significantly improve developer experience <- yes
3292018-09-13T19:25:25 <MarcoFalke> ok, will write up something today
3302018-09-13T19:25:34 <MarcoFalke> sipa is gone, so let's assign him to be wallet maintainer?
3312018-09-13T19:25:46 <gmaxwell> ACK.
3322018-09-13T19:25:50 <achow101> +1
3332018-09-13T19:25:51 <sdaftuar> i thought we already did that
3342018-09-13T19:25:53 <jnewbery> I think wumpus has wanted a wallet maintainer for a while, and sipa is probably too busy to take that role. I wonder if there are any actions we can take to find someone to be wallet maintainer in, say, the next six months
3352018-09-13T19:25:53 <meshcollider> I feel like he has already been assigned that role many times
3362018-09-13T19:26:03 <wumpus> best if it fixes a reported issue, or something that is clearly either a problem from a user perspective, a performance or security issue, etc
3372018-09-13T19:26:04 <promag> vote jnewbery for wallet maintainer :P
3382018-09-13T19:26:11 <jnewbery> promag: -1
3392018-09-13T19:26:25 <provoostenator> What is the wallet maintainer job description?
3402018-09-13T19:26:25 <wumpus> it's like a game of hot potato
3412018-09-13T19:26:29 <MarcoFalke> jnewbery: I am not aware of any single person that really knows what is going on in the wallet
3422018-09-13T19:26:47 <pierre_rochard> ryanofsky?
3432018-09-13T19:26:50 <jnewbery> MarcoFalke: that makes everyone equally qualified
3442018-09-13T19:26:51 <wumpus> provoostenator: review and merge wallet changes
3452018-09-13T19:26:55 <gmaxwell> sipa is closest, mostly as a side effect of knowing everything.
3462018-09-13T19:27:00 <wumpus> provoostenator: (most importantly, understand them)
3472018-09-13T19:27:22 <jonasschnelli> I think sipa is kinda the wallet maintainer... or am I wrong?
3482018-09-13T19:27:24 <jnewbery> but seriuosly, I think it's more important to have a sensitivity to what they don't know rather than have an encyclopedic knowledge of everything
3492018-09-13T19:27:35 <provoostenator> Well, some degree of not understanding can be compensated by not merging without ACK's from people who do.
3502018-09-13T19:27:45 <wumpus> yes, exactly jnewbery
3512018-09-13T19:27:51 <jnewbery> and it's only 15k lines of code. How difficult can it be?
3522018-09-13T19:27:54 <wumpus> it's a matter of judgement I guess
3532018-09-13T19:28:00 <gmaxwell> jnewbery: tada, disqualified. :P
3542018-09-13T19:28:23 <achow101> jnewbery: I think it's a bit cleaner now with accounts gone
3552018-09-13T19:28:32 <achow101> less idiotic to understand
3562018-09-13T19:28:45 <wumpus> it's not even that bad if you dn't fully understand it now, if you're willing to learn it
3572018-09-13T19:29:01 <MarcoFalke> So I believe the closest to a wallet maintainer would be the people that worked most on it in the last two releases
3582018-09-13T19:29:01 <jnewbery> my point in raising this topic is not "let's find a wallet maintainer today", but "can we take steps now to identify someone who might be a good wallet maintainer in a few months"
3592018-09-13T19:29:04 <wumpus> yes, getting rid of accounts did make it less crazy
3602018-09-13T19:29:18 <jnewbery> It seems that waiting around for someone to volunteer or step up hasn't really worked
3612018-09-13T19:29:28 <gmaxwell> having to support old stuff is just a pain. It's hard to do without having had a lot of exposure to the history as there are many poorly documented properties that the existing stuff obeys.
3622018-09-13T19:29:33 <wumpus> I wonder how Linus picks subsystem maintainers
3632018-09-13T19:29:52 <wumpus> though, I guess, people actually volunteer
3642018-09-13T19:29:55 <gmaxwell> jnewbery: I dunno, I think things are working in the sense that its becoming simpler and more people are contributing to that part actively than were in the past.
3652018-09-13T19:30:13 <jnewbery> gmaxwell: we're still too bottlenecked on wumpus
3662018-09-13T19:30:16 <meshcollider> Make a large wallet PR and the first person GitHub picks as a "suggested reviewer" is the new maintainer
3672018-09-13T19:30:18 <wumpus> jnewbery: yes
3682018-09-13T19:30:29 <jnewbery> so we need to make a wumpus bot or delegate to maintainers
3692018-09-13T19:30:31 <gmaxwell> Github just doesn't really directly facilitate that kind of workflow.
3702018-09-13T19:30:39 <wumpus> ideally I could just leave for a bit and things would continue
3712018-09-13T19:30:50 <promag> honestly I think jnewbery has done a great job cleaning and maintaining and improving wallet code
3722018-09-13T19:31:00 <achow101> the solution is to just upload wumpus's mind and then start 20 instances of him :p
3732018-09-13T19:31:05 <gmaxwell> like why are we actually bottlenecked on wumpus? perhaps wumpus needs to start tagging things with "I'm not going to merge this PR"
3742018-09-13T19:31:15 <wumpus> achow101: yes!
3752018-09-13T19:31:16 <provoostenator> I'd be fine with jnewbery doing this as well.
3762018-09-13T19:31:37 <meshcollider> jnewbery: in all honesty, would you not want the role
3772018-09-13T19:31:41 <wumpus> me too
3782018-09-13T19:31:42 <jamesob> instagibbs seems to know wallet pretty well
3792018-09-13T19:31:44 <gmaxwell> it's not like there is an actual technical physical bottleneck on wumpus.
3802018-09-13T19:31:59 <jnewbery> I'm flattered, honestly, but already too busy with bitcoin optech, residency stuff, etc
3812018-09-13T19:32:31 <jnewbery> perhaps something for discussion in tokyo
3822018-09-13T19:32:40 <MarcoFalke> I think the bottleneck is not clicking the merge button (any of the 4 maintainers can do this)
3832018-09-13T19:32:52 <MarcoFalke> The bottleneck is review and signing off on the merge
3842018-09-13T19:32:59 <MarcoFalke> (when ready)
3852018-09-13T19:33:12 <wumpus> yes, which is not always an easy judgement, but still
3862018-09-13T19:33:19 <provoostenator> So it's more like a "sudo ACK"?
3872018-09-13T19:33:37 <gmaxwell> well if we're concerned about review cycles then we need to talk about focusing resources on whats important. So perhaps more than 'foo maintainer' we need someone curating the priority list for a subsystem.
3882018-09-13T19:33:41 <wumpus> if you know a certain part of the code well enough you could be maintainer of it
3892018-09-13T19:33:53 <wumpus> like, in Linux, if you wrote a certain driver, you're pretty much maintainer of it by default
3902018-09-13T19:34:10 <gmaxwell> the high priority PRs things helps, at least as we close for a release...
3912018-09-13T19:34:24 *** masonicboom has quit IRC
3922018-09-13T19:34:26 <MarcoFalke> We could assign jnewbery and ryanofsky and other contributors the right to sign off on wallet changes and then some maintainer merges the changes.
3932018-09-13T19:34:33 <MarcoFalke> So have more than one wallet maintainer
3942018-09-13T19:34:37 <wumpus> well the maintainer of a subsystem would also curate prioriteit
3952018-09-13T19:34:47 <wumpus> the problems seems to be finding people, *NOT* finding things for them to do :)
3962018-09-13T19:34:49 <achow101> MarcoFalke: isn't that the point of ACK's though?
3972018-09-13T19:34:54 <meshcollider> MarcoFalke: isn't that basically just an ACK then
3982018-09-13T19:35:03 <promag> right achow101
3992018-09-13T19:35:20 <MarcoFalke> Not every ACK means merge
4002018-09-13T19:35:39 <gmaxwell> wumpus: well curating priority projects for a subsystem is less risky task, probably more people willing to do it, and fewer concerns about whos doing it.
4012018-09-13T19:35:40 <MarcoFalke> more like the "sudo ACK" (provoostenator)
4022018-09-13T19:35:42 <wumpus> well it's more subtle than that, otherwise it could jsut be a bot
4032018-09-13T19:36:08 <MarcoFalke> In the future I want it to be done by a bot, but thats a differnt topic
4042018-09-13T19:36:10 <wumpus> you also have to have a feeling who is the right person to ACK something
4052018-09-13T19:36:21 <wumpus> which would be possible if someone was a maintainer of that subsystem
4062018-09-13T19:36:30 <provoostenator> Does Github allow putting a "maintainer" badge on someone so it's more obvious for people that these maintainer ACK's are required / strongly recommended.
4072018-09-13T19:36:32 <wumpus> but we're circling around
4082018-09-13T19:36:42 <gmaxwell> like who would actually understand if this is broken or will cause problems down the road, vs who just looked at it and went yep no undefined behavior!
4092018-09-13T19:36:44 <meshcollider> provoostenator: mo
4102018-09-13T19:36:46 <meshcollider> No*
4112018-09-13T19:36:54 <wumpus> gmaxwell: righ
4122018-09-13T19:37:21 <wumpus> anyhow, if someone wants to be wallet maintainer, or maintainer of some other subsystem, let me know
4132018-09-13T19:37:30 <clarkmoody> provoostenator: maintainers.md
4142018-09-13T19:37:51 <wumpus> clarkmoody: yep
4152018-09-13T19:37:56 <provoostenator> Ok, that works.
4162018-09-13T19:38:07 <wumpus> you can define a path there, and who is maintainer, I think github even parses it somehow
4172018-09-13T19:38:22 <promag> and what should a maintainer do? :P
4182018-09-13T19:38:25 <meshcollider> So in terms of steps, be more active I'm looking for someone to push into the role? What else is possible
4192018-09-13T19:38:30 *** miknotauro has quit IRC
4202018-09-13T19:38:31 <meshcollider> In*
4212018-09-13T19:38:56 <provoostenator> https://blog.github.com/2017-07-06-introducing-code-owners/
4222018-09-13T19:38:58 <gmaxwell> I think we should all act as though we were the maintainers of things more.
4232018-09-13T19:39:04 <jnewbery> meshcollider: yes, I think so
4242018-09-13T19:39:20 <wumpus> promag: just be very active in maintaining a piece of code, like, review all PRs that change it, judge when a change is good, etc
4252018-09-13T19:39:41 <gmaxwell> not only does this potentially reduce work for others, but it helps identify people who are organically doing the job anyways. Which is, for the most part, what other projects do.
4262018-09-13T19:39:56 <gmaxwell> I think the issue wumpus struggles with is in part because no one is doing the job already.
4272018-09-13T19:40:02 <gmaxwell> :)
4282018-09-13T19:40:30 <gmaxwell> If someone were, it would be both less of an issue, and an easier thing to decide.
4292018-09-13T19:41:10 <wumpus> I mean I could pull a Guido van Rossum and just stop merging things and let you figure it out for yourself, but I'd prefer to have a saner path forward
4302018-09-13T19:41:45 <provoostenator> So we can just mark a bunch of people as Code Owners (as well maintainers.md) for the wallet and require review from at least one of them, as a step in the right direction?
4312018-09-13T19:41:49 <wumpus> but it's not given that I will be doing this forever
4322018-09-13T19:41:49 <promag> anyhow, if someone wants to be wallet maintainer, or maintainer of some other subsystem, let me know <-- wumpus: they should just step up?
4332018-09-13T19:42:07 <promag> like, ken2812221 looks like windows maintainer?
4342018-09-13T19:42:13 <meshcollider> provoostenator: that's effectively how RTM is judged anyway
4352018-09-13T19:42:15 <wumpus> promag: good idea!
4362018-09-13T19:43:24 <wumpus> he's doing a great job with the windows unicode support
4372018-09-13T19:43:55 <gmaxwell> The important thing is actually doing the work, meaning taking a concerted effort to review and understand changes, their short and long term implications-- their impact on the users, network, rest of the code base, their historical context... along with sheparding things along to make sure the required stuff gets done (if not actually doing it themselves)
4382018-09-13T19:43:57 <wumpus> I'mâsomewhat disappointedâthat windows still needs so much platform-specific code, but it's better than breaking on non-english people's PCs
4392018-09-13T19:44:14 <gmaxwell> These are things that almost everyone can do more of.
4402018-09-13T19:44:43 <wumpus> gmaxwell: agree
4412018-09-13T19:45:23 <wumpus> if someone was doing the work then assigning someone a maintainer label was easy
4422018-09-13T19:45:33 <wumpus> that's how jonasschnelli became GUI maintainer, for ex.
4432018-09-13T19:45:35 <gmaxwell> So I think thats really an action item people can take from this discussion, look for oppturnityies do to more of that yourself, and to help others do the same.
4442018-09-13T19:46:26 <wumpus> yes
4452018-09-13T19:47:11 <gmaxwell> opportunities*
4462018-09-13T19:47:55 <gmaxwell> Were there any other topics? kind of a bummer of a meeting. :)
4472018-09-13T19:48:09 <meshcollider> John had a third
4482018-09-13T19:48:29 <jnewbery> I had one more quick one on archiving meeting notes (sorry - didn't mean to take up all the time. Thought they'd all be quick)
4492018-09-13T19:48:32 <wumpus> #topic archiving meeting notes
4502018-09-13T19:48:50 <jnewbery> Botbotme is shutting down. not sure if anyone uses it
4512018-09-13T19:48:51 <jnewbery> https://lincolnloop.com/blog/saying-goodbye-botbotme/
4522018-09-13T19:48:52 <wumpus> jnewbery: well it needed to be said, Ithink
4532018-09-13T19:49:05 *** Mrrt has quit IRC
4542018-09-13T19:49:07 <jnewbery> I know that the bitcoincore.org meeting notes summaries linked there at least
4552018-09-13T19:49:29 <jnewbery> meeting notes also link to http://www.erisian.com.au/meetbot/bitcoin-core-dev/ , which I think is maintained by aj
4562018-09-13T19:49:54 <jnewbery> it'd be a shame if that went away at some point. I wonder if it makes sense to keep a mirror of the meeting notes somewher in the project
4572018-09-13T19:50:07 <achow101> we could have our own logger that publishes to bitcoincore.org?
4582018-09-13T19:50:10 <meshcollider> Meeting notes or full channel log?
4592018-09-13T19:50:20 <wumpus> we have aj's logger right?
4602018-09-13T19:50:24 <gmaxwell> Both would be nice, but seperately.
4612018-09-13T19:50:32 <jnewbery> meeting notes are most important I think, but yeah both
4622018-09-13T19:50:50 <wumpus> the meetingbot logs to www.erisian.com.au
4632018-09-13T19:51:11 <wumpus> as for summaries those should be part of the bitcoincore.org site itself not linked externally
4642018-09-13T19:51:27 <jnewbery> yes, summaries are at bitcoincore.org
4652018-09-13T19:51:48 <meshcollider> provoostenator: am I right in thinking you ran a logger at some point?
4662018-09-13T19:51:50 <wumpus> could also copy the logs there, I gues
4672018-09-13T19:52:02 <wumpus> would be good to have everything self-contained
4682018-09-13T19:52:09 <provoostenator> meshcollider: I did, but no longer do
4692018-09-13T19:52:14 <meshcollider> Ok
4702018-09-13T19:52:27 <achow101> could we migrate aj's meetbot to bitcoincore.org?
4712018-09-13T19:52:47 <provoostenator> BotBot server was fairly easy to deploy, so sounds like a good tool for this.
4722018-09-13T19:53:04 <wumpus> achow101: dunno, but could auto-copy the logs after a meeting
4732018-09-13T19:53:22 <wumpus> it'll print something like
4742018-09-13T19:53:22 <wumpus> 21:52 < lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-06-19.00.html
4752018-09-13T19:53:25 <wumpus> 21:52 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-06-19.00.txt
4762018-09-13T19:53:28 <wumpus> 21:52 < lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-06-19.00.log.html
4772018-09-13T19:53:33 <wumpus> so just a matter of copying those to bitcoincore.org and voila
4782018-09-13T19:54:15 <meshcollider> Ideally could run both botbot and the meetbot on the bitcoincore.org server directly ?
4792018-09-13T19:54:18 <provoostenator> Perhaps irc.bitcoincore.org could run such an instance? It's a much nicer format imo.
4802018-09-13T19:54:21 <wumpus> it needs to be checked into git so I don't think it can happen fully automatically
4812018-09-13T19:54:37 <provoostenator> Different subdomain means you can skip the Github flow (initially).
4822018-09-13T19:54:38 <achow101> wumpus: it could run in a sub domain
4832018-09-13T19:54:56 <MarcoFalke> provoostenator: I would want to host random irc logs on the bitcoincore domain
4842018-09-13T19:55:19 <MarcoFalke> Can be a completely separate trash.bitcoin-core-dev-logs.domain
4852018-09-13T19:55:21 <wumpus> these are only logs of the meeting
4862018-09-13T19:55:35 <provoostenator> You can pick which channel(s) to log. Or are you worried even about what could end up in this channel?
4872018-09-13T19:55:36 <jamesob> re: cutting down on refactoring PRs: one option might be to add a policy that forces refactoring-only PRs to document how each changed git hunk is covered by tests. If no test exists, obviously the proposing contributor would have to write one.
4882018-09-13T19:55:48 <wumpus> oh you want to log the entire channel?
4892018-09-13T19:56:00 <MarcoFalke> Yeah, I think it makes sense
4902018-09-13T19:56:04 <meshcollider> BotBot currently does and I think that's worth keeping up
4912018-09-13T19:56:19 <achow101> I think it currently makes more sense to log the entire channel with botbot going down
4922018-09-13T19:56:42 <provoostenator> I've linked to botbot logs in Github tickets more than once. Whatever tool we use, being able to deep-link to a specific message is very nice.
4932018-09-13T19:56:50 <wumpus> jamesob: I think that's good policy for any change, yes
4942018-09-13T19:56:53 <meshcollider> Agree
4952018-09-13T19:57:12 <MarcoFalke> Can botbot be hosted on GitHub (or at least the assets?)
4962018-09-13T19:58:02 <jamesob> wumpus: my only reservation is that that's a pretty high burden for large changes from established contributors... but maybe that makes it even more worthwhile :)
4972018-09-13T19:58:04 <wumpus> it can't run from github
4982018-09-13T19:58:46 <wumpus> jamesob: the biggest issue here is the volume, not so much the changes themselves, many don't even change the compiled code or are obviously correct like removing an argument
4992018-09-13T19:59:00 <MarcoFalke> Can it store the logs in a git repo?
5002018-09-13T19:59:03 <wumpus> jamesob: whichi s okay, but not of 5 of such PRs are opened every day
5012018-09-13T19:59:30 <meshcollider> MarcoFalke: I'm sure you could turn the log directory into a git repo either way
5022018-09-13T19:59:46 <wumpus> MarcoFalke: sure, though if commits need to be signed :)
5032018-09-13T19:59:54 <provoostenator> OTS?
5042018-09-13T20:00:15 <jamesob> wumpus: very much agreed. I was just thinking that such a policy (plainly advertised in a PR template, say) would filter out half-baked or lazy refactors (or at least allow a justified quick close)
5052018-09-13T20:00:16 <wumpus> when commigint to bitcoincore.org, really a human needs to be invovled
5062018-09-13T20:00:18 <meshcollider> Don't need to sign the commits if they're just pushed to a separate meeting-log repo
5072018-09-13T20:00:26 <MarcoFalke> If it is a binary blob (db) it might not work with git (or GitHub at least)
5082018-09-13T20:00:36 <wumpus> oh, no it's just text files
5092018-09-13T20:00:51 <MarcoFalke> kewl
5102018-09-13T20:00:58 <wumpus> #endmeeting
5112018-09-13T20:00:58 <lightningbot> Meeting ended Thu Sep 13 20:00:58 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
5122018-09-13T20:00:58 <lightningbot> Minutes: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-13-19.00.html
5132018-09-13T20:00:58 <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-13-19.00.txt
5142018-09-13T20:00:58 <lightningbot> Log: http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-09-13-19.00.log.html
5152018-09-13T20:01:00 <promag> jamesob: we already ask to split such pulls to ease review
5162018-09-13T20:01:39 *** phwalkr has joined #bitcoin-core-dev
5172018-09-13T20:01:57 <MarcoFalke> So (1) contact lincolnloop to fetcht the text logs of BotBot (2) put them on GitHub (3) Run a bot somewhere that keeps them up to date and hosts them on some domain?
5182018-09-13T20:01:59 <promag> jamesob: and how can we enforce that policy?
5192018-09-13T20:02:22 <MarcoFalke> DrahtBot can close prs that are refactoring that is not covered by tests ;)
5202018-09-13T20:02:32 <MarcoFalke> Though, that would close almost all refactoring prs
5212018-09-13T20:02:34 <jamesob> if the author didn't provide a coverage list and the PR is marked refactoring, it's an immediate close
5222018-09-13T20:03:03 <achow101> MarcoFalke: Is it necessary to get the logs from lincolnloop? We have the logs on at least two other sites as text files
5232018-09-13T20:03:03 <promag> how can DrathBot know if it's covered or not?
5242018-09-13T20:03:35 <MarcoFalke> achow101: If they are complete, then I guess not
5252018-09-13T20:03:47 <MarcoFalke> promag: make cov
5262018-09-13T20:04:14 <achow101> MarcoFalke: they look complete. they're in the topic
5272018-09-13T20:05:03 <meshcollider> So make a new repo in bitcoin-core called irc-logs or something and upload them ?
5282018-09-13T20:05:34 <promag> regarding scantxoutset release notes, should create separate file or append to release-notes.md?
5292018-09-13T20:05:45 <achow101> promag: use the wiki?
5302018-09-13T20:05:56 <achow101> or did that get merged in?
5312018-09-13T20:06:00 *** phwalkr has quit IRC
5322018-09-13T20:06:03 <MarcoFalke> achow101: They don't have html anchors, so hard to link to them for reference
5332018-09-13T20:06:11 <MarcoFalke> So I'd prefer them in a botbot-html-format
5342018-09-13T20:06:27 <MarcoFalke> The wiki is not yet merged in
5352018-09-13T20:06:33 <meshcollider> Yeah ideally all the logs are easily viewable from a botbot-like site
5362018-09-13T20:06:54 <promag> achow101: this https://github.com/bitcoin-core/bitcoin-devwiki/wiki/0.17.0-Release-notes ?
5372018-09-13T20:07:03 <achow101> yes
5382018-09-13T20:07:26 <promag> thanks
5392018-09-13T20:07:30 *** clarkmoody has quit IRC
5402018-09-13T20:07:41 <provoostenator> It might be easier to just get the logs in SQL format and then load them into a fresh server?
5412018-09-13T20:08:08 * aj waves
5422018-09-13T20:08:17 <wumpus> o/ aj
5432018-09-13T20:08:52 <aj> fwiw, i've been keeping non meeting channel logs at http://www.erisian.com.au/bitcoin-core-dev/
5442018-09-13T20:10:00 <provoostenator> aj: if you add anchor links to each timestamp, it makes it easier to link directly to one line of text
5452018-09-13T20:10:02 <aj> moving the meetbot stuff to bitcoincore.org domain sounds like a good idea, add it to the tokyo todo?
5462018-09-13T20:11:16 <provoostenator> Then it's just a question what's easier to maintain, aj's solution or a BotBot server.
5472018-09-13T20:11:23 <wumpus> that'd be awesome
5482018-09-13T20:11:35 <jnewbery> aj: fantastic! Didn't know about http://www.erisian.com.au/bitcoin-core-dev/
5492018-09-13T20:11:54 <achow101> jnewbery: it's in the topic of this channel
5502018-09-13T20:12:01 <aj> jnewbery: it is pretty horrible, but better than nothing :-/
5512018-09-13T20:12:07 <achow101> along with http://gnusha.org/bitcoin-core-dev/
5522018-09-13T20:13:22 <jnewbery> achow101: oh yeah. Thanks
5532018-09-13T20:14:08 *** owowo has quit IRC
5542018-09-13T20:17:49 <aj> provoostenator: http://www.erisian.com.au/bitcoin-core-dev/log-2018-09-13.html#l-544 might work fwiw
5552018-09-13T20:18:44 *** owowo has joined #bitcoin-core-dev
5562018-09-13T20:18:47 <wumpus> yep that works
5572018-09-13T20:19:43 <wumpus> does take viewing the source to find it, though :)
5582018-09-13T20:23:27 <aj> oh, i can fix that
5592018-09-13T20:26:36 *** Krellan has joined #bitcoin-core-dev
5602018-09-13T20:31:32 <aj> oh, no i can't, at least not the documented way :(
5612018-09-13T20:36:43 <aj> oh well, it includes line numbers visibly now so it should be easy-ish, but not point and click
5622018-09-13T21:08:48 *** Chris_Stewart_5 has quit IRC
5632018-09-13T21:11:09 *** Victorsueca has quit IRC
5642018-09-13T21:12:18 *** Victorsueca has joined #bitcoin-core-dev
5652018-09-13T21:18:36 *** Zenton has joined #bitcoin-core-dev
5662018-09-13T21:19:46 <gmaxwell> damn, never thought I'd see the day... windows 10 has a networking feature that I wish linux had.
5672018-09-13T21:20:15 <gmaxwell> Apparently you can set a socket option to make a TCP connection use LEDBAT congestion control, on a per socket basis.
5682018-09-13T21:23:11 <gmaxwell> but fortunately, MS has ways of making me not feel too bad.. apparently only "approved software" can use the socket option.
5692018-09-13T21:25:43 *** morcos has quit IRC
5702018-09-13T21:26:56 <gmaxwell> Thats too bad, it would make for a meaningful improvement in bitcoin node usability for many users if we could use that.
5712018-09-13T21:29:03 *** morcos has joined #bitcoin-core-dev
5722018-09-13T21:51:33 <TD-Linux> if it's really useful you could do a userspace implementation a la uTP
5732018-09-13T21:59:02 <gmaxwell> TD-Linux: utility vs sheer mass of OMG RCE VULNERABLE CODE...
5742018-09-13T21:59:39 <gmaxwell> the utility of it is that peers pulling many old blocks from us utterly slams the network connections of people with bufferbloated links.
5752018-09-13T21:59:51 <gmaxwell> And short of LEDBAT there isn't really a good fix for it.
5762018-09-13T22:00:13 <gmaxwell> But I don't know that the problem is severe enough that we'd want to ship a userspace network stack...
5772018-09-13T22:00:26 <TD-Linux> fair. also those people can prune
5782018-09-13T22:02:09 <gmaxwell> TD-Linux: they don't need to prune, they can just turn off service old blocks (set the upload limiter to zero)
5792018-09-13T22:02:15 <gmaxwell> serving*
5802018-09-13T22:02:22 *** phwalkr has joined #bitcoin-core-dev
5812018-09-13T22:02:43 <gmaxwell> But indeed, unfortunately having to have them configure stuff is kinda lame... since only a small portion of people who should do it actually will.
5822018-09-13T22:03:28 <gmaxwell> the rest will just have a bad time, and turn it off.
5832018-09-13T22:06:17 *** masonicboom has joined #bitcoin-core-dev
5842018-09-13T22:07:30 *** phwalkr has quit IRC
5852018-09-13T22:08:13 *** RubenSomsen has quit IRC
5862018-09-13T22:19:57 *** promag has quit IRC
5872018-09-13T22:21:25 *** spinza has quit IRC
5882018-09-13T22:22:54 *** hebasto has quit IRC
5892018-09-13T22:36:31 *** michaelsdunn1 has quit IRC
5902018-09-13T22:38:54 *** spinza has joined #bitcoin-core-dev
5912018-09-13T22:59:53 *** jarthur has quit IRC
5922018-09-13T23:19:10 <achow101> wumpus: is #12493 ready to be merged? it has several acks
5932018-09-13T23:19:13 <gribble> https://github.com/bitcoin/bitcoin/issues/12493 | [wallet] Reopen CDBEnv after encryption instead of shutting down by achow101 · Pull Request #12493 · bitcoin/bitcoin · GitHub
5942018-09-13T23:22:34 *** masonicboom has quit IRC
5952018-09-13T23:23:51 *** masonicboom has joined #bitcoin-core-dev
5962018-09-13T23:37:20 *** intcat has quit IRC
5972018-09-13T23:39:02 *** intcat has joined #bitcoin-core-dev
5982018-09-13T23:45:27 *** tryphe_ has quit IRC
5992018-09-13T23:46:01 *** tryphe_ has joined #bitcoin-core-dev
6002018-09-13T23:47:38 *** tryphe_ has joined #bitcoin-core-dev
6012018-09-13T23:48:27 *** tryphe_ has quit IRC
6022018-09-13T23:48:52 *** tryphe_ has joined #bitcoin-core-dev
6032018-09-13T23:49:57 *** tryphe_ has quit IRC
6042018-09-13T23:50:29 *** tryphe_ has joined #bitcoin-core-dev