12019-10-31T00:00:02  *** Guest18567 has quit IRC
  22019-10-31T00:07:40  *** Chris_Stewart_5 has joined #bitcoin-core-dev
  32019-10-31T00:12:08  *** Highway61 has quit IRC
  42019-10-31T00:17:33  *** krazyj has joined #bitcoin-core-dev
  52019-10-31T00:19:05  *** mariorz has quit IRC
  62019-10-31T00:24:40  *** mariorz has joined #bitcoin-core-dev
  72019-10-31T00:30:03  * luke-jr wonders if it would help to get force-pushes announced here. otoh, might get spammy
  82019-10-31T00:37:02  *** Chris_Stewart_5 has quit IRC
  92019-10-31T00:45:42  *** arik_ has joined #bitcoin-core-dev
 102019-10-31T00:55:05  *** arik_ has quit IRC
 112019-10-31T00:56:39  *** arik_ has joined #bitcoin-core-dev
 122019-10-31T01:02:45  *** davterra has quit IRC
 132019-10-31T01:11:39  *** ddustin has quit IRC
 142019-10-31T01:12:16  *** captjakk has joined #bitcoin-core-dev
 152019-10-31T01:12:26  *** ddustin has joined #bitcoin-core-dev
 162019-10-31T01:15:47  *** EagleTM has joined #bitcoin-core-dev
 172019-10-31T01:16:19  *** oneark has joined #bitcoin-core-dev
 182019-10-31T01:16:37  *** ddustin has quit IRC
 192019-10-31T01:23:16  *** arik_ has quit IRC
 202019-10-31T01:49:00  *** lightlike has quit IRC
 212019-10-31T02:03:48  *** lowentropy has quit IRC
 222019-10-31T02:05:29  *** lowentropy has joined #bitcoin-core-dev
 232019-10-31T02:09:41  *** ajonas has quit IRC
 242019-10-31T02:16:21  *** jarthur has joined #bitcoin-core-dev
 252019-10-31T02:23:29  *** m1rror8955363887 has quit IRC
 262019-10-31T02:24:01  *** m1rror8955363887 has joined #bitcoin-core-dev
 272019-10-31T02:25:56  *** captjakk has quit IRC
 282019-10-31T02:31:39  *** EagleTM has quit IRC
 292019-10-31T02:46:03  *** TheHoliestRoger has quit IRC
 302019-10-31T02:48:16  *** TheHoliestRoger has joined #bitcoin-core-dev
 312019-10-31T02:54:49  *** sipa has quit IRC
 322019-10-31T03:00:01  *** krazyj has quit IRC
 332019-10-31T03:03:05  *** sipa has joined #bitcoin-core-dev
 342019-10-31T03:09:14  *** emilengler has quit IRC
 352019-10-31T03:09:34  *** emilengler has joined #bitcoin-core-dev
 362019-10-31T03:17:26  *** HaeB1 has joined #bitcoin-core-dev
 372019-10-31T03:19:08  *** felixfoertsch has joined #bitcoin-core-dev
 382019-10-31T03:20:02  *** felixfoertsch23 has quit IRC
 392019-10-31T03:30:57  *** jarthur has quit IRC
 402019-10-31T03:32:56  *** jarthur has joined #bitcoin-core-dev
 412019-10-31T04:13:10  *** spinza has joined #bitcoin-core-dev
 422019-10-31T04:16:54  <BlueMatt> uhhhh...hopefully there re exactly 0?
 432019-10-31T04:28:10  <jeremyrubin> I force push all the time :| How else do you rebase?
 442019-10-31T04:28:22  <BlueMatt> I figured he meant to the repo itself
 452019-10-31T05:07:07  *** jarthur has quit IRC
 462019-10-31T05:09:42  *** provoostenator has quit IRC
 472019-10-31T05:17:35  *** provoostenator has joined #bitcoin-core-dev
 482019-10-31T05:20:19  <sipa> jeremyrubin: what BlueMatt said
 492019-10-31T05:27:40  *** nosss2 has joined #bitcoin-core-dev
 502019-10-31T05:31:47  *** Victor_sueca has joined #bitcoin-core-dev
 512019-10-31T05:34:48  *** Victorsueca has quit IRC
 522019-10-31T05:44:47  *** rex4539 has quit IRC
 532019-10-31T06:00:01  *** HaeB1 has quit IRC
 542019-10-31T06:17:34  *** zxiiro_ has joined #bitcoin-core-dev
 552019-10-31T06:33:10  *** arik_ has joined #bitcoin-core-dev
 562019-10-31T07:00:38  *** arik_ has quit IRC
 572019-10-31T07:05:57  *** arik_ has joined #bitcoin-core-dev
 582019-10-31T07:36:53  *** timothy has joined #bitcoin-core-dev
 592019-10-31T07:41:06  *** arik_ has quit IRC
 602019-10-31T07:53:40  *** soju has quit IRC
 612019-10-31T08:14:56  *** marcoagner has joined #bitcoin-core-dev
 622019-10-31T08:24:32  <jeremyrubin> i think i was thrown off by luke saying spammy -- I thought we should see 0!
 632019-10-31T08:27:58  <wumpus> moneyball: so they have the requirement based on the age of the software apparently
 642019-10-31T08:29:21  <wumpus> luke-jr: afaik, force-pushes are announced here, at least the old bot did
 652019-10-31T08:29:28  <wumpus> there just aren't any, usually
 662019-10-31T08:45:51  *** jonatack has quit IRC
 672019-10-31T08:48:34  *** Guyver2 has joined #bitcoin-core-dev
 682019-10-31T08:51:51  <provoostenator> I'm able to install from the signed DMG just fine (overriding a previous installation)
 692019-10-31T08:55:23  *** provoostenator has quit IRC
 702019-10-31T09:00:02  *** zxiiro_ has quit IRC
 712019-10-31T09:06:59  *** aqquadro has joined #bitcoin-core-dev
 722019-10-31T09:07:19  *** provoostenator has joined #bitcoin-core-dev
 732019-10-31T09:12:23  <provoostenator> I suppose it's alright if Apple provides additional free malware review :-) (as long as they keep the right-click to install alternative)
 742019-10-31T09:15:52  *** ExtraCrispy has joined #bitcoin-core-dev
 752019-10-31T09:17:27  *** Mikaku1 has joined #bitcoin-core-dev
 762019-10-31T09:28:57  *** jonatack has joined #bitcoin-core-dev
 772019-10-31T09:37:28  *** diogosergio has joined #bitcoin-core-dev
 782019-10-31T09:55:56  *** JeremyCrookshank has joined #bitcoin-core-dev
 792019-10-31T09:56:51  <JeremyCrookshank> Any recommenced reading for Bitcoin Development?
 802019-10-31T10:08:49  *** aqquadro has quit IRC
 812019-10-31T10:13:20  *** kabaum has joined #bitcoin-core-dev
 822019-10-31T10:16:47  *** timothy has quit IRC
 832019-10-31T10:19:56  *** aqquadro has joined #bitcoin-core-dev
 842019-10-31T10:20:43  *** timothy has joined #bitcoin-core-dev
 852019-10-31T10:28:57  *** hebasto has quit IRC
 862019-10-31T10:30:25  *** Highway61 has joined #bitcoin-core-dev
 872019-10-31T10:35:25  *** hebasto has joined #bitcoin-core-dev
 882019-10-31T10:44:17  *** thaumavorio has quit IRC
 892019-10-31T10:46:18  *** thaumavorio has joined #bitcoin-core-dev
 902019-10-31T10:52:58  <luke-jr> wumpus: force-pushes to PRs?
 912019-10-31T10:53:08  <luke-jr> ie, rebases
 922019-10-31T10:55:38  *** setpill has joined #bitcoin-core-dev
 932019-10-31T10:57:50  *** bitcoin-git has joined #bitcoin-core-dev
 942019-10-31T10:57:51  <bitcoin-git> [bitcoin] jonatack opened pull request #17327: test: add rpc_fundrawtransaction logging (master...rpc_fundrawtransaction-test-logging) https://github.com/bitcoin/bitcoin/pull/17327
 952019-10-31T10:58:03  *** bitcoin-git has left #bitcoin-core-dev
 962019-10-31T11:04:03  *** mabox has joined #bitcoin-core-dev
 972019-10-31T11:04:48  *** mabox has quit IRC
 982019-10-31T11:07:17  *** Chris_Stewart_5 has joined #bitcoin-core-dev
 992019-10-31T11:08:17  <jonatack> JeremyCrookshank: many resources here https://github.com/jonatack/bitcoin-development/blob/master/how-to-review-bitcoin-core-prs.md
1002019-10-31T11:09:20  <provoostenator> Looks like #16697  is back. I'm seeing it again on master too....
1012019-10-31T11:09:21  <gribble> https://github.com/bitcoin/bitcoin/issues/16697 | Unknown version bit fork activated warning · Issue #16697 · bitcoin/bitcoin · GitHub
1022019-10-31T11:12:11  <wumpus> luke-jr: the bot only monitors the branches on the main repository, not every user's branches
1032019-10-31T11:12:20  <wumpus> and it shouldn't imo
1042019-10-31T11:12:51  *** ExtraCrispy has quit IRC
1052019-10-31T11:14:39  <wumpus> provoostenator: I thought we deleted that code
1062019-10-31T11:14:53  <wumpus> apparently not
1072019-10-31T11:20:02  <provoostenator> Fun fact: downloading from internet is different than copying via SSH from a Gitian machine... for macOS
1082019-10-31T11:24:47  <luke-jr> wumpus: it announces PR opens/closes
1092019-10-31T11:26:14  <wumpus> JeremyCrookshank: https://bitcoin.org/en/developer-reference
1102019-10-31T11:26:54  <luke-jr> provoostenator: what?
1112019-10-31T11:27:03  <wumpus> luke-jr: right, I suppose it *could* track all user's branches too, but I think that would be a bad idea, I'm not interested in rebases on 294 open PRs
1122019-10-31T11:27:42  <luke-jr> wumpus: it seems more interesting than DrahtBot's close/reopen Travis rebuilds ;)
1132019-10-31T11:27:57  <luke-jr> wumpus: not all user branches are PRs tho
1142019-10-31T11:28:32  <luke-jr> anyway, I just meant in terms of timely review of rebased PRs before they need rebase yet again a day later <.<
1152019-10-31T11:28:34  <wumpus> it would be possible to filter out drahtbot actions
1162019-10-31T11:38:21  <wumpus> provoostenator: windows does a similar thing, some kind of taint tracking with files, anything downloaded by the browser is suspect
1172019-10-31T11:44:11  *** Chris_Stewart_5 has quit IRC
1182019-10-31T11:49:22  <luke-jr> wget does it too, just doesn't warn you
1192019-10-31T11:50:23  <luke-jr> getfattr -d on your downloads
1202019-10-31T11:50:31  *** Chris_Stewart_5 has joined #bitcoin-core-dev
1212019-10-31T11:53:26  *** aqquadro has quit IRC
1222019-10-31T11:55:54  *** jonatack has quit IRC
1232019-10-31T11:57:53  *** jonatack has joined #bitcoin-core-dev
1242019-10-31T12:00:02  *** Mikaku1 has quit IRC
1252019-10-31T12:09:20  *** JeremyCrookshank has quit IRC
1262019-10-31T12:17:31  *** AngryAdmin has joined #bitcoin-core-dev
1272019-10-31T12:24:11  *** pinheadmz_ has joined #bitcoin-core-dev
1282019-10-31T12:24:26  *** bitcoin-git has joined #bitcoin-core-dev
1292019-10-31T12:24:26  <bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/08e29473126d...feb1a8c03aff
1302019-10-31T12:24:27  <bitcoin-git> bitcoin/master 3b3b931 Carl Dong: nsis: Write to correct filename in first place
1312019-10-31T12:24:27  <bitcoin-git> bitcoin/master feb1a8c Wladimir J. van der Laan: Merge #17308: nsis: Write to correct filename in first place
1322019-10-31T12:24:29  *** bitcoin-git has left #bitcoin-core-dev
1332019-10-31T12:24:46  *** bitcoin-git has joined #bitcoin-core-dev
1342019-10-31T12:24:46  <bitcoin-git> [bitcoin] laanwj merged pull request #17308: nsis: Write to correct filename in first place (master...2019-10-simplify-nsis-exe-rename) https://github.com/bitcoin/bitcoin/pull/17308
1352019-10-31T12:24:48  *** bitcoin-git has left #bitcoin-core-dev
1362019-10-31T12:26:37  *** pinheadmz has quit IRC
1372019-10-31T12:26:37  *** pinheadmz_ is now known as pinheadmz
1382019-10-31T12:29:12  *** m1rror8955363887 has quit IRC
1392019-10-31T12:29:54  *** m1rror8955363887 has joined #bitcoin-core-dev
1402019-10-31T12:32:25  *** JeremyCrookshank has joined #bitcoin-core-dev
1412019-10-31T12:32:36  <JeremyCrookshank> jonatack & wumpus thank you
1422019-10-31T12:33:02  <JeremyCrookshank> already done two basic GUI PRs just wanting to expand knowlege
1432019-10-31T12:46:00  <JeremyCrookshank> will be reviewing #16432 soon
1442019-10-31T12:46:02  <gribble> https://github.com/bitcoin/bitcoin/issues/16432 | qt: Add privacy to the Overview page by hebasto · Pull Request #16432 · bitcoin/bitcoin · GitHub
1452019-10-31T12:50:04  *** Victor_sueca is now known as Victorsueca
1462019-10-31T12:53:23  <instagibbs> luke-jr, I force push a ton to my PRs, it would be a bit much
1472019-10-31T12:55:52  <luke-jr> hmm
1482019-10-31T12:56:11  <luke-jr> maybe we should just try manually announcing when a rebase is ready
1492019-10-31T12:59:47  <instagibbs> rebase is ready?
1502019-10-31T12:59:56  <instagibbs> meaning, "it's ok to re-review now"?
1512019-10-31T13:06:12  <luke-jr> right
1522019-10-31T13:15:43  <instagibbs> I usually manually announce in the thread, yeah
1532019-10-31T13:37:26  *** JeremyCrookshank has quit IRC
1542019-10-31T13:41:24  *** JeremyCrookshank has joined #bitcoin-core-dev
1552019-10-31T13:42:07  <provoostenator> I force push so much it bogs down Travis :-)
1562019-10-31T13:44:37  *** ajonas has joined #bitcoin-core-dev
1572019-10-31T13:46:08  *** jonatack has quit IRC
1582019-10-31T13:46:45  *** lightlike has joined #bitcoin-core-dev
1592019-10-31T13:59:12  *** xoyi- has joined #bitcoin-core-dev
1602019-10-31T14:11:06  *** rex4539 has joined #bitcoin-core-dev
1612019-10-31T14:12:15  *** rex4539 has quit IRC
1622019-10-31T14:12:37  *** rex4539 has joined #bitcoin-core-dev
1632019-10-31T14:16:40  *** bitcoin-git has joined #bitcoin-core-dev
1642019-10-31T14:16:41  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/feb1a8c03aff...1c5e0ccabae1
1652019-10-31T14:16:41  <bitcoin-git> bitcoin/master 9cae3d5 practicalswift: tests: Add fuzzer initialization (hold ECCVerifyHandle)
1662019-10-31T14:16:41  <bitcoin-git> bitcoin/master 1c5e0cc MarcoFalke: Merge #17274: tests: Fix fuzzers eval_script and script_flags by re-adding...
1672019-10-31T14:16:53  *** bitcoin-git has left #bitcoin-core-dev
1682019-10-31T14:17:10  *** bitcoin-git has joined #bitcoin-core-dev
1692019-10-31T14:17:11  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17274: tests: Fix fuzzers eval_script and script_flags by re-adding ECCVerifyHandle dependency (master...fuzzer-initialization-follow-up) https://github.com/bitcoin/bitcoin/pull/17274
1702019-10-31T14:17:23  *** bitcoin-git has left #bitcoin-core-dev
1712019-10-31T14:24:52  *** sipa has quit IRC
1722019-10-31T14:26:19  *** michaelfolkson has joined #bitcoin-core-dev
1732019-10-31T14:35:44  *** mdunnio has joined #bitcoin-core-dev
1742019-10-31T14:46:23  *** tsujp has quit IRC
1752019-10-31T14:48:09  *** tsujp has joined #bitcoin-core-dev
1762019-10-31T14:49:19  *** ExtraCrispy has joined #bitcoin-core-dev
1772019-10-31T14:52:51  *** bitcoin-git has joined #bitcoin-core-dev
1782019-10-31T14:52:52  <bitcoin-git> [bitcoin] darosior opened pull request #17328: GuessVerificationProgress: cap the ratio to 1 (master...fixup_getblockchaininfo) https://github.com/bitcoin/bitcoin/pull/17328
1792019-10-31T14:52:52  *** bitcoin-git has left #bitcoin-core-dev
1802019-10-31T15:00:01  *** AngryAdmin has quit IRC
1812019-10-31T15:00:53  *** arik_ has joined #bitcoin-core-dev
1822019-10-31T15:08:02  *** xoyi- has quit IRC
1832019-10-31T15:10:12  *** rex4539 has quit IRC
1842019-10-31T15:12:15  *** mdunnio has quit IRC
1852019-10-31T15:12:34  *** mdunnio has joined #bitcoin-core-dev
1862019-10-31T15:17:14  *** gdude2002 has joined #bitcoin-core-dev
1872019-10-31T15:18:07  *** rex4539 has joined #bitcoin-core-dev
1882019-10-31T15:39:30  *** mdunnio has quit IRC
1892019-10-31T15:42:41  *** mdunnio has joined #bitcoin-core-dev
1902019-10-31T15:42:51  *** captjakk has joined #bitcoin-core-dev
1912019-10-31T15:44:45  *** tsujp has quit IRC
1922019-10-31T15:46:06  *** captjakk_ has joined #bitcoin-core-dev
1932019-10-31T15:46:31  *** captjakk has quit IRC
1942019-10-31T15:47:52  *** michaelfolkson has quit IRC
1952019-10-31T15:49:24  *** ViresNumeris21 has joined #bitcoin-core-dev
1962019-10-31T15:49:30  *** tsujp has joined #bitcoin-core-dev
1972019-10-31T15:58:41  *** bitcoin-git has joined #bitcoin-core-dev
1982019-10-31T15:58:42  <bitcoin-git> [bitcoin] jnewbery opened pull request #17329: linter: Strip trailing / in path for git-subtree-check (master...2019-10-subtree-path) https://github.com/bitcoin/bitcoin/pull/17329
1992019-10-31T15:58:43  *** bitcoin-git has left #bitcoin-core-dev
2002019-10-31T16:00:25  *** jarthur has joined #bitcoin-core-dev
2012019-10-31T16:02:19  *** Deinogalerix21 has joined #bitcoin-core-dev
2022019-10-31T16:03:14  *** captjakk_ has quit IRC
2032019-10-31T16:05:51  *** captjakk has joined #bitcoin-core-dev
2042019-10-31T16:11:59  *** sipa has joined #bitcoin-core-dev
2052019-10-31T16:14:40  *** AaronvanW has quit IRC
2062019-10-31T16:17:20  *** timothy has quit IRC
2072019-10-31T16:39:26  *** pinheadmz has quit IRC
2082019-10-31T16:44:23  *** mdunnio has quit IRC
2092019-10-31T16:48:42  *** AaronvanW has joined #bitcoin-core-dev
2102019-10-31T16:49:55  *** Aaronvan_ has joined #bitcoin-core-dev
2112019-10-31T16:53:14  *** AaronvanW has quit IRC
2122019-10-31T16:53:16  <JeremyCrookshank> "Take pains to explain exactly what you’re doing and the reasoning behind"
2132019-10-31T16:53:19  *** Deinogalerix21 has quit IRC
2142019-10-31T16:53:25  <JeremyCrookshank> Pain? ;)
2152019-10-31T16:53:32  *** jonatack has joined #bitcoin-core-dev
2162019-10-31T16:57:18  *** jb55 has quit IRC
2172019-10-31T16:59:32  *** captjakk has quit IRC
2182019-10-31T16:59:55  *** Chris_Stewart_5 has quit IRC
2192019-10-31T17:00:01  *** captjakk has joined #bitcoin-core-dev
2202019-10-31T17:04:02  *** captjakk has quit IRC
2212019-10-31T17:04:43  *** setpill has quit IRC
2222019-10-31T17:07:44  *** captjakk has joined #bitcoin-core-dev
2232019-10-31T17:10:25  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2242019-10-31T17:12:21  *** mdunnio has joined #bitcoin-core-dev
2252019-10-31T17:13:43  *** diogosergio has quit IRC
2262019-10-31T17:22:07  *** jonatack has quit IRC
2272019-10-31T17:22:49  *** jonatack has joined #bitcoin-core-dev
2282019-10-31T17:26:50  *** jonatack has quit IRC
2292019-10-31T17:27:54  *** jonatack has joined #bitcoin-core-dev
2302019-10-31T17:32:57  *** JeremyCrookshank has quit IRC
2312019-10-31T17:33:54  *** Deacyde has joined #bitcoin-core-dev
2322019-10-31T17:33:56  *** Deacydal has joined #bitcoin-core-dev
2332019-10-31T17:36:48  *** Deacyde has quit IRC
2342019-10-31T17:41:08  *** mdunnio_ has joined #bitcoin-core-dev
2352019-10-31T17:41:57  *** jonatack has quit IRC
2362019-10-31T17:42:05  *** lightlike has quit IRC
2372019-10-31T17:44:26  *** mdunnio has quit IRC
2382019-10-31T17:45:08  *** Chris_Stewart_5 has quit IRC
2392019-10-31T17:46:14  *** jonatack has joined #bitcoin-core-dev
2402019-10-31T17:46:34  *** Deacydal is now known as Deacyde
2412019-10-31T17:47:47  *** Chris_Stewart_5 has joined #bitcoin-core-dev
2422019-10-31T17:51:23  *** bsm1175321 has joined #bitcoin-core-dev
2432019-10-31T17:56:17  *** bitcoin-git has joined #bitcoin-core-dev
2442019-10-31T17:56:17  <bitcoin-git> [bitcoin] sdaftuar opened pull request #17330: [qa] Add shrinkdebugfile=0 to regtest bitcoin.conf (master...2019-10-shrinkdebugfile0) https://github.com/bitcoin/bitcoin/pull/17330
2452019-10-31T17:56:17  *** mdunnio_ has quit IRC
2462019-10-31T17:56:18  *** bitcoin-git has left #bitcoin-core-dev
2472019-10-31T17:58:49  *** ddustin has joined #bitcoin-core-dev
2482019-10-31T17:59:09  *** pinheadmz has joined #bitcoin-core-dev
2492019-10-31T17:59:38  *** ddustin has joined #bitcoin-core-dev
2502019-10-31T18:00:01  *** gdude2002 has quit IRC
2512019-10-31T18:00:18  *** ddustin has quit IRC
2522019-10-31T18:00:54  *** ddustin has joined #bitcoin-core-dev
2532019-10-31T18:02:02  *** ddustin has joined #bitcoin-core-dev
2542019-10-31T18:08:32  *** Aaronvan_ is now known as AaronvanW
2552019-10-31T18:11:51  *** mdunnio has joined #bitcoin-core-dev
2562019-10-31T18:15:08  *** mdunnio has quit IRC
2572019-10-31T18:15:21  *** mdunnio has joined #bitcoin-core-dev
2582019-10-31T18:36:59  *** lightlike has joined #bitcoin-core-dev
2592019-10-31T18:40:25  *** xoyi- has joined #bitcoin-core-dev
2602019-10-31T18:44:00  *** bitcoin-git has joined #bitcoin-core-dev
2612019-10-31T18:44:02  <bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/1c5e0ccabae1...100fa0a62a29
2622019-10-31T18:44:03  <bitcoin-git> bitcoin/master 52cf68f Russell Yanofsky: Refactor: Add GetLegacyScriptPubKeyMan helper
2632019-10-31T18:44:03  <bitcoin-git> bitcoin/master 628d11b Russell Yanofsky: Add back mistakenly removed AssertLockHeld
2642019-10-31T18:44:04  <bitcoin-git> bitcoin/master 2632b1f Russell Yanofsky: doc: Clarify WalletStorage / Wallet relation
2652019-10-31T18:44:06  *** bitcoin-git has left #bitcoin-core-dev
2662019-10-31T18:44:20  *** bitcoin-git has joined #bitcoin-core-dev
2672019-10-31T18:44:21  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17300: LegacyScriptPubKeyMan code cleanups (master...pr/keyman-cleanup) https://github.com/bitcoin/bitcoin/pull/17300
2682019-10-31T18:44:33  *** bitcoin-git has left #bitcoin-core-dev
2692019-10-31T18:46:51  *** Deacyde has quit IRC
2702019-10-31T18:48:03  *** MasterdonX has quit IRC
2712019-10-31T18:48:23  *** GsC_RuL3Z has joined #bitcoin-core-dev
2722019-10-31T18:49:25  *** ViresNumeris21 has quit IRC
2732019-10-31T18:50:40  *** MasterdonX has joined #bitcoin-core-dev
2742019-10-31T18:52:11  *** bitcoin-git has joined #bitcoin-core-dev
2752019-10-31T18:52:12  <bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/100fa0a62a29...811c381ab650
2762019-10-31T18:52:13  <bitcoin-git> bitcoin/master 60582d6 John Newbery: [linter] Strip trailing / in path for git-subtree-check
2772019-10-31T18:52:13  <bitcoin-git> bitcoin/master 811c381 fanquake: Merge #17329: linter: Strip trailing / in path for git-subtree-check
2782019-10-31T18:52:15  *** bitcoin-git has left #bitcoin-core-dev
2792019-10-31T18:52:31  *** bitcoin-git has joined #bitcoin-core-dev
2802019-10-31T18:52:31  <bitcoin-git> [bitcoin] fanquake merged pull request #17329: linter: Strip trailing / in path for git-subtree-check (master...2019-10-subtree-path) https://github.com/bitcoin/bitcoin/pull/17329
2812019-10-31T18:52:32  *** bitcoin-git has left #bitcoin-core-dev
2822019-10-31T18:55:57  *** oneark has quit IRC
2832019-10-31T18:57:55  *** reallll has joined #bitcoin-core-dev
2842019-10-31T18:58:37  *** jonatack has quit IRC
2852019-10-31T18:59:20  *** bitcoin-git has joined #bitcoin-core-dev
2862019-10-31T18:59:21  <bitcoin-git> [bitcoin] achow101 opened pull request #17331: Use effective values throughout coin selection (master...effective-value) https://github.com/bitcoin/bitcoin/pull/17331
2872019-10-31T18:59:21  *** bitcoin-git has left #bitcoin-core-dev
2882019-10-31T18:59:48  <jeremyrubin> meeting?
2892019-10-31T19:00:00  <warren> here
2902019-10-31T19:00:05  <achow101> meeting?
2912019-10-31T19:00:21  <wumpus> #startmeeting
2922019-10-31T19:00:21  <lightningbot> Meeting started Thu Oct 31 19:00:21 2019 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
2932019-10-31T19:00:21  <lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
2942019-10-31T19:00:43  <jnewbery> hi
2952019-10-31T19:00:47  <warren> hi
2962019-10-31T19:00:51  <kanzure> hi
2972019-10-31T19:00:53  <achow101> hi
2982019-10-31T19:00:56  <amiti> hi
2992019-10-31T19:00:59  <moneyball> hi
3002019-10-31T19:01:00  *** bitcoin-git has joined #bitcoin-core-dev
3012019-10-31T19:01:01  <bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/811c381ab650...222b7d0ca795
3022019-10-31T19:01:02  <bitcoin-git> bitcoin/master c5377ff Suhas Daftuar: [qa] Add shrinkdebugfile=0 to regtest bitcoin.conf
3032019-10-31T19:01:02  <bitcoin-git> bitcoin/master 222b7d0 MarcoFalke: Merge #17330: test: Add shrinkdebugfile=0 to regtest bitcoin.conf
3042019-10-31T19:01:04  *** bitcoin-git has left #bitcoin-core-dev
3052019-10-31T19:01:13  <jeremyrubin> im unsure about DST
3062019-10-31T19:01:14  *** belcher has quit IRC
3072019-10-31T19:01:17  <jeremyrubin> Oh
3082019-10-31T19:01:20  <sipa> hi
3092019-10-31T19:01:20  *** bitcoin-git has joined #bitcoin-core-dev
3102019-10-31T19:01:21  <bitcoin-git> [bitcoin] MarcoFalke merged pull request #17330: test: Add shrinkdebugfile=0 to regtest bitcoin.conf (master...2019-10-shrinkdebugfile0) https://github.com/bitcoin/bitcoin/pull/17330
3112019-10-31T19:01:22  *** bitcoin-git has left #bitcoin-core-dev
3122019-10-31T19:01:46  <provoostenator> hi
3132019-10-31T19:02:18  <wumpus> yes, DST in europe changed
3142019-10-31T19:02:32  <wumpus> it's an hour earlier here
3152019-10-31T19:03:03  *** reallll is now known as belcher
3162019-10-31T19:03:05  <meshcollider> wumpus: don't forget to ping everyone :p
3172019-10-31T19:03:07  <meshcollider> hi
3182019-10-31T19:03:17  <fanquake> hi
3192019-10-31T19:03:37  <wumpus> four proposed topics in https://gist.github.com/moneyball/071d608fdae217c2a6d7c35955881d8a : "moneyball: follow-up on travis and #16148" "umpus: close Boost → C++11 migration project for now" "proposed by dongcarl: MacOS, notarization https://github.com/bitcoin/bitcoin/issues/15774" "jeremyrubin: epoch mempool"
3202019-10-31T19:03:39  <gribble> https://github.com/bitcoin/bitcoin/issues/16148 | Travis timeouts · Issue #16148 · bitcoin/bitcoin · GitHub
3212019-10-31T19:03:56  *** bitcoin-git has joined #bitcoin-core-dev
3222019-10-31T19:03:56  <bitcoin-git> [bitcoin] sdaftuar opened pull request #17332: [p2p] Proof-of-concept: Improve DoS-resistance to low-work headers chains (master...2019-10-no-checkpoints-cleanedup) https://github.com/bitcoin/bitcoin/pull/17332
3232019-10-31T19:03:57  *** bitcoin-git has left #bitcoin-core-dev
3242019-10-31T19:04:01  <digi_james> Hi
3252019-10-31T19:04:16  <wumpus> #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 moneyball kvaciral ariard digi_james amiti fjahr
3262019-10-31T19:04:29  <wumpus> #topic High priority for review
3272019-10-31T19:04:47  <wumpus> currently 7 blockers, 7 chasing concept ACK
3282019-10-31T19:04:49  <wumpus> https://github.com/bitcoin/bitcoin/projects/8
3292019-10-31T19:05:23  <BlueMatt> plz2add #16974
3302019-10-31T19:05:24  <gribble> https://github.com/bitcoin/bitcoin/issues/16974 | Walk pindexBestHeader back to ChainActive().Tip() if it is invalid by TheBlueMatt · Pull Request #16974 · bitcoin/bitcoin · GitHub
3312019-10-31T19:05:27  *** xoyi- has quit IRC
3322019-10-31T19:06:28  <wumpus> BlueMatt: added (to blocker I guess?)
3332019-10-31T19:06:40  <BlueMatt> yea
3342019-10-31T19:07:08  <BlueMatt> it blocks post-headers-over-dns rust progress (since I want to lean heavily on "I have a better header than blocks, but my peers dont have blocks" as a criteria for searching for alternate block download methods)
3352019-10-31T19:07:27  <wumpus> yes, makes sense
3362019-10-31T19:07:59  <wumpus> nothing else too add/remove?
3372019-10-31T19:08:51  <wumpus> #topic close Boost → C++11 migration project for now (wumpus)
3382019-10-31T19:09:23  <warren> too much change required?
3392019-10-31T19:09:34  <wumpus> so it looks like all the low-hanging fruit for replacing boost has been picked now
3402019-10-31T19:10:07  <wumpus> what remains is hard to replace with C++11 (results in very verbose code, locale dependent legacy C, or introduces harder to maintain platform-specific code)
3412019-10-31T19:10:19  <jeremyrubin> It's basically just multiindex and boost::thread now right?
3422019-10-31T19:10:22  <wumpus> it's kind of a time wasting trap for developers now (regarding PRs like #17245)
3432019-10-31T19:10:24  <gribble> https://github.com/bitcoin/bitcoin/issues/17245 | wallet: Remove Boost from DecodeDumpTime by elichai · Pull Request #17245 · bitcoin/bitcoin · GitHub
3442019-10-31T19:10:52  <wumpus> nah, people stumble over the sleep and date/time handling stuff every time
3452019-10-31T19:11:21  <wumpus> #17307 might still be worthwhile
3462019-10-31T19:11:23  <gribble> https://github.com/bitcoin/bitcoin/issues/17307 | Stop using `boost::thread_group` · Issue #17307 · bitcoin/bitcoin · GitHub
3472019-10-31T19:11:31  <jeremyrubin> What about just checking in those specific copies of boost library code
3482019-10-31T19:11:48  <sipa> after 17307, won't removing boost::threa dbe a lot easier?
3492019-10-31T19:11:49  <jeremyrubin> Or are they too large/dependent on the rest of boost types
3502019-10-31T19:11:50  <wumpus> but it needs to be focused, we don't want to close the same PRs time after time that don't really make it
3512019-10-31T19:12:11  <wumpus> I think having that project open sends the wrong messag
3522019-10-31T19:12:15  <wumpus> we can't replace boost right now
3532019-10-31T19:12:36  <jeremyrubin> 17307, having worked on replacing thread_group in the checkqueue before, scares me a bit
3542019-10-31T19:12:37  <sipa> agree there
3552019-10-31T19:12:49  <wumpus> there's no need to replace, say, small string handling functions with our own impelentation, before we have a vision to replace the rest
3562019-10-31T19:13:33  <sipa> right; until we have a reasonable way to remove multiindex (which i'm not sure will ever happen), getting rid of boost entirely is not really useful
3572019-10-31T19:13:38  <dongcarl> Just so it's out there... we can maybe run bcp at some point when there's only one or two things left https://www.boost.org/doc/libs/1_71_0/tools/bcp/doc/html/index.html
3582019-10-31T19:13:49  <jeremyrubin> dongcarl: ++
3592019-10-31T19:13:55  <sipa> i do think there are individual improvements possible that dkn't go all the way, like removing boost::thread
3602019-10-31T19:14:13  <jnewbery> I agree that if it's not a priority then the project should be closed. It can always be re-opened later if necessary.
3612019-10-31T19:14:21  <wumpus> but in any case it doesn't seem like it needs a big coordinated project anymore
3622019-10-31T19:14:25  <sipa> how many non-headers-only boost libs are we still using?
3632019-10-31T19:14:39  <sipa> wumpus: agree
3642019-10-31T19:14:45  <jnewbery> (leaving a comment in the project description explaining why it's been closed)
3652019-10-31T19:14:58  <wumpus> when C++17 is allowed, it can be reopened
3662019-10-31T19:15:28  <fanquake> Guess #13751 can be closed with the same rationale as well then.
3672019-10-31T19:15:30  <gribble> https://github.com/bitcoin/bitcoin/issues/13751 | Utils and libraries: Drops the boost/algorithm/string/split.hpp dependency by l2a5b1 · Pull Request #13751 · bitcoin/bitcoin · GitHub
3682019-10-31T19:15:35  <wumpus> fanquake: yes
3692019-10-31T19:15:50  <wumpus> there's not really a reason to do that right now
3702019-10-31T19:16:33  <warren> gitian binaries static link the libstdc++ so distro support won't change when C++17 happens right?
3712019-10-31T19:16:35  *** jb55 has joined #bitcoin-core-dev
3722019-10-31T19:16:39  *** captjakk has quit IRC
3732019-10-31T19:16:43  <dongcarl> warren: Yes
3742019-10-31T19:16:47  <wumpus> warren: correct, assumning we can keep the same GLIBC req
3752019-10-31T19:16:50  <wumpus> (runtime)
3762019-10-31T19:17:24  <wumpus> which I don't see why not
3772019-10-31T19:17:58  <wumpus> statically linking using musl libc is another thing that might be considered in the future
3782019-10-31T19:18:03  <wumpus> but that's a whole different topic
3792019-10-31T19:18:15  <dongcarl> should be able to keep it as long as we 1. stick to Bionic 2. write new hooks, ick, or 3. use guix
3802019-10-31T19:18:27  *** captjakk has joined #bitcoin-core-dev
3812019-10-31T19:18:33  <cfields> Bionic?
3822019-10-31T19:18:53  <dongcarl> cfields: bionic has 1.27, which is what we've written hooks to support up to
3832019-10-31T19:18:57  *** captjakk has quit IRC
3842019-10-31T19:19:02  <dongcarl> glibc 1.27 that is
3852019-10-31T19:19:03  <sipa> i read "books" instead of hooks. was confused
3862019-10-31T19:19:11  *** captjakk has joined #bitcoin-core-dev
3872019-10-31T19:19:37  *** bitcoin-git has joined #bitcoin-core-dev
3882019-10-31T19:19:38  <bitcoin-git> [bitcoin] fanquake closed pull request #13751: Utils and libraries: Drops the boost/algorithm/string/split.hpp dependency (master...patch/remove_boost_split) https://github.com/bitcoin/bitcoin/pull/13751
3892019-10-31T19:19:39  <wumpus> hehe
3902019-10-31T19:19:39  *** bitcoin-git has left #bitcoin-core-dev
3912019-10-31T19:19:44  *** captjakk has quit IRC
3922019-10-31T19:19:44  <jnewbery> Shall I go ahead and update the project description and then close?
3932019-10-31T19:19:50  <wumpus> jnewbery: yes, thanks
3942019-10-31T19:20:02  *** captjakk has joined #bitcoin-core-dev
3952019-10-31T19:20:02  <jnewbery> ok done
3962019-10-31T19:20:05  <wumpus> seems no one strongly disagrees
3972019-10-31T19:20:20  <wumpus> #topic MacOS, notarization (dongcarl)
3982019-10-31T19:20:21  *** captjakk has quit IRC
3992019-10-31T19:20:31  <jnewbery> updated description is visible here: https://github.com/bitcoin/bitcoin/projects?query=is%3Aclosed
4002019-10-31T19:20:59  <dongcarl> Right, here
4012019-10-31T19:21:03  <wumpus>  #15774
4022019-10-31T19:21:04  <gribble> https://github.com/bitcoin/bitcoin/issues/15774 | macOS App Notarization · Issue #15774 · bitcoin/bitcoin · GitHub
4032019-10-31T19:21:08  <dongcarl> Info available here: https://developer.apple.com/documentation/xcode/notarizing_your_app_before_distribution/customizing_the_notarization_workflow
4042019-10-31T19:21:11  <wumpus> jnewbery: great!
4052019-10-31T19:21:18  <dongcarl> Mostly just to make people aware of what's going to happen
4062019-10-31T19:21:30  <dongcarl> We're going to have a step in the release process that can only happen on a mac
4072019-10-31T19:21:33  <cfields> dongcarl: I think we should consider rejecting Apple's new requirement.
4082019-10-31T19:21:38  <wumpus> discntinuing MacOS binaries?
4092019-10-31T19:21:56  <dongcarl> cfields: that's something I've thought about too
4102019-10-31T19:22:03  <provoostenator> It depends on what the step is
4112019-10-31T19:22:04  * dongcarl typing gimme a sec
4122019-10-31T19:22:14  <cfields> I've been putting something together, probably best not to thought-dump here.
4132019-10-31T19:22:18  <provoostenator> As long as it's easy to review the difference on a non-Mac I don't mind too much.
4142019-10-31T19:22:33  <wumpus> htey make it harder and harder to distribute binaries for open source software
4152019-10-31T19:22:41  <luke-jr> [19:16:33] <warren> gitian binaries static link the libstdc++ so distro support won't change when C++17 happens right? <-- gitian binaries don't matter in this regard
4162019-10-31T19:22:49  <luke-jr> distro support is for NATIVE compiles
4172019-10-31T19:23:01  <luke-jr> (also, gitian binaries *don't* work on all distros)
4182019-10-31T19:23:02  <dongcarl> After we submit the app for notarization it is actually not NEEDED to staple it to the binary
4192019-10-31T19:23:14  <dongcarl> Apparently GateKeeper will query the Apple servers
4202019-10-31T19:23:18  <wumpus> luke-jr: that was last topic, but yes
4212019-10-31T19:23:24  <dongcarl> Which is convenient, but gives them A LOT OF CONTROL
4222019-10-31T19:23:28  <provoostenator> I'm not a huge fan of Apple getting a call from all our useres
4232019-10-31T19:23:31  <luke-jr> oh, I missed the #topic line
4242019-10-31T19:23:48  <provoostenator> So better to staple if it's not too difficult
4252019-10-31T19:23:50  <cfields> the bigger issue is that it makes Apple the final arbiter of what people can run. In a potential emergency fork/uasf scenario, this puts them in charge. I think it would be unwise for us to participate in that.
4262019-10-31T19:24:05  <luke-jr> wumpus: is Apple dropping support for unsigned binaries entirely?
4272019-10-31T19:24:10  <cfields> (final arbiter once we start down the path, that is)
4282019-10-31T19:24:19  <wumpus> yes, they want the same control as they have on iOS
4292019-10-31T19:24:24  <provoostenator> What changes when we go down the path?
4302019-10-31T19:24:24  <luke-jr> ugh
4312019-10-31T19:24:37  <moneyball> luke-jr: no you can still install but you have to "right click open"
4322019-10-31T19:24:51  <luke-jr> moneyball: right now, yes; but after these new changes?
4332019-10-31T19:24:57  <cfields> I think it's a mistake to engage that, because we can't go back. And if they refuse to sign a soft-fork, presumably there'd be nothing we could do.
4342019-10-31T19:25:10  <provoostenator> I don't understand why we can't go back
4352019-10-31T19:25:12  <luke-jr> cfields: we could timebomb..
4362019-10-31T19:25:22  <provoostenator> Do they change the installation rules once you notarize once?
4372019-10-31T19:25:24  <luke-jr> Knots already expires 1-2 years after the release
4382019-10-31T19:25:24  <dongcarl> I'm less worried about them refusing to sign
4392019-10-31T19:25:38  <dongcarl> I'm more worried about them signing: we've audited this binary and it's malicious
4402019-10-31T19:25:38  <moneyball> luke-jr: I run MacOS Catalina, am able to install 0.18 fine, and 0.19 RC3 I can install but need to "right click Open"
4412019-10-31T19:25:40  <cfields> provoostenator: if we engage once, then it would be a regression not to continue.
4422019-10-31T19:25:47  <dongcarl> That's a bad message to users
4432019-10-31T19:26:00  <provoostenator> cfields: arguably we're just kicking that regression down the road
4442019-10-31T19:26:16  <moneyball> If we make no changes, I think at minimum we need to communicate on the download site that one must "right click Open" otherwise many users will be perplexed as I was
4452019-10-31T19:26:19  <wumpus> it's not a regression if we never start supporting it
4462019-10-31T19:26:22  <provoostenator> Because Catalina users will encounter the regression (right click to install) now
4472019-10-31T19:26:27  <provoostenator> Which we can delay
4482019-10-31T19:26:34  <luke-jr> As long as users can run binaries w/o the notary, that sounds preferable
4492019-10-31T19:26:40  <wumpus> I think it's a good point, for a project like us, to be principled about it
4502019-10-31T19:26:43  <cfields> provoostenator: yes,( unpopular opinion time...) which is why it's worth considering dropping MacOs
4512019-10-31T19:27:04  <luke-jr> cfields: why drop entirely?
4522019-10-31T19:27:05  <cfields> I'm not saying that we should. I'm saying it's worth a discussion.
4532019-10-31T19:27:15  <wumpus> only when they *require* this
4542019-10-31T19:27:18  <wumpus> not right now
4552019-10-31T19:27:26  <luke-jr> can't our DMG just tell them right click etc in the folde rview?
4562019-10-31T19:27:31  <warren> are there other reasons aside from this?
4572019-10-31T19:27:32  <wumpus> but it's a possiblility in the future
4582019-10-31T19:28:03  <jeremyrubin> is there no more self-signing?
4592019-10-31T19:28:03  <wumpus> if it really becomes a closed platform
4602019-10-31T19:28:11  <sipa> cfields: stop supporting for release binarier, or stop supporting the platform? (i know the distinction is kinda vague for us, but we can still make sure our code compiles and runs fine, even if we're not providing binaries)
4612019-10-31T19:28:22  <jeremyrubin> Can we have a binary which we get apple to sign which self-signs our binary?
4622019-10-31T19:28:24  <wumpus> sipa: you can still build your own
4632019-10-31T19:28:27  <wumpus> sipa: using homebrew
4642019-10-31T19:28:49  <achow101> What changed between 0.18.x and 0.19 that 0.19 now triggers the warning but 0.18.x doesn't?
4652019-10-31T19:28:54  <jeremyrubin> Then apple would only have to sign it once, and then that can self-sign future cores
4662019-10-31T19:28:58  <wumpus> achow101: nothing in our code
4672019-10-31T19:29:11  <cfields> sipa: yes, thanks for making the distinction. The first would be far less problematic.
4682019-10-31T19:29:22  *** jarthur_ has joined #bitcoin-core-dev
4692019-10-31T19:29:23  <dongcarl> Here's the risk that I see: someone takes our codesigned binaries, gives it to Apple, Apple maybe mistakingly decides that the binary is malicious, and now everyone's GateKeeper will ask Apple about that codesigned binary, which will give them a "THIS IS MALICIOUS" popup on double-click
4702019-10-31T19:29:25  <achow101> wumpus: moneyball said that 0.18.x installs fine, but 0.19 doesn't, on the same system
4712019-10-31T19:29:48  <wumpus> achow101: only because iti's more recent I think
4722019-10-31T19:29:50  <sipa> cfields: devil's advocate... is this very different from say snap controlling our snap releases? sure, snap is not the only way you run bitcoind on ubuntu, but depending on the user's expertise there may not be that much difference in how much control those entities have over what consensus code gets adopted
4732019-10-31T19:29:51  <cfields> dongcarl: yes, and that's inevitible. Because we ARE bitcoin core. You know, the thing they're scanning their binaries for :)
4742019-10-31T19:29:55  <fanquake> I'd assume he'd already been running 0.18
4752019-10-31T19:31:02  <moneyball> fanquake: me? as an experiment i installed 0.18 yesterday to compare to the experience installing 0.19
4762019-10-31T19:31:06  <achow101> I think it would be worthwhile to investigate why that happens and see if we are able to avoid the warning without doing any apple special stuff
4772019-10-31T19:31:08  <luke-jr> [19:27:31] <warren> are there other reasons aside from this? <-- macOS only works on backdoored hardware; macOS is proprietary; etc
4782019-10-31T19:31:31  <fanquake> moneyball yea. I don't think the reinstalling 0.18 would make a difference though.
4792019-10-31T19:31:42  <cfields> achow101: yes, agree.
4802019-10-31T19:31:42  <wumpus> even google isn't aiming for that kind of total control of android
4812019-10-31T19:31:48  <fanquake> Otherwise suddenly everyone who updated to 10.15's software would start breaking.
4822019-10-31T19:31:57  <wumpus> sipa: your comparison would hold for the apple app store, not for things installed outside it
4832019-10-31T19:32:01  <fanquake> I'd assume the new checks only apply to "new" binaries you are trying to run.
4842019-10-31T19:32:13  <cfields> Admittedly I don't have enough info on this. But what I've read has really rubbed me the wrong way. So I'll shut up now and chime in on the issue instead :)
4852019-10-31T19:32:16  <fanquake> So if you'd already been running 0.18 previously, I don't think reinstalling it is going to cause an issue.
4862019-10-31T19:32:27  *** jarthur_ has quit IRC
4872019-10-31T19:32:51  *** jarthur has quit IRC
4882019-10-31T19:32:54  <sipa> wumpus: fair point; but even on android you need to explicitly enable non-play store apk sources; that seems fairly similar to the right click "open anyway"
4892019-10-31T19:33:07  <fanquake> cfields: I assume your opinion is that we aren't shipping a macOS binary for 0.19 then? Assuming we're already at rc3?
4902019-10-31T19:33:09  <cfields> sipa: I'll have to think about that. I think it's different.
4912019-10-31T19:33:17  <provoostenator> I don't think it's very effective for a small (in terms of macOS user base) project to make a stance at this stage.
4922019-10-31T19:33:19  <wumpus> sipa: yes; I definiely don't think we should stop with MacOS binaries as long as that's possible
4932019-10-31T19:33:40  <dongcarl> Seems this is stirring up a lot of conversation, perhaps we can come back to this as the last topic?
4942019-10-31T19:33:42  <cfields> provoostenator: then I suppose we'd need to involve more projects :)
4952019-10-31T19:33:55  <ryanofsky> another danger of us not providing binaries is that someone else starts submitting and providing them, like happened with the snap store
4962019-10-31T19:34:01  <sipa> cfields: as far as ideology goes, supporting osx release binaries without participating in the gatekeeper stuff perhaps has more impact than dropping support entirely
4972019-10-31T19:34:02  <cfields> fanquake: Nah, for 0.19 I think we should just build/sign as before.
4982019-10-31T19:34:07  <jeremyrubin> ryanofsky: +1
4992019-10-31T19:34:09  <provoostenator> cfields: well, for starters it could be useful to get a bunch of projects together and try to get a physical meeting with Apple
5002019-10-31T19:34:14  <wumpus> provoostenator: I'm not really interested in having it being effective as a political strategy in general
5012019-10-31T19:34:20  <achow101> I can (probably) find a mac that doesn't have core installed and try
5022019-10-31T19:34:21  <provoostenator> They might be open to actually fixing this.
5032019-10-31T19:34:31  <wumpus> provoostenator: it would be a bad idea for bitcoin, so for bitcoin we should reject it
5042019-10-31T19:34:33  <fanquake> cfields: with just a warning / opening instructions on the website / in the dmg?
5052019-10-31T19:34:40  <sipa> provoostenator: i very much doubt that
5062019-10-31T19:34:50  <fanquake> ^
5072019-10-31T19:35:20  <sipa> provoostenator: i suspect that from their perspective, the fact that people can run unvetted binaries is a historical legacy that needs to be fixed :)
5082019-10-31T19:35:23  <provoostenator> Well if the answer is "we don't want to fix this, we like a gated community" then that's a nice quote to start a boycott.
5092019-10-31T19:35:54  <ryanofsky> dongcarl, if we do decide to "staple" the apple signature, is it still easily possible for a user to verify the executed code was built reproducibly & signed by us?
5102019-10-31T19:36:25  <provoostenator> ^ that's the most important question imo
5112019-10-31T19:36:27  <cfields> ryanofsky: that's already how it operates. We "staple" on the detached sig. It's easily auditable.
5122019-10-31T19:36:32  <jeremyrubin> Odd question: if we ship a binary + a VM, can we just run it in the VM always?
5132019-10-31T19:36:37  <wumpus> I'm not going to upload any binaries that aren't possible to verify in a distributed way
5142019-10-31T19:36:40  <cfields> I assume it'd be the same here. If not, surely we could write a tool to handle it.
5152019-10-31T19:37:10  <ryanofsky> ok, that's good at least
5162019-10-31T19:37:21  <achow101> is it possible to "staple" without a mac?
5172019-10-31T19:37:24  *** luke-jr has quit IRC
5182019-10-31T19:37:47  <dongcarl> not possible to "staple" without a mac right now
5192019-10-31T19:37:50  <fanquake> You'd need Xcode and associated tools
5202019-10-31T19:37:51  <cfields> It's not possible to do the detached sigs without a mac either.. the tooling is our own.
5212019-10-31T19:37:52  <sipa> is it possible to undo the stapling on non-mac?
5222019-10-31T19:38:04  <cfields> Er, let me rephrase...
5232019-10-31T19:38:36  <cfields> There's no supported way sign on non-mac as we do now, but that didn't stop us from hacking something together :)
5242019-10-31T19:39:02  <achow101> someone would have to reverse engineer how it's "stapled" and write a tool for it for other platforms
5252019-10-31T19:39:03  <cfields> So I assume we could do something similar again. Might turn into a 3-stage gitian build, though :(
5262019-10-31T19:39:09  <dongcarl> what cfields said
5272019-10-31T19:39:18  <fanquake> Liking something we can take away from this discussion: https://trac.torproject.org/projects/tor/ticket/30126
5282019-10-31T19:39:22  <fanquake> *likely
5292019-10-31T19:39:41  <sipa> cfields: what if instead of doing the stapling in the 2nd/3rd gitian stage, we write a tool that can compare a stapled binary against a deterministic one?
5302019-10-31T19:39:49  <sipa> that could even remove the need for the 2nd stage we have now
5312019-10-31T19:40:05  <wumpus> cfields: adding a slight delay is usually not a problem
5322019-10-31T19:40:12  <dongcarl> sipa: A notarization strip tool?
5332019-10-31T19:40:16  <sipa> dongcarl: yes
5342019-10-31T19:40:37  <cfields> sipa: I don't think it's possible to be deterministic because of the timestamping, but maybe I'm misunderstanding.
5352019-10-31T19:40:54  <sipa> let me start over
5362019-10-31T19:40:56  <dongcarl> cfields: He's talking about our existing deterministic codesigned binary
5372019-10-31T19:41:21  <sipa> do we actually care that the codesigning/timestamping/notarizing step is deterministic?
5382019-10-31T19:41:26  <wumpus> yes
5392019-10-31T19:41:37  <sipa> the point of determinism is showing that the shipped binaries match our source code
5402019-10-31T19:41:49  <wumpus> at least the attach-signature step
5412019-10-31T19:41:58  <warren> presumably the timestamp is part of the stapled part, while the executable part could be verified after stapling?
5422019-10-31T19:42:11  <wumpus> the signing itself doesn't need to be determinsitic, it's only done once by one person
5432019-10-31T19:42:21  <sipa> if you could *strip* the codesigning from a binary, and compare the result of that with the deterministic unsigned result, don't we achieve the same thing?
5442019-10-31T19:42:42  <sipa> in that case the notarizing/codesigning could be done entirely outside of gitian, removing the 2 phase process we have now
5452019-10-31T19:42:58  *** Highway62 has joined #bitcoin-core-dev
5462019-10-31T19:43:02  <sipa> that of course only works if the stripping tool is easily auditable
5472019-10-31T19:43:12  <cfields> sipa: I see. You'd have to trust the stripping tool and be able to audit the diff, but that could work.
5482019-10-31T19:43:20  *** Highway61 has quit IRC
5492019-10-31T19:43:21  *** Highway62 is now known as Highway61
5502019-10-31T19:43:28  <sipa> right, it depends on how complicated the stripping is
5512019-10-31T19:43:35  <wumpus> so instead of uploading my own gitian results, I'd have to upload the binary someone else sends me
5522019-10-31T19:43:43  <cfields> sipa: IIRC there's a reason we didn't do it that way. Can't seem to remember though, maybe not.
5532019-10-31T19:44:02  <dongcarl> how many people do the codesigning right now?
5542019-10-31T19:44:11  <sipa> wumpus: you'd upload the codesigned binary, but the gitian results contain the non-codesigned hash
5552019-10-31T19:44:23  <sipa> the comparison tool strips the codesigning, and compares with gitian
5562019-10-31T19:44:23  <achow101> dongcarl: 2. cfields for windows, jonasschnelli for mac
5572019-10-31T19:45:47  <dongcarl> right, if it's just one person for each platform then perhaps stripping is not too bad?
5582019-10-31T19:46:02  <cfields> sipa: ah, at the time, it might've just been about the tooling. Easier to add than remove. That likely isn't an issue anymore though, there's better tooling now.
5592019-10-31T19:46:33  <wumpus> at least now it's possible to look up the sha256 of the binaries from the SHA256SUMS.asc in gitian, and see they match, this would add an extra step
5602019-10-31T19:46:39  <wumpus> I don't like it but ok...
5612019-10-31T19:46:46  <sipa> wumpus: agreed, it's annoying; but needing to comply with ever-increasing notarization/codesigning requirements is also annoying
5622019-10-31T19:47:13  <sipa> it's just an idea; no need to decide anything now
5632019-10-31T19:47:37  <wumpus> this wouoldn't avoid that right?
5642019-10-31T19:47:55  <fanquake> Apparently we wont actually need the secure timestamp or hardened runtime until January next year
5652019-10-31T19:48:00  <fanquake> https://developer.apple.com/news/?id=09032019a
5662019-10-31T19:48:16  <provoostenator> You can still put the sha of the signed binary in the gitian result, along with the sha of the stripped version.
5672019-10-31T19:48:17  <cfields> Bitcoin 0.20 when? :p
5682019-10-31T19:48:19  <wumpus> why even bother with bitcoincore.org uploads anymore, if you go through all these hoops, can't you put it on the app store directly?
5692019-10-31T19:48:20  <achow101> that's in two months...
5702019-10-31T19:48:24  <dongcarl> wumpus: this would avoid us having to reverse engineer each notarization/codesigning step and writing a tool to do it under our reproducible builds process
5712019-10-31T19:48:35  <jeremyrubin> Here's a reductionist viewpoint: It's not worth jumping through too many hoops for apple users, because ultimately if the person shipping your kernel decides you don't want them running bitcoin, or a version of bitcoin, you're already, to put it lightly, fucked
5722019-10-31T19:48:44  <fanquake> achow101 at least it means a 0.19.0 release is simpler...
5732019-10-31T19:48:53  <fanquake> and gives us time to figure out future tooling
5742019-10-31T19:49:05  <jeremyrubin> So this is maybe a problem we can't really solve for OSX users, short of giving them a liberated computer
5752019-10-31T19:49:31  <sipa> back to short-term issue: are our processes already using the secure timestamp and/or hardened runtime?
5762019-10-31T19:49:36  <provoostenator> wumpus: app stores come with additional problems though, like auto-update
5772019-10-31T19:49:36  <sipa> or how hard is it to do so
5782019-10-31T19:49:47  <wumpus> let's go to the next issue, already spent too much time on apple junk
5792019-10-31T19:50:04  <wumpus> two topics left and 10 minutes
5802019-10-31T19:50:07  <sipa> ok
5812019-10-31T19:50:12  <wumpus> #topic follow-up on travis and #16148 (moneyball)
5822019-10-31T19:50:13  <gribble> https://github.com/bitcoin/bitcoin/issues/16148 | Travis timeouts · Issue #16148 · bitcoin/bitcoin · GitHub
5832019-10-31T19:50:41  *** luke-jr has joined #bitcoin-core-dev
5842019-10-31T19:51:32  <wumpus> moneyball?
5852019-10-31T19:51:38  <moneyball> hi
5862019-10-31T19:51:50  <moneyball> my name is on the topic but it is from 1 month ago
5872019-10-31T19:51:57  <instagibbs> moneyball, don't timeout in 10 minutes ;)
5882019-10-31T19:51:57  <moneyball> when we discussed the same topic and said punt 1 month
5892019-10-31T19:51:58  <wumpus> oh
5902019-10-31T19:52:03  <moneyball> since then the PR was closed
5912019-10-31T19:52:13  <moneyball> maybe MarcoFalke can discuss that?
5922019-10-31T19:52:29  <moneyball> also we were wondering the status of jonasschnelli's related project
5932019-10-31T19:52:58  <wumpus> ok, might be better to move to jeremyrubin's topic for now then
5942019-10-31T19:53:03  <moneyball> sure
5952019-10-31T19:53:09  <wumpus> #topic  epoch mempool (jeremyrubin)
5962019-10-31T19:53:12  <jeremyrubin> Hi!
5972019-10-31T19:53:31  <jeremyrubin> So Epoch Mempool is a relatively big upgrade to the way the mempool tracks relatives state
5982019-10-31T19:53:44  <jeremyrubin> We replace a ton of std::sets with epoch tracking for touching txiters
5992019-10-31T19:54:07  <sipa> yay
6002019-10-31T19:54:21  <jeremyrubin> This is done because we have restrictive limits on the number of descendants, which is a problem for protocols like lightning or OP_STB
6012019-10-31T19:54:43  <jeremyrubin> The PR is just a start, but it's a good checkpoint on improvement progress
6022019-10-31T19:54:59  <jeremyrubin> (I will have follow ups that are further improvements)
6032019-10-31T19:55:30  <sipa> it's clear to me that that approach in theory at least should be possible and improve performance; i haven't looked at the code
6042019-10-31T19:55:30  <jeremyrubin> But the critical question is: what standard of "evidence" do we want to see to be comfortable with such an improvement not introducing regressions in performance?
6052019-10-31T19:55:41  <instagibbs> it's also a problem for services due to simple transaction pinning
6062019-10-31T19:55:47  <wumpus> is mempool performance a bottleneck?
6072019-10-31T19:55:58  <sipa> wumpus: for increasing the mempool limits, it is
6082019-10-31T19:56:12  <sipa> (package size, ancestor depth, ...)
6092019-10-31T19:56:19  <wumpus> okay
6102019-10-31T19:56:58  <instagibbs> sipa, is there a good writeup of "all" the reasons for the limits? There are 1 or 2 on suhas' writeup on the wiki, but likely not exhaustive of collective wisdom
6112019-10-31T19:57:07  <sipa> instagibbs: not that i know
6122019-10-31T19:57:08  <ariard> is this a change only in the way we traverse mempool sets or also in the way we compute entry feerate?
6132019-10-31T19:57:18  <jeremyrubin> Traversal only as of now
6142019-10-31T19:57:27  <jeremyrubin> The notes aren't really fully up-to-date either
6152019-10-31T19:57:34  <sipa> instagibbs: and sdaftuar likely knows better than i do
6162019-10-31T19:57:49  <instagibbs> I think I've hit up sdaftuar for all he currently has written done(which is better than 0!)
6172019-10-31T19:58:08  <ariard> hmmmm did you spend time to think how we compute feerate? improving this point first could ease traversal
6182019-10-31T19:58:34  <jeremyrubin> Feerate isn't really the chief issue here IMO
6192019-10-31T19:58:36  <sipa> ariard: what do you mean by compute feerate?
6202019-10-31T19:58:48  <instagibbs> https://github.com/bitcoin-core/bitcoin-devwiki/wiki/Mempool-and-mining poached slides being referenced
6212019-10-31T19:58:50  <jeremyrubin> But it does cause a lot of traversal-ing
6222019-10-31T19:58:54  <ariard> tracking ancestor/descendant size/fees
6232019-10-31T19:59:11  <instagibbs> the modified feerate you mean
6242019-10-31T20:00:08  <jeremyrubin> In either case, the feerate stuff is easier to deal with as it (iirc) ends up being O(N)-ish if you traverse in the correct order.
6252019-10-31T20:00:28  <jeremyrubin> But the speed of those traversals you have to pay on adding a txn or removing one
6262019-10-31T20:00:30  <ariard> yes nModifiesFees
6272019-10-31T20:00:33  <wumpus> let's wrap up please, it's almost time to close the meeting
6282019-10-31T20:00:36  <jeremyrubin> Ok
6292019-10-31T20:00:59  <jeremyrubin> I guess please review #17268
6302019-10-31T20:01:01  <gribble> https://github.com/bitcoin/bitcoin/issues/17268 | Epoch Mempool by JeremyRubin · Pull Request #17268 · bitcoin/bitcoin · GitHub
6312019-10-31T20:01:13  <wumpus> #action review #17268
6322019-10-31T20:01:13  <luke-jr> jeremyrubin: 1) what is "epoch tracking" ?
6332019-10-31T20:01:15  <gribble> https://github.com/bitcoin/bitcoin/issues/17268 | Epoch Mempool by JeremyRubin · Pull Request #17268 · bitcoin/bitcoin · GitHub
6342019-10-31T20:01:21  <wumpus> #endmeeting
6352019-10-31T20:01:21  <lightningbot> Meeting ended Thu Oct 31 20:01:21 2019 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
6362019-10-31T20:01:21  <lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-31-19.00.html
6372019-10-31T20:01:21  <lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-31-19.00.txt
6382019-10-31T20:01:21  <lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2019/bitcoin-core-dev.2019-10-31-19.00.log.html
6392019-10-31T20:01:22  <instagibbs> new benchmark also https://github.com/bitcoin/bitcoin/pull/17292
6402019-10-31T20:01:26  <sipa> jeremyrubin: it may make sense to give a 1-sentence summary :)
6412019-10-31T20:01:53  <wumpus> cfields: I'll post the proposed 0.20 schedule soon, was waiting for -final, but seems we're almost there anyhow
6422019-10-31T20:01:57  <jeremyrubin> We basically just keep track of the last time we looked at a TxMemPoolEntry
6432019-10-31T20:02:18  <jeremyrubin> And if we've looked more recently than a given time, we ignore looking again.
6442019-10-31T20:02:55  <cfields> wumpus: oh, that was a joke. I was saying we should put out 0.20 before January so we have another release under our belt before Apple decides it doesn't like our dmgs :)
6452019-10-31T20:03:00  <jeremyrubin> Many of the algorithms in the mempool can be simplified greatly with this tactic
6462019-10-31T20:03:03  <nickler> #proposedmeetingtopic security email address for bitcoin-core/secp256k1 (https://github.com/bitcoin-core/secp256k1/pull/679)
6472019-10-31T20:03:42  <jeremyrubin> luke-jr: does that make sense?
6482019-10-31T20:03:44  <luke-jr> jeremyrubin: as for standards, does it hurt performance when using policies other than Core's feerate-only one?
6492019-10-31T20:03:46  <luke-jr> jeremyrubin: as for standards, does it hurt performance when using policies other than Core's feerate-only one?
6502019-10-31T20:03:47  <luke-jr> jeremyrubin: eg, I would want someone to evalulate if it makes priority-based mining any slower or harder to implemented
6512019-10-31T20:04:05  <jeremyrubin> luke-jr: Unless you have something odd, it should have no impact
6522019-10-31T20:04:10  <sipa> luke-jr: that's completely orthogonal; it just speeds up all recursive algorithms over transactions
6532019-10-31T20:04:13  <jeremyrubin> * negative impact
6542019-10-31T20:04:47  <sipa> am i right: (a) there is a global epoch counter in the overall mempool; (b) every time we "iterate" in a recursive algorithm through a transaction, that transaction's timestamp is set to the mempool epoch and the epoch is incremented (c) when iterating, you can ignore any transaction whose timestamp is later than the epoch of when you started iterating; (d) you make sure there are no two recursive
6552019-10-31T20:04:53  <sipa> algorithms simultaneously updating the...
6562019-10-31T20:04:56  <sipa> timestamps
6572019-10-31T20:05:04  <jeremyrubin> yes
6582019-10-31T20:05:23  <jeremyrubin> Although there are specific cases where the recursive both updating is desirable
6592019-10-31T20:05:28  <jeremyrubin> It's not used here
6602019-10-31T20:06:06  <jeremyrubin> This also opens us up to really fancy pants stuff down the line like parallelized mempool traversals
6612019-10-31T20:07:00  <jeremyrubin> Because the epochs are replacing data structures like std::set
6622019-10-31T20:07:36  <jeremyrubin> sipa: but yeah your base understanding is spot on
6632019-10-31T20:07:57  <jeremyrubin> THe other benefit is that we can now accumulate the results into better data structures, e.g., vec instead of set
6642019-10-31T20:08:10  <luke-jr> jeremyrubin: not really, but I'm having some connection issues, so I may have missed parts
6652019-10-31T20:08:17  <luke-jr> nickler: I wonder if it would make sense to simply have different PGP targets - it can be helpful to know a report was made even if you're not privy to the nature of it
6662019-10-31T20:08:19  <luke-jr> eg, if Wladimir is preparing a final release when a security issue gets reported, he knows to check with sipa or someone else if it should get delayed
6672019-10-31T20:09:39  <jeremyrubin> luke-jr: just read the pr if you haven't? It's like +300loc -200loc. It should have 0 impact on priority mining
6682019-10-31T20:09:44  *** rex4539_ has joined #bitcoin-core-dev
6692019-10-31T20:10:10  *** rex4539_ has quit IRC
6702019-10-31T20:10:19  <jeremyrubin> You can look at just like the first couple commits, and then you'll get the gist
6712019-10-31T20:10:32  <luke-jr> jeremyrubin: I'll have to re-read the log later when my connection is better
6722019-10-31T20:10:33  <luke-jr> or the PR
6732019-10-31T20:10:45  <luke-jr> k
6742019-10-31T20:10:52  <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/17268/commits/b01cdd429459a1db42a3c24b7bf141c6695e21de
6752019-10-31T20:11:13  <jeremyrubin> https://github.com/bitcoin/bitcoin/pull/17268/commits/17a0a5214666871ea2fe7134d99733090f4acf4a
6762019-10-31T20:11:38  <jeremyrubin> Just look at those two; that's the basic idea and the rest of the PR is just refinements/applications of that principal
6772019-10-31T20:13:20  *** rex4539 has quit IRC
6782019-10-31T20:14:56  <sipa> principle?
6792019-10-31T20:21:16  *** rex4539 has joined #bitcoin-core-dev
6802019-10-31T20:22:38  <jeremyrubin> yeah my bad
6812019-10-31T20:22:44  *** rex4539 has quit IRC
6822019-10-31T20:27:59  *** captjakk has joined #bitcoin-core-dev
6832019-10-31T20:32:44  *** xoyi- has joined #bitcoin-core-dev
6842019-10-31T20:33:34  *** EagleTM has joined #bitcoin-core-dev
6852019-10-31T20:36:48  <nickler> luke-jr: good point. It seems like you're suggesting to use security@bitcoincore.org then? That has the downside of potentially (depending how it's actually set up) reaching more people when the report is unencrypted.
6862019-10-31T20:36:50  *** rex4539 has joined #bitcoin-core-dev
6872019-10-31T20:37:17  <nickler> Alternatively it's the responsibility of the secp256k1-security@bitcoincore.org people to warn Wladimir before making a release
6882019-10-31T20:42:00  <jeremyrubin> So another topic; can we make the benchmarking framework support asymptotic testing too?
6892019-10-31T20:42:05  <jeremyrubin> Or add a new one?
6902019-10-31T20:42:28  <jeremyrubin> E.g., it would be nice to be able to run an algorithm 10 times with inputs that are powers of 10
6912019-10-31T20:42:40  *** captjakk has quit IRC
6922019-10-31T20:42:44  <jeremyrubin> And collect the outputs.
6932019-10-31T20:43:05  <jeremyrubin> But this is incompatible with the current framework, which has a goal of having the test take a second or something
6942019-10-31T20:43:09  *** captjakk has joined #bitcoin-core-dev
6952019-10-31T20:43:45  *** captjakk has joined #bitcoin-core-dev
6962019-10-31T20:44:36  *** captjakk has joined #bitcoin-core-dev
6972019-10-31T20:44:58  *** captjakk has quit IRC
6982019-10-31T20:45:13  *** captjakk has joined #bitcoin-core-dev
6992019-10-31T20:46:01  *** captjakk has joined #bitcoin-core-dev
7002019-10-31T20:49:24  <luke-jr> nickler: dunno, just a thought; also, would they warn me or other affected software too?
7012019-10-31T20:49:43  *** xoyi- has quit IRC
7022019-10-31T20:51:47  <luke-jr> probably a broader discussion of security handlign is desirable (to avoid a repeat of 17144, fix the "stuff never gets disclosed" issue, etc)
7032019-10-31T20:53:35  *** ExtraCrispy has quit IRC
7042019-10-31T20:54:37  *** Guyver2 has quit IRC
7052019-10-31T20:57:33  *** jarthur has joined #bitcoin-core-dev
7062019-10-31T21:00:02  *** GsC_RuL3Z has quit IRC
7072019-10-31T21:00:19  <nickler> I guess that depends and having a defined process could be valuable. Also, making libsecp releases and asking people to update regularly would help. But for now just a contact address would already be a simple and effective improvement over the current situation.
7082019-10-31T21:04:26  *** Chris_Stewart_5 has quit IRC
7092019-10-31T21:17:35  *** sammuel86 has joined #bitcoin-core-dev
7102019-10-31T21:22:04  *** mdunnio has quit IRC
7112019-10-31T21:23:17  *** mdunnio has joined #bitcoin-core-dev
7122019-10-31T21:27:11  *** rex4539 has quit IRC
7132019-10-31T21:27:41  *** rex4539 has joined #bitcoin-core-dev
7142019-10-31T21:32:38  *** arapaho has joined #bitcoin-core-dev
7152019-10-31T21:38:44  *** rex4539 has quit IRC
7162019-10-31T21:42:47  *** mdunnio has quit IRC
7172019-10-31T22:01:31  *** arik_ has quit IRC
7182019-10-31T22:03:13  *** EagleTM has quit IRC
7192019-10-31T22:13:29  *** sipa has quit IRC
7202019-10-31T22:13:44  *** sipa has joined #bitcoin-core-dev
7212019-10-31T22:37:09  *** Chris_Stewart_5 has joined #bitcoin-core-dev
7222019-10-31T22:47:29  *** soju has joined #bitcoin-core-dev
7232019-10-31T22:48:54  *** arik_ has joined #bitcoin-core-dev
7242019-10-31T22:53:10  *** ddustin has quit IRC
7252019-10-31T22:54:03  *** ddustin has joined #bitcoin-core-dev
7262019-10-31T23:08:52  *** astro has quit IRC
7272019-10-31T23:10:15  *** bitcoin-git has joined #bitcoin-core-dev
7282019-10-31T23:10:15  <bitcoin-git> [bitcoin] TheBlueMatt opened pull request #17335: Add test for syncing blocks generated after invalidateblock. (master...2019-10-invalid-mine-test) https://github.com/bitcoin/bitcoin/pull/17335
7292019-10-31T23:10:26  *** bitcoin-git has left #bitcoin-core-dev
7302019-10-31T23:11:40  *** astro has joined #bitcoin-core-dev
7312019-10-31T23:12:58  *** jarthur has quit IRC
7322019-10-31T23:25:37  *** ddustin has quit IRC
7332019-10-31T23:25:52  *** ddustin has joined #bitcoin-core-dev
7342019-10-31T23:40:49  *** rabidus has quit IRC
7352019-10-31T23:42:29  *** rabidus has joined #bitcoin-core-dev
7362019-10-31T23:51:17  *** Chris_Stewart_5 has quit IRC
7372019-10-31T23:54:00  *** bitcoin-git has joined #bitcoin-core-dev
7382019-10-31T23:54:01  <bitcoin-git> [bitcoin] Rjected opened pull request #17336: scripts: search for first block file for linearize-data with some block files pruned (master...linearize) https://github.com/bitcoin/bitcoin/pull/17336
7392019-10-31T23:54:06  *** Am3nadiel has joined #bitcoin-core-dev
7402019-10-31T23:54:13  *** bitcoin-git has left #bitcoin-core-dev