--- Day changed Wed Aug 16 2017
00:02 -!- klebs [~klebs@65.sub-70-197-15.myvzw.com] has quit [Client Quit]     
00:03 -!- promag [~Adium@248.47.43.5.rev.vodafone.pt] has joined #bitcoin-core-dev     
00:17 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
00:18 -!- treebeardd [~treebeard@73.109.60.183] has quit [Quit: Leaving...]     
00:19 -!- cfields_ is now known as cfields     
00:20 -!- cfields [~quassel@unaffiliated/cfields] has quit [Quit: cfields]     
00:20 -!- cfields [~quassel@unaffiliated/cfields] has joined #bitcoin-core-dev     
00:36 < wumpus> as I had to test binary upload I've already uploaded rc1 to both sites https://bitcoin.org/bin/bitcoin-core-0.15.0/test.rc1/   https://bitcoincore.org/bin/bitcoin-core-0.15.0/test.rc1/ - but we should wait with announcing this publicly until there's at least two more gitian sigs for the code-signed executables
00:50 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
00:56 -!- promag [~Adium@248.47.43.5.rev.vodafone.pt] has quit [Quit: Leaving.]     
00:58 -!- promag [~Adium@248.47.43.5.rev.vodafone.pt] has joined #bitcoin-core-dev     
01:06 -!- promag [~Adium@248.47.43.5.rev.vodafone.pt] has quit [Quit: Leaving.]     
01:12 -!- Austindoggie_ [~austindog@2601:647:ca80:1f82:ad80:26a3:bdbd:9569] has quit [Remote host closed the connection]     
01:25 < bitcoin-git> [bitcoin] kallewoof opened pull request #11062: [mempool] Mark mempool import fails that were found in mempool as 'already there' (master...mempool-alreadythere) https://github.com/bitcoin/bitcoin/pull/11062
01:31 -!- fanquake [~fanquake@unaffiliated/fanquake] has joined #bitcoin-core-dev     
01:31 < fanquake> wumpus I've pushed up signed sigs
01:42 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:f5e8:5872:665a:47df] has joined #bitcoin-core-dev     
01:46 -!- vicenteH [~user@195.235.96.150] has joined #bitcoin-core-dev     
01:52 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:f5e8:5872:665a:47df] has quit [Ping timeout: 255 seconds]     
01:58 -!- grandfso [~quassel@host-85.14.101.166.static.3s.pl] has joined #bitcoin-core-dev     
02:20 -!- goatpig [0599e923@gateway/web/freenode/ip.5.153.233.35] has joined #bitcoin-core-dev     
02:22 -!- miknotauro [~miknotaur@c-67-185-35-159.hsd1.wa.comcast.net] has quit [Ping timeout: 246 seconds]     
02:35 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
02:40 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Quit: WeeChat 1.7.1]     
03:07 -!- JackH [~laptop@79-73-189-225.dynamic.dsl.as9105.com] has quit [Quit: Leaving]     
03:23 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
03:48 < wumpus> fanquake: thanks!
03:59 -!- shesek [~shesek@bzq-84-110-177-132.red.bezeqint.net] has joined #bitcoin-core-dev     
04:00 -!- shesek [~shesek@bzq-84-110-177-132.red.bezeqint.net] has quit [Changing host]     
04:00 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
04:19 -!- promag [~Adium@248.47.43.5.rev.vodafone.pt] has joined #bitcoin-core-dev     
04:26 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
04:31 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
04:37 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
04:39 -!- grandfso_ [~quassel@host-85.14.101.166.static.3s.pl] has joined #bitcoin-core-dev     
04:42 -!- grandfso [~quassel@host-85.14.101.166.static.3s.pl] has quit [Ping timeout: 246 seconds]     
04:50 -!- grandfso_ [~quassel@host-85.14.101.166.static.3s.pl] has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]     
04:50 -!- grandfso [~quassel@host-85.14.101.166.static.3s.pl] has joined #bitcoin-core-dev     
04:57 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
04:59 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 246 seconds]     
05:09 -!- fanquake [~fanquake@unaffiliated/fanquake] has quit [Quit: Leaving.]     
05:12 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
05:46 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
05:51 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:02 -!- promag [~Adium@248.47.43.5.rev.vodafone.pt] has quit [Quit: Leaving.]     
06:26 -!- promag [~Adium@248.47.43.5.rev.vodafone.pt] has joined #bitcoin-core-dev     
06:37 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]     
06:59 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d451d0bcf15d...c484ec6c9b85
06:59 < bitcoin-git> bitcoin/master 36d326e practicalswift: Use nullptr instead of zero (0) as the null pointer constant
06:59 < bitcoin-git> bitcoin/master c484ec6 MarcoFalke: Merge #10645: Use nullptr (C++11) instead of zero (0) as the null pointer constant...
06:59 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10645: Use nullptr (C++11) instead of zero (0) as the null pointer constant (master...welcome-nullptr-goodbye-0) https://github.com/bitcoin/bitcoin/pull/10645
07:00 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
07:01 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
07:12 < bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c484ec6c9b85...22e301a3d56d
07:12 < bitcoin-git> bitcoin/master a622a17 João Barbosa: Fix constness of ArgsManager methods
07:12 < bitcoin-git> bitcoin/master 22e301a MarcoFalke: Merge #10901: Fix constness of ArgsManager methods...
07:13 < bitcoin-git> [bitcoin] MarcoFalke closed pull request #10901: Fix constness of ArgsManager methods (master...2017-07-args-manager-constness) https://github.com/bitcoin/bitcoin/pull/10901
07:45 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Quit: WeeChat 1.4]     
07:45 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
07:50 -!- Skynets [5896ba02@gateway/web/cgi-irc/kiwiirc.com/ip.88.150.186.2] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
07:50 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
07:50 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
07:51 -!- Skynets [5896e622@gateway/web/cgi-irc/kiwiirc.com/ip.88.150.230.34] has joined #bitcoin-core-dev     
07:58 -!- grandfso [~quassel@host-85.14.101.166.static.3s.pl] has quit [Quit: Poof, and I'm gone]     
08:07 < BlueMatt> alrighty, what should I be reviewing?
08:20 -!- hwl3o [268e7c0a@gateway/web/freenode/ip.38.142.124.10] has joined #bitcoin-core-dev     
08:21 -!- hwl3o [268e7c0a@gateway/web/freenode/ip.38.142.124.10] has quit [Client Quit]     
08:24 < promag> BlueMatt: #11006 it's one line :P
08:28 < bitcoin-git> [bitcoin] practicalswift opened pull request #11066: Document the preference of nullptr over NULL or (void*)0 (master...document-nullptr-preference) https://github.com/bitcoin/bitcoin/pull/11066
08:36 < gribble> https://github.com/bitcoin/bitcoin/issues/11006 | Improve shutdown process by promag · Pull Request #11006 · bitcoin/bitcoin · GitHub
08:49 < BlueMatt> cfields: can you rebase #10756 ?
08:51 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #11067: [qa] TestNode: Add wait_until_node_stopped helper method (master...Mf1708-qaTestnodeWaitStopHelper) https://github.com/bitcoin/bitcoin/pull/11067
08:51 < cfields> BlueMatt: sure
08:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
09:01 < gribble> https://github.com/bitcoin/bitcoin/issues/10756 | net processing: swap out signals for an interface class by theuni · Pull Request #10756 · bitcoin/bitcoin · GitHub
09:08 < BlueMatt> cfields: thnks, gonna take a crack at rebasing on it :)
09:14 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:17 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Ping timeout: 276 seconds]     
09:19 < bitcoin-git> [bitcoin] MarcoFalke opened pull request #11068: [WIP] qa: Replace wait_until with wait_until_mn (scripted) (master...Mf1708-qaWaitUntilMiniNode) https://github.com/bitcoin/bitcoin/pull/11068
09:25 -!- d_t [~d_t@108-65-78-188.lightspeed.sntcca.sbcglobal.net] has joined #bitcoin-core-dev     
09:56 < bitcoin-git> [bitcoin] popenkomaksim opened pull request #11069: Trivial: Lossless image optimization. (master...master) https://github.com/bitcoin/bitcoin/pull/11069
10:03 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:04 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Ping timeout: 260 seconds]     
10:15 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Quit: WeeChat 1.4]     
10:17 -!- Giszmo [~leo@net-188-153-89-117.cust.vodafonedsl.it] has joined #bitcoin-core-dev     
10:17 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
10:17 -!- promag [~Adium@248.47.43.5.rev.vodafone.pt] has quit [Quit: Leaving.]     
10:18 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev     
10:18 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Read error: No route to host]     
10:18 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev     
10:19 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Client Quit]     
10:19 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
10:31 < cfields> morcos: ping
10:33 < cfields> morcos: while profiling some new net code yesterday, i noticed that TxConfirmStats::UpdateMovingAverages is a notable hotspot
10:34 < cfields> during IBD, it accounted for ~5-10% of the message handler thread
10:34 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
10:35 < cfields> cpu usage, that is
10:37 -!- vicenteH [~user@195.235.96.150] has quit [Ping timeout: 240 seconds]     
10:38 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:f8b5:ea68:6579:fd60] has joined #bitcoin-core-dev     
10:39 < sipa> cfields: during IBD? :o
10:39 < cfields> sipa: that was my thought :\
10:40 < cfields> IBD up to 200k blocks, anyway
10:45 < BlueMatt> cfields: well, it'll be in the background in 16 :/
10:46 < cfields> BlueMatt: surely it's not necessary until we're nearly caught up?
10:51 < sdaftuar> cfields: i'd guess the implementation is probably just trying to make sure that the estimates properly decay when a node is catching up after being down for a while
10:55 < cfields> well i have a quick optim to speed up that function, but i figured it'd just result in a discussion about avoiding it during early IBD
10:55 < gmaxwell> I assume a simple branch to skip decays when everything is zero would speed that right up.
10:55 < cfields> I'll PR the speedup, and create an issue to discuss avoidance
10:56 < gmaxwell> sipa: we test too much with reindex chainstate
10:56 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:f8b5:ea68:6579:fd60] has quit [Ping timeout: 246 seconds]     
10:56 < cfields> gmaxwell: ah, i was wondering why you hadn't nagged about it :)
11:04 -!- To7 [~theo@2604:2000:1382:b7:5028:4a13:60c:3f15] has quit [Ping timeout: 255 seconds]     
11:06 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
11:08 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
11:11 -!- RoyceX [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 246 seconds]     
11:20 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
11:20 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
11:21 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 240 seconds]     
11:22 < cfields> BlueMatt: rebased
11:26 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev     
11:37 -!- Giszmo [~leo@net-188-153-89-117.cust.vodafonedsl.it] has quit [Quit: Leaving.]     
11:44 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has joined #bitcoin-core-dev     
11:45 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
11:55 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has quit [Quit: ZZZzzz…]     
11:58 < BlueMatt> gmaxwell: well its gonna be slow after sync anyway, so just move it into the background where it wont slow down ibd at all and will be fast later, too :p
11:58 < BlueMatt> cfields: thanks
12:00 < gmaxwell> BlueMatt: well I agree, but a branch on already zero is perhaps a four line change.
12:03 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
12:04 < BlueMatt> gmaxwell: a branch to put it in the background is probably 3 at this point :p
12:06 < BlueMatt> can someone remind me whats left to switch the sync.h stuff to std::mutex?
12:06 < BlueMatt> looks like it may be needed for #10923
12:07 < gribble> https://github.com/bitcoin/bitcoin/issues/10923 | Use -Wthread-safety-analysis if available (+ -Werror=[…] if --enable-werror) by practicalswift · Pull Request #10923 · bitcoin/bitcoin · GitHub
12:13 -!- goatpig [0599e923@gateway/web/freenode/ip.5.153.233.35] has quit [Quit: Page closed]     
12:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
12:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:22 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has quit [Quit: ZZZzzz…]     
12:27 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 246 seconds]     
12:33 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
12:34 < bitcoin-git> [bitcoin] practicalswift opened pull request #11071: Use static_assert(…, …) instead of assert(…) where appropriate (master...static_assert) https://github.com/bitcoin/bitcoin/pull/11071
12:37 < morcos> cfields: hmm...  that's somewhat surprising, but yes i guess if all the other operations are basically very quick with the early blocks, that one takes just as long
12:37 < morcos> i'd be happy to look at your speedup
12:38 < morcos> i think we could also do something relatively simple to avoid doing it if blocks are less than some reasonable checkpointed height or something
12:38 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:90f5:e84b:409c:4732] has joined #bitcoin-core-dev     
12:42 -!- ekerstei_ [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
12:42 -!- eck [~eck@fsf/member/eck] has quit [Quit: we out here]     
12:42 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has quit [Ping timeout: 240 seconds]     
12:42 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
12:42 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
12:44 -!- eck [~eck@fsf/member/eck] has quit [Client Quit]     
12:44 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
12:44 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
12:46 -!- eck [~eck@fsf/member/eck] has quit [Client Quit]     
12:46 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
12:47 -!- eck [~eck@fsf/member/eck] has quit [Client Quit]     
12:48 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
12:52 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
12:54 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
12:55 < BlueMatt> morcos: the height-at-which-0.15-was-released is sufficient, cause your estimates get wiped anyway :p
12:55 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
13:01 -!- Skynets [5896e622@gateway/web/cgi-irc/kiwiirc.com/ip.88.150.230.34] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
13:02 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
13:03 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
13:04 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
13:32 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:90f5:e84b:409c:4732] has quit [Ping timeout: 240 seconds]     
13:39 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:d0f:d643:aae3:be2b] has joined #bitcoin-core-dev     
13:54 -!- treebeardd [~treebeard@73.109.61.174] has joined #bitcoin-core-dev     
14:00 < jimpo> If I rebroadcast an already-confirmed transaction, will Bitcoin Core nodes add it as an orphan tx?
14:03 < sipa> it may
14:04 < jimpo> I see this https://github.com/bitcoin/bitcoin/blob/master/src/validation.cpp#L545
14:05 < jimpo> When would an old output be in the pcoinsTip cache?
14:06 < sipa> because its output isn't spent yet
14:06 < jimpo> OK, makes sense
14:17 < jimpo> So in the case where you rebroadcast a transaction with all spent outputs, and it is added as an orphan, the node will then reject all of the parent transactions to that one?
14:17 < jimpo> request* not reject
14:17 < sipa> right, which other peers likely don't have anymore
14:23 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]     
14:31 -!- harrymm1 [~wayne@125-227-207-249.HINET-IP.hinet.net] has joined #bitcoin-core-dev     
14:32 -!- harrymm [~wayne@125-227-221-27.HINET-IP.hinet.net] has quit [Ping timeout: 246 seconds]     
14:34 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
14:48 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
14:50 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
14:55 -!- ekerstei_ [~ekerstein@ip-64-134-180-44.public.wayport.net] has quit [Quit: See ya...]     
16:30 -!- echonaut [~echonaut@46.101.192.134] has quit [Remote host closed the connection]     
16:30 -!- echonaut [~echonaut@46.101.192.134] has joined #bitcoin-core-dev     
16:35 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]     
16:36 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
16:39 -!- juscamarena [~justin@47.148.173.164] has joined #bitcoin-core-dev     
16:39 -!- juscamarena is now known as Guest18809     
16:41 -!- juscamarena_ [~justin@47.148.173.164] has quit [Ping timeout: 276 seconds]     
16:46 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
16:47 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has quit [Remote host closed the connection]     
16:48 -!- d9b4bef9 [~d9b4bef9@web501.webfaction.com] has joined #bitcoin-core-dev     
16:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
16:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit]     
16:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
16:59 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 255 seconds]     
17:05 -!- miknotauro [~miknotaur@71.4.37.2.ptr.us.xo.net] has joined #bitcoin-core-dev     
17:08 -!- shesek [~shesek@bzq-84-110-232-225.red.bezeqint.net] has joined #bitcoin-core-dev     
17:13 -!- belcher [~belcher@unaffiliated/belcher] has joined #bitcoin-core-dev     
17:13 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:20 -!- ekerstein [~ekerstein@63.250.89.22] has joined #bitcoin-core-dev     
17:25 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
17:27 -!- shesek [~shesek@bzq-84-110-232-225.red.bezeqint.net] has quit [Changing host]     
17:27 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
17:27 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:d0f:d643:aae3:be2b] has quit [Ping timeout: 276 seconds]     
17:27 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 264 seconds]     
17:32 -!- miknotauro [~miknotaur@71.4.37.2.ptr.us.xo.net] has quit [Ping timeout: 260 seconds]     
17:39 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
17:42 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
17:50 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:f1f8:9016:8952:ec90] has joined #bitcoin-core-dev     
17:52 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
17:56 -!- ekerstein [~ekerstein@63.250.89.22] has quit [Quit: ZZZzzz…]     
18:03 < gmaxwell> Wow, this is super dishonest https://segwit2x.github.io/segwit2x-announce.html  ... "Bitcoin Upgrade" is untrue... it claims Bitcoin "Classic" and unlimited are compatible "Compatible Fully-Validating Node Software" but they don't implement the S2X rules and don't even implement segwit!
18:06 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
18:07 -!- dabura667_ [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
18:17 < luke-jr> gmaxwell: Classic and BU merged 2X code
18:18 < luke-jr> funny how they didn't include XT, Knots, btcsuite, et al on their lists
18:19 < gmaxwell> luke-jr: they merged segwit?!
18:19 < luke-jr> gmaxwell: no, just 2X
18:19 < luke-jr> it's still super dishonest, just not *totally* bogus
18:19 < gmaxwell> then they're not compatible fully validating s2x nodes.
18:19 < luke-jr> remember that crowd thinks SPV is fine
18:19 < gmaxwell> they don't list bitcoinj
18:20 < gmaxwell> or any other SPV client.
18:20 < luke-jr> ‎[01:19:28] ‎<‎luke-jr‎>‎ it's still super dishonest, just not *totally* bogus
18:21 < gmaxwell> if they said "[compatible fully validating nodes] btc1 \n [compatible wallet software] bitcoin classic\n" it would n... oh okay, well I suppose because it's not a lie in every possible sense it's okay. :P
18:21 < luke-jr> in other news, Texas Bitcoin conference is promoting 2X as if it's Bitcoin, so I think that makes the decision to go simple (ie, not to)
18:24 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
18:25 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]     
18:38 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
18:47 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
18:53 < morcos> BlueMatt: is there an ascii middle finger? 3- or something?
19:06 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev     
19:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
19:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
19:15 < jimpo> This grant doesn't appear to be checked in ThreadOpenConnections. https://github.com/bitcoin/bitcoin/blob/master/src/net.cpp#L1712. Only the one in ProcessOneShot is. Why is that?
19:17 < jimpo> Ah, got it. It's the fTry constructor param.
19:19 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
19:20 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Remote host closed the connection]     
19:20 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
19:52 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
19:54 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
19:54 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Client Quit]     
19:55 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev     
19:56 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 264 seconds]     
19:59 -!- miknotauro [~miknotaur@c-67-185-35-159.hsd1.wa.comcast.net] has joined #bitcoin-core-dev     
20:04 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 264 seconds]     
20:49 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:f1f8:9016:8952:ec90] has quit [Ping timeout: 246 seconds]     
21:05 < shesek> gmaxwell, luke-jr: I mentioned that to them: https://github.com/segwit2x/segwit2x.github.io/pull/6#discussion_r132615997 https://github.com/segwit2x/segwit2x.github.io/pull/6#discussion_r132616222
21:05 < shesek> they ignored me.
21:07 < chainhead> I also mentioned it, multiple times and they deny that it is even possibly misleading
21:11 -!- Austindoggie_ [~austindog@2600:380:4655:a45d:95ed:181e:f7fe:4b5b] has joined #bitcoin-core-dev     
21:13 -!- treebeardd [~treebeard@73.109.61.174] has quit [Remote host closed the connection]     
21:17 -!- treebeardd [~treebeard@73.109.61.174] has joined #bitcoin-core-dev     
21:26 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has quit [Quit: See ya...]     
21:31 -!- treebeardd [~treebeard@73.109.61.174] has quit [Quit: Leaving...]     
21:35 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev     
21:42 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [K-Lined]     
21:42 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [K-Lined]     
21:42 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [K-Lined]     
21:42 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [K-Lined]     
21:42 -!- sam_c [~sam_c@gateway/tor-sasl/stanley] has quit [K-Lined]     
21:42 -!- kanzure [~kanzure@unaffiliated/kanzure] has quit [K-Lined]     
--- Log closed Wed Aug 16 21:42:06 2017
--- Log opened Thu Aug 17 03:45:17 2017
03:45 -!- kanzure [~kanzure@unaffiliated/kanzure] has joined #bitcoin-core-dev     
03:45 -!- Irssi: #bitcoin-core-dev: Total of 170 nicks [0 ops, 0 halfops, 0 voices, 170 normal]     
03:51 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
03:53 -!- Irssi: Join to #bitcoin-core-dev was synced in 473 secs
04:11 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
04:29 -!- morcos [~morcos@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
04:32 -!- promag [~Adium@20.33.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
05:11 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
05:11 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:24 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
05:25 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
05:29 < bitcoin-git> [bitcoin] BitonicEelis opened pull request #11073: Remove dead store in ecdsa_signature_parse_der_lax. (master...deadstore) https://github.com/bitcoin/bitcoin/pull/11073
05:39 -!- Deacyded [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
05:42 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 246 seconds]     
05:43 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
05:45 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
05:46 -!- Deacyded [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 246 seconds]     
06:00 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 246 seconds]     
06:01 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
06:01 -!- promag [~Adium@20.33.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
06:04 -!- promag [~Adium@20.33.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
06:06 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 246 seconds]     
06:11 -!- rockhouse [~rockhouse@h54110.upc-h.chello.nl] has joined #bitcoin-core-dev     
06:11 -!- rockhouse [~rockhouse@h54110.upc-h.chello.nl] has quit [Changing host]     
06:11 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has joined #bitcoin-core-dev     
06:15 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Quit: WeeChat 1.4]     
06:18 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
06:19 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
06:21 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
06:33 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
06:35 < bitcoin-git> [bitcoin] BitonicEelis opened pull request #11074: Assert that CWallet::SyncMetaData finds oldest transaction. (master...syncassert) https://github.com/bitcoin/bitcoin/pull/11074
06:37 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
06:43 -!- jnewbery [~john@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
06:44 -!- webuser232 [57c4e5cc@gateway/web/freenode/ip.87.196.229.204] has joined #bitcoin-core-dev     
06:45 < webuser232> gmaxwell, what do you think about this? https://github.com/bitcoin/bitcoin/issues/11064
07:08 -!- waxwing [~waxwing@91.216.245.111] has quit [Changing host]     
07:08 -!- waxwing [~waxwing@unaffiliated/waxwing] has joined #bitcoin-core-dev     
07:19 -!- eenoch [~eenoch@unaffiliated/eenoch] has joined #bitcoin-core-dev     
07:31 < bitcoin-git> [bitcoin] practicalswift opened pull request #11076: 0.15 release-note nits: fix redundancy, remove accidental parenthesis & fix range style (0.15...0.15-release-notes) https://github.com/bitcoin/bitcoin/pull/11076
07:42 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev     
07:48 < BlueMatt> morcos: I appreciate that you ask me, but I'm certainly not hip with the ascii art
07:53 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
07:55 < bitcoin-git> [bitcoin] jnewbery opened pull request #11077: [tests] fix timeout issues from TestNode (master...test_node_fixes) https://github.com/bitcoin/bitcoin/pull/11077
08:01 < morcos> BlueMatt: well it was most relevant what you would interpret that way... :)
08:01 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
08:05 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
08:06 < webuser232> wumpus, re your reply over https://github.com/bitcoin/bitcoin/issues/11064 , posting an idea publicly like that usually saves you all the work you listed in case you missed something obvious to begin with
08:07 < wumpus> I don't think you missed anything obvious, it should absolutely be possible to use "AI" for fee estimation, if you include all possible things that are counted under the buzzword "AI" nowadays
08:08 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
08:08 -!- zxzzt [~prod@static-100-38-11-146.nycmny.fios.verizon.net] has joined #bitcoin-core-dev     
08:08 < wumpus> without going into detail about what exactly you want to do, there's no useful responses to give
08:09 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
08:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 240 seconds]     
08:09 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has quit [Quit: .]     
08:09 -!- riemann [~riemann@84-10-11-234.static.chello.pl] has quit [Remote host closed the connection]     
08:09 -!- sdaftuar [~sdaftuar@unaffiliated/sdaftuar] has joined #bitcoin-core-dev     
08:10 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 255 seconds]     
08:11 -!- PaulCapestany [~PaulCapes@ip72-209-228-52.dc.dc.cox.net] has joined #bitcoin-core-dev     
08:11 < webuser232> wumpus, I agree with you mostly. I just wanted to see peoples first/gut/intuitive reaction to the idea proposed, that's all.
08:12 -!- Lightsword [~Lightswor@107.170.253.193] has quit [Quit: ZNC]     
08:12 < webuser232> jnewbery, thanks for you input!
08:13 -!- Lightsword [~Lightswor@107.170.253.193] has joined #bitcoin-core-dev     
08:17 < sipa> "use AI to solve it!" is not very different from saying "use software to solve it!"
08:17 < wumpus> why not use physics to solve it!
08:18 -!- karelb [~karelb@li1380-211.members.linode.com] has joined #bitcoin-core-dev     
08:19 < webuser232> sipa, wumpus, very rich. I get it first time. No need to mock.
08:19 < wumpus> but yeah, I'm sure the current fee estimation can be classified as AI of some kind already, despite not yet having gained consciousness
08:19 < karelb> Hello, nobody replied at #bitcoin, I hope I am not interrupting a meeting again, I will ask here
08:20 < karelb> question about bitcoin 0.15.0 ... does estimatesmartfee return the same fees as estimatefee?
08:20 < karelb> ignoring the errors and the conservative mode
08:20 < promag> morcos: is it relevant to call UpdateMovingAverages while syncing?
08:20 < jnewbery> karelb no, it's a new implementation
08:20 < karelb> ok     
08:20 < promag> morcos: there is some performance improvement if not
08:21 < karelb> so esttimatefee returns the same fees, estimatesmartfee returns a better estimate
08:21 < karelb> great
08:21 < morcos> promag: that issue has already been raised.. i think cfields has a proposed fix he is going to PR..  but yeah we should optimize it
08:22 < morcos> karelb: estimatefee is deprecated for 0.15.  it returns something slightly different than 0.14's estimatefee and likely slightly worse
08:22 < morcos> but as close as it could be wihtout a lot of work given the new internals
08:22 < morcos> got to run
08:23 < jnewbery> webuser232 I happen to think fee estimation might be a good candidate for reinforcement learning, but I'm no expert in AI. Run a bitcoind node for some time to get a good history of transactions/blocks and estimaterawfee should give you good data
08:26 < karelb> hm, that is a bit confusing. We are using the old API in our fee estimates, I hoped we could just upgrade the node without new logic for the new call. OK
08:26 < webuser232> jnewbery, I think it's a good candidate too. I'll investigate further. I've got to run for now. Thanks!
08:26 -!- webuser232 [57c4e5cc@gateway/web/freenode/ip.87.196.229.204] has quit [Quit: Page closed]     
08:42 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
08:44 < bitcoin-git> [bitcoin] jnewbery opened pull request #11078: [tests] Make p2p-leaktests.py more robust (master...p2p_leaktests_robust) https://github.com/bitcoin/bitcoin/pull/11078
08:48 -!- JackH [~laptop@46.231.18.66] has quit [Ping timeout: 248 seconds]     
08:50 -!- praxeology [~praxeolog@unaffiliated/praxeology] has joined #bitcoin-core-dev     
08:51 -!- rosenfs [~rosenfs@shairosenfeld.com] has joined #bitcoin-core-dev     
08:54 -!- marcoagner [~user@187.113.128.120] has quit [Ping timeout: 240 seconds]     
08:54 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 255 seconds]     
08:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:06 -!- marcoagner [~user@179.177.240.202] has joined #bitcoin-core-dev     
09:08 -!- promag [~Adium@20.33.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
09:11 < BlueMatt> grr, does someone have a fucking openbsd box to test build on?
09:12 -!- jcorgan [~jcorgan@unaffiliated/jcorgan] has joined #bitcoin-core-dev     
09:14 < wumpus> yes     
09:15 < wumpus> BlueMatt: I have an openbsd 6.1 box to test on - what do you need tested?
09:19 < BlueMatt> wumpus: just looks like there's been a few build errors on openbsd recently (I assume 15rc1 testing) eg #11057
09:20 < wumpus> ooh the gui on opennsd? I don't think anyone even tried that before, certainly not me
09:23 < wumpus> #11057 looks like a conflict between GL driver and libdrm version?
09:25 -!- promag [~Adium@20.33.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
09:25 < BlueMatt> possibly? I dunno
09:25 < wumpus> nothing we can help in any case
09:27 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
09:28 -!- treebeardd [~treebeard@73.109.61.126] has joined #bitcoin-core-dev     
09:29 < wumpus> building anything on openbsd is difficult, I can't imagine the nightmare of getting the opengl/X/qt stack to work on that
09:33 < BlueMatt> wumpus: have you managed to repro the crashes in bitcoind in #11063?
09:33 < BlueMatt> wasnt there a similar one in test_bitcoin, too?
09:34 < wumpus> haven't tried yet
09:34 < wumpus> last time I ran the tests on openbsd it was all ok, but it's been a few months ago
09:34 < BlueMatt> oh, no, it was in bench
09:34 < BlueMatt> yea, #10801
09:34 < BlueMatt> yea, sounds like openbsd got fucked again :(
09:35 < wumpus> (no, shorter ago, this was around the time the asm changes went in)
09:35 < BlueMatt> wonder where we can find an openbsd dev to contribute :p
09:36 < wumpus> it's funny how gdb is fucked on all BSD
09:36 < BlueMatt> yea :/
09:36 < wumpus> at least on freebsd it's easy (and encouraged) to install a newer one, but the default one is ancient, from 2004
09:37 < wumpus> this means it cannot understand the debug information (DWARF 3) generated by compilers of this decennium
09:37 < BlueMatt> so they're taking the debian approach of keeping people on ancient versions of things :(
09:37 < wumpus> it has some license-related reason
09:38 < wumpus> same reason why the default gcc on openbsd is a patched 4.2, that was the last one before going to GPL3 which is no longer acceptable
09:38 < BlueMatt> lol     
09:38 < BlueMatt> man licensing sucks
09:39 < wumpus> would be wiser to go to llvm/clang as that does have a bsd compatible license, FreeBSD did that for many platforms already
09:39 < grubles> yeah i think obsd is completely ditching gcc for clang soon
09:39 < grubles> i think i read that the other day
09:39 < wumpus> finally!
09:39 < grubles> yeah https://www.phoronix.com/scan.php?page=news_item&px=OpenBSD-Default-Clang
09:40 < wumpus> (oh, FreeBSD already switched to clang a while ago, what they're doing now is switching the *linker* to clang's linker)
09:41 < wumpus> probably gdb to lldb
09:44 -!- promag [~Adium@20.33.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
09:46 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
09:46 < wumpus> 'gmake check' passes on openbsd
09:47 < wumpus> bench also runs succesfully
09:47 < wumpus> (this is with master, not 0.15 branch, but they have hardly diverged)
09:49 -!- nickler [~nickler@185.12.46.130] has joined #bitcoin-core-dev     
09:49 < gribble> https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
10:00 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
10:17 < gribble> https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
10:18 < wumpus> gribble: why are you repeating that?
10:19 < sipa> 17:17:57 < gribble> https://github.com/bitcoin/bitcoin/issues/11057 | QT5 interface build failed · Issue #11057 · bitcoin/bitcoin · GitHub
10:19 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
10:19 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
10:22 < bitcoin-git> [bitcoin] laanwj opened pull request #11080: doc: Update build-openbsd for 6.1 (master...2017_08_openbsd_bump) https://github.com/bitcoin/bitcoin/pull/11080
10:28 < praxeology> where can I find a spec on how to craft bch transactions? gmaxwell, you said you had/were making a patch?
10:29 < praxeology> Is it just BIP143 + SIGHASH_FORKID = 0x40 ?
10:30 < arubi> and p2pkh\p2sh instead of p2wpkh\p2wpsh
10:30 < arubi> p2wsh*
10:32 < luke-jr> praxeology: it's just Segwit's signature format, with the extra bit set in the sighash flags
10:33 < wumpus> praxeology: this patch adds ALL|ABC support to signrawtransaction: https://github.com/laanwj/bitcoin/commit/22a4c47643203f86e03f4b001e776fcff1fe8d92
10:34 < wumpus> it's not mine, has been floating around for a while - and I guess it's strongly off topic here
10:35 < sipa> i think it's mine :)
10:36 < wumpus> sipa: I wasn't sure whether you wanted credit for it lol
10:36 < praxeology> wumpus: at least I'm not interrupting a meeting this time :p
10:37 < sipa> praxeology: off by 23 minutes
10:37 -!- sanada [sanada@36-2-119-80.chiba.ap.gmo-isp.jp] has joined #bitcoin-core-dev     
10:38 < praxeology> ... So if I run core w/ that patch... I can sign my bch over to shapeshift.io for example?
10:38 < wumpus> yes, that works. Do run it with -nolisten -noconnect to avoid bch transactions from getting into your mempool.
10:39 < praxeology> I'll be running it on an airgapped computer
10:39 < wumpus> you can use https://github.com/laanwj/bitcoin-submittx to submit the signed transaction to a list of BCH nodes
10:41 < gribble> https://github.com/bitcoin/bitcoin/issues/11063 | bitcoind aborts · Issue #11063 · bitcoin/bitcoin · GitHub
10:41 < wumpus> so to be clear that patch won't make it generate BCH transactios by default, you need to run signrawtransaction with 'ALL|ABC' as signature type
10:41 < wumpus> gribble: huh?
10:45 < praxeology> alrighty guys... thanks for the help, and the secret private messages so that only I can benefit :p.  I think I have a solid plan now
10:56 -!- jimmysong [~jimmysong@199.227.42.110] has joined #bitcoin-core-dev     
10:57 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
10:57 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has joined #bitcoin-core-dev     
11:00 < sipa> *DING*
11:00 < BlueMatt> sipa: you're an hour early
11:00 < wumpus> huuh are you sure you're not an hour early?
11:00 < sipa> oops?
11:00 < sipa> yes, it was the "warning, meeting in one hour!" alarm </whateverhappenspretenditwasintentional>
11:01 < gribble> https://github.com/bitcoin/bitcoin/issues/10801 | bench_bitcoin segfaults · Issue #10801 · bitcoin/bitcoin · GitHub
11:01 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ     
11:01 -!- gribble was kicked from #bitcoin-core-dev by sipa [gribble]     
11:01 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
11:01 -!- mode/#bitcoin-core-dev [-o sipa] by sipa     
11:01 < sipa> maybe that'll teach gribble
11:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11057 | Connection timed out.
11:15 -!- mode/#bitcoin-core-dev [+o wumpus] by ChanServ     
11:15 -!- gribble was kicked from #bitcoin-core-dev by wumpus [you're drunk bot, go home!]     
11:15 -!- gribble [~gribble@unaffiliated/nanotube/bot/gribble] has joined #bitcoin-core-dev     
11:17 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has quit [Ping timeout: 268 seconds]     
11:22 -!- afk11 [~afk11@gateway/tor-sasl/afk11] has joined #bitcoin-core-dev     
11:36 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
11:37 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:46 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
11:46 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
11:46 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
11:50 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
11:51 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
11:56 -!- jimmysong [~jimmysong@199.227.42.110] has quit [Remote host closed the connection]     
11:56 -!- clarkmoody [~clarkmood@47-218-249-135.bcstcmta04.res.dyn.suddenlink.net] has joined #bitcoin-core-dev     
11:56 < achow101> wut     
11:57 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
12:00 < BlueMatt> sipa: try again now?
12:00 <@wumpus> #startmeeting
12:00 < lightningbot> Meeting started Thu Aug 17 19:00:14 2017 UTC.  The chair is wumpus. Information about MeetBot at http://wiki.debian.org/MeetBot.
12:00 < lightningbot> Useful Commands: #action #agreed #help #info #idea #link #topic.
12:00 < sipa> DUNG
12:00 < achow101> hi     
12:00 < Chris_Stewart_5> present
12:00 < jtimon> dong
12:00 < jonasschnelli> hi     
12:00 < instagibbs> prezent
12:00 <@wumpus> topics?
12:01 < cfields> hi     
12:01 <@wumpus> #bitcoin-core-dev Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr btcdrak sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101
12:01 < BlueMatt> blockers for review
12:01 <@wumpus> let's start with 0.15.0rc1 - have any serious issues been reported?
12:01 < BlueMatt> and that
12:01 <@wumpus> #topic 0.15.0
12:02 < BlueMatt> there's the openbsd stuff, but I'm not sure thats really 0.15 per se, more than just openbsd brokenness
12:02 < BlueMatt> there's also the version-reporting thing gmaxwell mentioned
12:02 < cfields> only thing i'm aware of is the version number issue, but that's nothing
12:02 <@wumpus> that's just openbsd brittleness, I'm looking at it
12:02 < achow101> there's the duplicate hex in getrawtransaction
12:02 < BlueMatt> plus the new compiler warnings
12:02 <@wumpus> cfields: do we have a patch for that?
12:02 < sipa> and the other things marked for 0.15... #11044 #11027
12:03 < cfields> wumpus: i haven't decided on where to fix it yet. Either way I'll PR something today/tomorrow
12:03 <@wumpus> cfields: I guess in a hurry we could just revert luke-jr's patch that introduces the problem, for 0.15
12:04 < cfields> wumpus: yes, that was my initial suggestion, but luke-jr isn't a fan
12:04 < jonasschnelli> Can you elaborate on the version number issue (via luke-jr's PR)?
12:04 <@wumpus> yes I saw the new compiler warnings, something about signed to unsigned comparison in the wallet version logic
12:04 <@wumpus> is that something serious?
12:05 < cfields> jonasschnelli: the version string doesn't show v0.15.0 as it should, but a git commit instead
12:05 <@wumpus> src/wallet/wallet.cpp:3668:38: warning: comparison of integers of different signs: 'std::set<long, std::less<long>, std::allocator<long> >::size_type' (aka 'unsigned long') and 'int' [-Wsign-compare]
12:05 < cfields> sec for offending PR
12:05 < sipa> suggestion: have travis (which has a deterministic compiler version) in one of the tests run with -Werror... but not for default builds
12:05 <@wumpus> and another one on the same line
12:05 < BlueMatt> sipa: #10923
12:06 < kanzure> hi.     
12:06 <@wumpus> sipa: yeah, no that we no longer have any annoying warnings such as Wshadow we could do that
12:06 < cfields> jonasschnelli: #7522
12:06 < jonasschnelli> wumpus: isn't that (-WSign-compare) fixed with #11044?
12:06 < sipa> BlueMatt: oops, never read the second part of the title
12:06 <@wumpus> jonasschnelli: could be!
12:06 < jonasschnelli> It is. Just checked
12:06 < BlueMatt> sipa: we already have --enable-werror which is an even more limited set of -W's that we error on, but we never enable it on anything
12:07 < BlueMatt> sipa: that pr enables it for thread-safety-analysis and then turns it on on travis-osx
12:07 < cfields> sipa: +1. I think 10923 is a great idea
12:07 < BlueMatt> 10923 is blocked on switching mutexes and sync.h to std, but I think we can just do that (tm)
12:07 < cfields> BlueMatt: not yet :(
12:08 <@wumpus> we can just take the travis-werror part
12:08 <@wumpus> I don't see how that is strongly related to the thread analysis
12:08 < BlueMatt> true
12:08 <@wumpus> switching over mutexes and sync definitely sounds like a post-0.15 thing
12:08 < cfields> yea, we should just go ahead with that and add the thread checking when it's ready
12:08 < BlueMatt> cfields: oh? none of that stuff is used directly in the remaining threadGroup threads
12:09 < BlueMatt> oh, y'all want to turn on -Werror on travis for 15? yea, ok, not that then
12:09 < BlueMatt> anyway, looks like #11044 fixes the warnings, and its already tagged 0.15.0
12:09 < cfields> oh, i thought we were talking about it for master
12:10 <@wumpus> the topic is 0.15 so I was assuming we were talking about 0.15 
12:10 < jonasschnelli> cfields: I have a correct version string in 0.15.0rc1 (Qt, debug log). What do I miss?
12:10 <@wumpus> anyhow, I don't mind, let's enable it for some branch...
12:10 < cfields> BlueMatt: i'll double-check. But I thought we had some outstanding condvars that we couldn't switch yet. Will look after meeting.
12:10 <@wumpus> master is what the PRs will be tested against so that makes most sense I suppose
12:10 < BlueMatt> cfields: we do, but they're directly calling boost::condition_variable, not CConditionVariable, I believe
12:11 < gmaxwell> We can turn of travis Werroring if it turns out to be a pain (or even when not if...) but gain advantages from it until then.
12:11 <@wumpus> ok: does anything need tagging for 0.15.0?
12:11 < cfields> jonasschnelli: the splash screen, at least, shows the git revision
12:11 < BlueMatt> as for 0.15, I think its jsut the 3 tags + whatever for the version string issue
12:11 < BlueMatt> or, nothing else was brought up
12:11 < gribble> https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
12:11 < jonasschnelli> cfields: Ah. I see now.. releases don't have the commit&dirty.. nm
12:12 <@wumpus> okay
12:12 <@wumpus> #topic high-priority for review
12:12  * BlueMatt puts #10286 on the list
12:13 <@wumpus> now that 0.15 is branched, we can start doing this again
12:13 <@wumpus> added
12:13 <@wumpus> it's lonely https://github.com/bitcoin/bitcoin/projects/8
12:13  * jonasschnelli puts Implement BIP159 / #10387  on the list
12:14 < sipa> i'd like to draw some attention to #10785 (serialization improvements)
12:14 < BlueMatt> thats ok, 10286 needs to simmer on master for a month or three, so it is actually a should-go-soon, thing
12:14 < BlueMatt> :p     
12:14 < gribble> https://github.com/bitcoin/bitcoin/issues/11027 | [RPC] Only return hex field once in getrawtransaction by achow101 · Pull Request #11027 · bitcoin/bitcoin · GitHub
12:14 < jonasschnelli> sipa: It's on my list.. reviewed most of it and running on my node
12:14 < gmaxwell> lol poor gribble.
12:14 < gmaxwell> (he's way behind)
12:15 -!- jimmysong [~Jimmy@23-112-39-203.lightspeed.austtx.sbcglobal.net] has joined #bitcoin-core-dev     
12:15 < cfields> I'd like to add #10756 please, as lots of things for 0.16 will build on top of that
12:15 < jonasschnelli> (gribble probably needs to process all the spam first)
12:15 <@wumpus> gribble damnit you made me add 11027, which makes no sense as it's already tagged 0.15
12:16 < jonasschnelli> cfields. done
12:16 < cfields> (that's the signals -> interface class switch for message processing)
12:16 < sipa> cfields: ack
12:16 < BlueMatt> yes! 10756!
12:16 < cfields> jonasschnelli: thanks
12:16 < gribble> https://github.com/bitcoin/bitcoin/issues/10923 | Use -Wthread-safety-analysis if available (+ -Werror=[…] if --enable-werror) by practicalswift · Pull Request #10923 · bitcoin/bitcoin · GitHub
12:16 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ     
12:16  * gmaxwell can't breathe
12:16 -!- mode/#bitcoin-core-dev [+b *!*gribble@unaffiliated/nanotube/bot/gribble] by sipa     
12:16 -!- gribble was kicked from #bitcoin-core-dev by sipa [you're useless]     
12:17 -!- mode/#bitcoin-core-dev [-o sipa] by sipa     
12:17 < jtimon> I would suggest #8498 but not sure if it can be high priority
12:17 < BlueMatt> poor gribble
12:17 -!- promag [~Adium@20.33.54.77.rev.vodafone.pt] has joined #bitcoin-core-dev     
12:17 <@wumpus> aww :)
12:17 < jonasschnelli> :)     
12:17 < cfields> haha
12:17 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has joined #bitcoin-core-dev     
12:18 < gribble> https://github.com/bitcoin/bitcoin/issues/7522 | Bugfix: Only use git for build info if the repository is actually the right one by luke-jr · Pull Request #7522 · bitcoin/bitcoin · GitHub
12:18 <@wumpus> jtimon: added
12:18 < jtimon> cool
12:18 <@wumpus> ok, any other topics?
12:19 < jonasschnelli> short topic: adding bench to gitian build package?
12:19 < jonasschnelli> I can PR
12:19 < cfields> wasn't it just explicitly removed? :)
12:20 < jonasschnelli> Yes. At least on Win
12:20  * jonasschnelli searching PR
12:20 < gribble> https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
12:20 -!- andytoshi [~apoelstra@unaffiliated/andytoshi] has left #bitcoin-core-dev []     
12:20 < achow101> +     
12:21 < jonasschnelli> https://github.com/bitcoin/bitcoin/pull/7776
12:21 <@wumpus> #topic adding bench to gitian build package
12:21 < jonasschnelli> I stumbled over it when wanted to bench sse4
12:21 <@wumpus> I removed it because it was useless at the time, bench had only the examle benchmark
12:21 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ     
12:21 < gribble> https://github.com/bitcoin/bitcoin/issues/11044 | [wallet] Keypool topup cleanups by jnewbery · Pull Request #11044 · bitcoin/bitcoin · GitHub
12:21 -!- mode/#bitcoin-core-dev [-o sipa] by sipa     
12:21 <@wumpus> but now that bench is actually useful I agree with enabling it for the distributions, for all platforms
12:21 -!- mode/#bitcoin-core-dev [+o sipa] by ChanServ     
12:22 -!- mode/#bitcoin-core-dev [-o sipa] by sipa     
12:22 < jonasschnelli> I think its useful now.
12:22 < jonasschnelli> I'll PR that then
12:22 < gribble> https://github.com/bitcoin/bitcoin/issues/10286 | Call wallet notify callbacks in scheduler thread (without cs_main) by TheBlueMatt · Pull Request #10286 · bitcoin/bitcoin · GitHub
12:22 < jtimon> suggested topic, what do we want to do about configs for different chains? related to issue #9374 and prs #10267 #8994 
12:23 < gribble> https://github.com/bitcoin/bitcoin/issues/10387 | Implement BIP159, define and signal NODE_NETWORK_LIMITED (pruned peers) by jonasschnelli · Pull Request #10387 · bitcoin/bitcoin · GitHub
12:23 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
12:23 <@wumpus> jonasschnelli: thanks
12:23 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
12:23 < gribble> https://github.com/bitcoin/bitcoin/issues/10785 | Connection reset by peer.
12:24 < sipa> do we want to discuss bip159 more?
12:24 <@wumpus> jonasschnelli: no rush, we don't really need it in 0.15 yet
12:24 < gribble> https://github.com/bitcoin/bitcoin/issues/10756 | Connection reset by peer.
12:24 < jonasschnelli> Yes. Certenly not for 0.15
12:24 < luke-jr> sorry, here
12:24 <@wumpus> #topic bip159: (NODE_NETWORK_LIMITED service bits)
12:24 < jonasschnelli> last updates on BIP159: threat bits independently, fingerprinting protection
12:25 < luke-jr> ‎[19:03:38] ‎<‎wumpus‎>‎ cfields: I guess in a hurry we could just revert luke-jr's patch that introduces the problem, for 0.15 <-- it fixes other (more real) problems
12:25 < jonasschnelli> The address relay and whole peering maybe needs discussion
12:25 < jonasschnelli> cfields mentioned once some potential issues
12:25 < sipa> so, i'd like to suggest that bip159 only defines 1 bit, corresponding to 144/288 blocks
12:25 <@wumpus> luke-jr: ok, well, can you help cfields fixing the problem then?
12:25 < luke-jr> wumpus: yes, already suggested a few ideas
12:26 < sipa> that gets 90% of the benefit I believe (nodes who are already caught up, and want to stay caught up)
12:26 < sipa> without needing to know what other ranges are important
12:26 < cfields> jonasschnelli: yea, i'll jot down my concerns.
12:26 < jonasschnelli> sipa: we could start with that. What's you concerns about definig two bots?
12:26 < jonasschnelli> bits?
12:27 < sipa> jonasschnelli: i'm beginning to think a second bit is just unnecessary for now
12:27 < sipa> and we may be able to make a more informed choice later
12:27 < instagibbs> sipa, prefer the week or day?
12:27 < sipa> day     
12:27 < gmaxwell> It's also the case that the second bit doesn't really jive with UTXO sync, so it may just end up totally surpflous within a couple months.
12:27 < jonasschnelli> I think the week usecase can be interesting with SPV (client side)
12:27 < gmaxwell> the 288 matches the current minimum.
12:28 < jonasschnelli> You could run a pruned peer while syncing your phone
12:28 < jonasschnelli> (in an ideal BIP150 world)
12:28 < jonasschnelli> (or via tor)
12:28 < gmaxwell> sure, so long as you don't ever forget to run your wallet once a week. :)
12:28 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
12:28 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
12:28 < gmaxwell> you can still do that without the flag however.
12:29 < sipa> the most important benefit is that pruned nodes can and should help with partition resistence of the network, but they currently don't
12:29 < gmaxwell> as any whitepeer would still be able to request anythign we have. (in your BIP150 world that phone would be authenticated, presumably)
12:29 < jonasschnelli> I agree. I think defining only the 288 depth bit is okay. We can define another later.
12:29 < gmaxwell> sipa: well they do a littl.
12:29 < gmaxwell> jonasschnelli: yea, that was my thought. Now quick, slip it into 0.15rc2  _me ducks and runs_
12:29 < jonasschnelli> gmaxwell: good point about the whitepeer, right
12:30 < jonasschnelli> gmaxwell: No 0.15. Sadly
12:30 < sipa> jonasschnelli: i believe gmaxwell may not have been very serious ;)
12:30 < gmaxwell> I'm kidding. :)
12:31 < jonasschnelli> No joking about releases. :)
12:31 < gmaxwell> If we cannot laugh all there is left to do is cry.
12:31 < gmaxwell> :)     
12:32 <@wumpus> exactly
12:32  * sipa mourns the untimely passing of rc1
12:32 < jonasschnelli> Indeed
12:32 < jonasschnelli> Any other thoughts on dropping the 1'152 dept NODE_NETWORK_LIMITED_HIGH flag?
12:33 < gmaxwell> that gets rid of anything to be debated.
12:33 < jonasschnelli> A single flag was also my original idea.. but we had then discussions and the second one came up. So going back to a single bit is fine for me.
12:33 <@wumpus> yes, let's drop it for now
12:34 <@wumpus> it's better to continue with something; the bits debate goes on and on :)
12:34 < gmaxwell> smaller changes faster plz.
12:34 < cfields> 3 bits!
12:34 < jonasschnelli> Heh. Right... okay, will update the bip and the PR.
12:34  * jonasschnelli curses cfields 
12:34 < cfields> :)     
12:34 <@wumpus> cfields: moar!
12:34 -!- promag [~Adium@20.33.54.77.rev.vodafone.pt] has quit [Quit: Leaving.]     
12:34 < sipa> 3.14 bits!
12:35 < jonasschnelli> hehe
12:35 < gmaxwell> next subject?
12:35 < cfields> sipa: that's just irrational.
12:35 < jnewbery> sipa gmaxwell do you have data about what blocks are requested on the network? Have you shared it anywhere?
12:35 < gmaxwell> damn, I almost saved us from that pun.
12:35 < gmaxwell> jnewbery: we do, we have, I can dig it up again later today.
12:35 < jonasschnelli> jnewbery: sipa has that blocks-requested-chart
12:35 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Read error: Connection reset by peer]     
12:35 <@wumpus> #topic what do we want to do about configs for different chains (jtimon)
12:35 < jnewbery> thanks
12:35 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
12:35 < gmaxwell> jtimon: 12:35:36 <@wumpus> #topic what do we want to do about configs for different chains (jtimon)
12:36 < achow101> pr/issue for reference?
12:36 < gmaxwell> there was an overlay config file PR I saw, I like that general idea.
12:36 <@wumpus> related to issue #9374 and prs #10267 #8994
12:36 -!- Chris_St1 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
12:36 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
12:37 < jtimon> sorry, I just fell
12:37 < jtimon> so jnewbery had some suggestions for #8994 https://github.com/bitcoin/bitcoin/pull/8994#issuecomment-321355349
12:37 < jtimon> #10267 is slightly related
12:37 < jtimon> and there's the issue #9374
12:38 < BlueMatt> <gribble> https://github.com/bitcoin/bitcoin/issues/10267 | INew -includeconf argument for including external configuration files by kallewoof · Pull Request #10267 · bitcoin/bitcoin · GitHub
12:39 <@wumpus> not much to discuss from my side really, I think the idea of additional per-chain config files is good
12:39 < sipa> we know but one gribble, and his name is BlueMatt
12:39 <@wumpus> need to review the PRs
12:40 <@wumpus> also we really need test for initialization order / argument precedence stuff
12:40 -!- chjj [~chjj@c-24-130-173-170.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]     
12:40 <@wumpus> as it becomes more complex with this
12:40 < gmaxwell> The Gribble is dead, long live the Gribble.
12:40 < jtimon> network.conf idea seems good to me, perhaps I could the something similar for /chain.conf, but not sure about jnewbery's suggestion because that would allow them to be used with the mainnet
12:41 < gmaxwell> okay, so comment on PRs?
12:41 < jtimon> well, I guess it can be discussed on the prs, yeah
12:41 < jtimon> just poiting out the 3 things seem related to me
12:41 <@wumpus> yes     
12:42 < luke-jr> wumpus: bitcoin_rw.conf solves per-chain at the same time, so IMO the approach to take there
12:42 <@wumpus> luke-jr: that's a different issue
12:42 <@wumpus> luke-jr: let's not blur everything together now jsut because jtimon started off with a whole list...
12:42 <@wumpus> any other topics?
12:43 < gmaxwell> yea.. I want to talk about the impersonation issues and comms stuff for a moment.
12:43 < jnewbery> I don't think that #10996 (per network configuration) and #10267 (additional config file) should be held up on #8994 (custom chains)
12:43 <@wumpus> jnewbery: no, I don't think so either
12:43 <@wumpus> #topic impersonation issues and comms stuff
12:43 < gmaxwell> Kind of OT for the normal material here; but everyone should be aware that the developer of S2X is going around
12:43 < gmaxwell> spreading misinformation about S2X describing it as a harmless "upgrade" to bitcoin, misstating that things like
12:43 < gmaxwell> classic and BU are compatible (though they don't even implement segwit), and not making any mention of the serious
12:43 < gmaxwell> issues like its lack of replay protection, no HF bit, lack of a spec, this is especially bad because there have
12:43 < gmaxwell> been a bunch of efforts to impersonate our project supporting this stuff:
12:43 < gmaxwell> https://twitter.com/bcoreproject/status/897966294083018760 (click internal link for the S2X stuff)
12:44 < gmaxwell> I'm not sure of what to do but it appears to be a widescale effort to misinform people. :(
12:44 < gmaxwell> In the past twitter hasn't done much with people impersonating me, and this is happening on more than twitter.
12:44 < sipa> :(     
12:44 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has quit [Ping timeout: 240 seconds]     
12:44 <@wumpus> yea :/
12:44 < BlueMatt> I'm not sure what can be done about it, sadly, either, aside from everyone spending some time vigorously condemning such blatant fraud and reaching out to corners of the community to point this out
12:44 < gmaxwell> E.g. seen it on reddit and hacker news; and our community links people to https://en.bitcoin.it/wiki/Segwit_support but then gets trolls responding that its "fake" and "censored by theymos"
12:44 < achow101> for twitter impersonation, you can report it to twitter and they might do something about it
12:45 < luke-jr> maybe a bitcoincore.org blog explicitly rejecting 2X and warning people of the misinformation campaigns?
12:45 <@wumpus> right, I'm not sure what recourse there is, fake news everywhere on the internet
12:45 < gmaxwell> achow101: I've heard that several project contributors have; so sure; but I wouldn't expect much.
12:45 < praxeology> gmaxwell: I saw in #bitcoin someone was saying that bitpay was linking to use btc1 https://blog.bitpay.com/bitcore-segwit-activation/  with "bitcore"
12:45 <@wumpus> yes certainly report to sites where the impersonation is hosted
12:45 < BlueMatt> luke-jr: if carefully worded, seems fine
12:45 <@wumpus> github is quite active with that at least
12:45 <@wumpus> twitter usually ignores report unless a lot of people report
12:46 < gmaxwell> Right we may need to each be more outspoken personally, and perhaps organize some project things too. 
12:46 < achow101> I like luke-jr's idea. having something explicitly rejecting s2x would be good
12:46 < Murch> I had already reported that account last week, I suggest that others which use twitter do so as well.
12:46 < jtimon> jnewbery: agreed, nor the other way around imo
12:46  * luke-jr notes he personally calls it simply "2X" because he doesn't want to give the impression Segwit is connected to it.
12:47 < gmaxwell> luke-jr: I've used S2X, but yea people are confused thinking 2X = 2MB  not 4MB (8peak) and other crazy stuff.
12:47 < gmaxwell> or thinking that segwit activation means s2x activation.
12:48 <@wumpus> luke-jr: yes, I think an explicit post rejecting s2x would be a good idea
12:48 < praxeology> didn't help that the slashdot article was wrong, portraying it bcash vs segwit2x
12:48 < gmaxwell> I looked a week or two ago and there were under two dozen btc1 nodes after excluding VPSes and only something like 60 including. Non-entity on the network.
12:49 < gmaxwell> ironically, BCash seems the more honest and responsible of the two.
12:49 < Murch> gmaxwell: And no development activity since "rc2"
12:49 < achow101> gmaxwell: unfortunately their doing basically a misinformation campaign to get more people to run btc1
12:49 < achow101> e.g. bitpay telling people to use btc1 for segwit
12:49 < BlueMatt> ok, so objections to luke-jr's proposal to put something on bitcoincore.org that simply points out that s2x is unrelated to segwit, and a fork of bitcoin, not a "harmless upgrade"?
12:49 < gmaxwell> In any case, we're not going to solve it here, but I think we each can make little pushes to better inform people.
12:49 < BlueMatt> simple faq/error correction, not political "fuck this thing"
12:50 < gmaxwell> BlueMatt: would depend on the text! someone could propose some, maybe harding.
12:50 < luke-jr> I'll throw up a draft GDoc people can hack at after the meeting?
12:50 < BlueMatt> gmaxwell: yes, of course
12:50 < gmaxwell> We can also talk to the bitcoin.org folks in general.
12:51 < gmaxwell> luke-jr: It might be a streach for your approach to get something the rest of the contributors would find super agreeable.
12:51 < praxeology> How close is bitcoin.org w/ the core dev team?  Who runs it?
12:51 < gmaxwell> luke-jr: I think you do well staking out your own more extreme position and adding to the discussion that way, though-- so no offense intended.
12:51 < Chris_St1> maybe bitcoin.org people can throw up a warning about people promoting consensus imcompatible implementations  
12:51 < gmaxwell> praxeology: it's run by the bitcoin.org people. They're generally reasonable folks.
12:51 < BlueMatt> praxeology: not at all, but we can at least contact them or open github issues since they do put the source on github
12:51 < cfields> i think it's important that we point out that this isn't some NIH issue or aversion to change, rather a reaction to a fork that has not only ignored what we've learned from the recent split, but even manages to regress from it
12:51 < luke-jr> gmaxwell: maybe someone else can write a draft then?
12:52 < luke-jr> what I wrote so far: https://docs.google.com/document/d/1D5wYL8mYTfswE94lzIe1RwdDP_rETpgXSWdkMUcpt1A/edit?usp=sharing
12:52 < sipa> cfields: indeed
12:52 < Murch> BlueMatt: Factual statement that the two are unrelated and perhaps a mention of the lack in replay protection
12:53 < gmaxwell> cfields: yes, indeed, in the few places where he even responded to concerns it was to claim things were non-issues with bcash when they actually were, and when bcash's better decisions were highly protective.
12:53 < BlueMatt> yea, that seems reasonable, just "hey, this is unrelated to Bitcoin Core or Bitcoin, really, they are playing a very, very risky game and most folks dont condone this"
12:54 < gmaxwell> In any case, beyond some factual statement... part of the consequence of having the project itself speak less is that each of us in the community sometimes needs to speak more. Otherwise the vacuum is easily filled with fakes and lies.
12:54 < gmaxwell> I dunno if everyone has seen morcos' blog posts but they've been fantastic.
12:54 <@wumpus> gmaxwell: can you link them please?
12:54 <@wumpus> (for the sake of the meeting log)
12:54 < gmaxwell> BlueMatt: even just many rather than most (while I don't doubt most is also true, a narrower thing can be said)
12:54 < BlueMatt> fair
12:55 < Murch> BlueMatt: Yeah, Replay Protection might be a bit over the head for the general audience. It should be mentioned though that it is unrelated to and _not supported by Bitcoin Core_.
12:55 < sipa> https://medium.com/@morcos/no2x-bad-governance-model-97b8e521e751 https://medium.com/@morcos/no2x-centralized-services-539e3b1b56c9 https://medium.com/@morcos/no2x-full-nodes-889c20100a8d 
12:55 < BlueMatt> yea, ^ those are great!
12:56 <@wumpus> #link https://medium.com/@morcos/no2x-bad-governance-model-97b8e521e751
12:56 <@wumpus> #link  https://medium.com/@morcos/no2x-centralized-services-539e3b1b56c9 
12:56 < luke-jr> some open source projects just do blog aggregation
12:56 <@wumpus> #link https://medium.com/@morcos/no2x-full-nodes-889c20100a8d 
12:56 < gmaxwell> it's a fine line to walk, to express the gist without seeming like there isn't substance or alternatively dropping people into the weeds.
12:57 < gmaxwell> luke-jr: I'm generally glad that we don't, in that joe-blow who just doesn't get open projects and is looking for an authority won't understand that a blog aggregation isn't an official position.
12:57 < Murch> luke-jr: That's why I'm putting it so carefully: "not supported" is easily true. Stating that there is no Core contributors that do support it, is probably hard to check and easily false.
12:57 < bitcoin-git> [bitcoin] jonasschnelli opened pull request #11081: Add length check for CExtKey deserialization (master...2017/08/fix_cextkey) https://github.com/bitcoin/bitcoin/pull/11081
12:57 <@wumpus> luke-jr: yes, something like https://planet.freedesktop.org/ would be nice, though on the other hand for bitcoin that would result in endless political discussions about who to include and who not
12:57 < gmaxwell> In any case, even if you don't have the energy or skills to write your own statements, if you agree with stuff like morcos' you can still link to it and let others know you support it.
12:57 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
12:57 < gmaxwell> luke-jr: aka bitcoin press center.
12:57 < BlueMatt> wumpus: I think we should include Mr Buckethead! I find his points on Brexit to be rather well-informed.
12:57 < luke-jr> :x     
12:58 < luke-jr> gmaxwell: some people don't know to follow individual developers, though
12:58 < sipa> BlueMatt: *Lord* Buckethead please
12:58 <@wumpus> lol BlueMatt
12:58 < BlueMatt> sipa: oops, sorry
12:59 < Murch> luke-jr: That's why a statement coming from Core would be useful. Especially since Core as an entity doesn't usually have a position.
12:59 < BlueMatt> if folks agree, @bitcoincoreorg could also r/t morcos' blog posts
12:59 <@wumpus> @btcdrak
13:00 <@wumpus> #endmeeting
13:00 < lightningbot> Meeting ended Thu Aug 17 20:00:03 2017 UTC.  Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
13:00 < lightningbot> Minutes:        http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-17-19.00.html
13:00 < lightningbot> Minutes (text): http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-17-19.00.txt
13:00 < lightningbot> Log:            http://www.erisian.com.au/meetbot/bitcoin-core-dev/2017/bitcoin-core-dev.2017-08-17-19.00.log.html
13:00 < gmaxwell> BlueMatt: I think it would be good, can be done in a way that it's clearly not project stuff.
13:00 < BlueMatt> yea, i mean just r/t would still show it as a tweet from morcos
13:00 < Murch> BlueMatt: Still would be considered an endorsement
13:01 < BlueMatt> Murch: yes, it would be
13:01 < BlueMatt> thats on purpose
13:01 < BlueMatt> hence my question :)
13:01 < instagibbs> Quote Tweet to make it more obvious :P
13:01 -!- Char0n [~Char0n@unaffiliated/char0n] has quit [Quit: ZNC 1.6.3+deb1+xenial0 - http://znc.in]     
13:01 -!- Char0n [~Char0n@unaffiliated/char0n] has joined #bitcoin-core-dev     
13:01 < luke-jr> not everyone reads Twitter either
13:01 < Murch> I think that the position is pretty broadly held here, but if someone disagrees with it, I'm not sure they'd want to speak up.
13:01 < gmaxwell> Murch: somewhat, and a failure to counter is implicitly an endorcement of things like https://twitter.com/bcoreproject/status/897966294083018760
13:02 < luke-jr> the vaccine to misinformation is truth
13:02 < instagibbs> Merely informing users that it's "not just an upgrade" cannot be controversial to anyone on the project
13:02 < gmaxwell> Murch: well they should, cause otherwise no one is gonna know.
13:02 < Murch> gmaxwell: That needs a response from the actual Bitcoin Core twitter account to condemn it as false flag.
13:03 < jnewbery> Murch - I agree. Have misgivings about "Bitcoin Core" endorsing a personal opinion
13:03 < gmaxwell> yes, we can condemn the impersonation (that isn't the only one, also)
13:03 < Murch> luke-jr: It'll get linked on reddit in no time. And I'm sure that BCT also would get some discussion on something like that.
13:03 < luke-jr> "Of the 25 Bitcoin Core developers who have stated a position on 2X, all of them are opposed."
13:03 < luke-jr> Murch: bitcoincore.org is important IMO
13:03 < Murch> luke-jr: Yeah, that's better.
13:03 < instagibbs> the impersonation is break of ToS 
13:04 < luke-jr> so should I junk https://docs.google.com/document/d/1D5wYL8mYTfswE94lzIe1RwdDP_rETpgXSWdkMUcpt1A/edit?usp=sharing ?
13:04 < instagibbs> hmm I need a "company email" to report theft of brand
13:05 < BlueMatt> instagibbs: I just made it up, they'll figure it out that its not a "company", its an organization
13:05 < achow101> instagibbs: it's only impersonation if they don't state that they are a parody account
13:05 < instagibbs> achow101, they do not, at least in profile
13:05 < achow101> so what usually happens is that they put "parody" in the profile somewhere, and no one actually notices that
13:05 < gmaxwell> to be clear, if the S2X posts were "This is a thing we're doing, it's controversial, but we think it's right. Here are the risks and protective steps"  I'd disagree but have little to complain about.   But the burying the risks, describing it as an upgrade,  dovetails perfectly with the troll false flags to pretend that the authors of most of the software they're shipping supports it... it's fra
13:05 < instagibbs> that's fine, but they aren't hence ToS :)
13:05 < gmaxwell> ud.     
13:06 < BlueMatt> jnewbery: I'm with gmaxwell, while its always bad to endorse a personal opinion, as far as I know every major and even the vast majority of minor contributors support that view, at which point if you want the org to not endorse it, you should speak up
13:07 < gmaxwell> I think we can make things clear that they're personal opinions.  Yes, it's something thats fraught with problems. But other than the meta issues, is there anyone who actually disagrees with Morcos on the whole whos a regular contributor, much less disagrees with sharing it?  I think the answer is no.
13:07 < luke-jr> I think we're fine endorsing a "personal opinion" in cases where as-far-as-we-know all developers are of the same opinion..
13:07 < gmaxwell> We do have to make a balance, and I think the sucess of the misinformation has been high enough to indicate that we're strking the balance a little too far to one sid.
13:07 < BlueMatt> can also just quote tweet and say like "Some thoughts on 2x, from a major contributor to Bitcoin Core"
13:08 < jnewbery> ok, I'll speak up. I think there's a difference between condemning impersonation and misinformation (which we should definitely do) and endorsing someone's opionion (which is a road I think we shouldn't go down)
13:08 < jnewbery> BlueMatt - I think that's better
13:08 < gmaxwell> luke-jr: well I'm sure we don't all agree with every last detail of morcos' post.. but broadly. certantly the wiki page and 1:1 discussions support that generally.
13:08 < jnewbery> slightly better
13:08 < gmaxwell> yea, I don't think we should endorse it, but increase visiblity of it.
13:09 < praxeology> Maybe there should be discussion or a link to discussion about core's opinion/roadmap on block size increases?
13:09 < gmaxwell> Because otherwise opponents will flood with disinfo, and pay to advertise it, and thats all people will see.
13:09 < BlueMatt> jnewbery: heh, that wasnt my point, I asked if people disagreed with the views stated, not disagreed with the concept of endorsing a personal opion....at some point if everyone agrees its no longer a "personal opinion"
13:09 < instagibbs> praxeology, already on mailing list, fwiw, search for Paul... Sz... whatever :)
13:10 < gmaxwell> BlueMatt: I think the objective should be to increase the quality of the public discussion. Getting more people morcos' links would objectively do that, even if there was some disagreement about them, it's even more obviously a win because there doesn't appear to be.
13:10 < BlueMatt> anyway, quoting it and pointing out that its a personal opinion is a lower bar, and ~as effective
13:10 < BlueMatt> so whatever
13:11 < gmaxwell> in any case, I've also heard from several community members that it would help them if we helped shut down some of this misinformation.
13:11 < cfields> jnewbery: agreed. you don't even have to take a position on the matter to call out shadyness. I like to think we'd equally call out a large campaign claiming something stupid like "0.15 solves the scaling issue, update immediately!"
13:12 < gmaxwell> cfields: indeed, and I've done that on prior releases (called out people who overstated their gains)
13:12 < jnewbery> to be clear, I'm not disputing the quality of morcos's posts, and I personally agree with them, but I find the idea of 'Bitcoin Core thinks <x>' objectionable
13:12 < jnewbery> cfields - yes. Absolutely no issue with calling out shadiness
13:12 -!- Chris_St1 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
13:12 < luke-jr> long term I think we should link blogs with only agreement from maybe 2 or 3 devs, but have a clear notice at the top saying "x, y, z agree; a, b, c don't agree; e, f, g think this is interesting, but don't necessarily agree or disagree" :P  this would get info out there better, and make it more obvious that Core is just an open source project, not a formal top-down group
13:13 < gmaxwell> jnewbery: yes, I think we want to avoid that.
13:13 < gmaxwell> jnewbery: but we can pass on some links while saying that they're worth a read without stating it as a position.
13:14 < jnewbery> Perhaps. I'm not going to NACK, and I think I've made my point that we need to be careful with tone
13:14 < gmaxwell> All our efforts to do the right thing don't matter if we let less ethical people bury us.  I don't think we should adopt those techniques, but we do need to act with the full range and power of what we can agree is acceptable.
13:15 < instagibbs> could we also try to get a blue checkmark for the twitter account?
13:15 < instagibbs> (heard it's a PITA)
13:15 < gmaxwell> jnewbery: btcdrak would probably write it, I'll suggest he also consult with you on the presentation. I think your point is perfectly reasonable.
13:15 -!- protomar [~protomar@109.232.227.133] has joined #bitcoin-core-dev     
13:17 < praxeology> I disagree with luke's suggested rename to "2X".  Ideally we could get the whole bitcoin/altcoin community to change the name, but its too late now, should just stick w/ what everyone is familiar with
13:21 <@wumpus> another openbsd issue I can't reproduce https://github.com/bitcoin/bitcoin/issues/11063, seems to work fine here
13:21 < Murch> luke-jr: I've added a suggestion to the bottom of your gdoc.
13:22 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
13:22 < Murch> BlueMatt: What do you think? https://docs.google.com/document/d/1D5wYL8mYTfswE94lzIe1RwdDP_rETpgXSWdkMUcpt1A/edit
13:23 < BlueMatt> lol, we said non-political statement...."altcoin"
13:24 < Murch> BlueMatt: I've added the sentences below the line
13:24 < BlueMatt> yea, ok, the version below the line is actually a decent start
13:26 < Murch> BlueMatt: Good changes if that is you. ;)
13:30 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
13:30 < luke-jr> BlueMatt: "altcoin" is objective fact, not political..
13:30 < luke-jr> praxeology: everyone is familiar with "2X"
13:32 < Murch> luke-jr: "Altcoin" is also needlessly polarizing.
13:33 < luke-jr> Murch: I don't see how.
13:33 < BlueMatt> luke-jr: feel free to replace the original text with the stuff below the line
13:33 < luke-jr> Murch: it's a neutral term, I'm not sure how to make it any better
13:34 < BlueMatt> luke-jr: its politically polarizing, whether you intend it to be or not
13:35 < Murch> luke-jr: It's a technical term but often used to disparage other projects. It would just be an unnecessary affront to users that actually like some of those projects.
13:35 < BlueMatt> fork'd https://docs.google.com/document/d/1y6Hsqdg1xBrJY4dFeKP6y05XCceJoVMs0_M_VwKFReM
13:35  * luke-jr wonders how to decide when to accept suggested changes
13:39 < Murch> The google doc has hardforked :p
13:39  * Murch needs to get back to work
13:41 < jnewbery> I've added my suggested wording to the doc (under =====)
13:42 < luke-jr> jnewbery: it seems to fail to address the main misinformation (that they are misrepresenting an altcoin as an upgrade to Bitcoin)
13:43 < luke-jr> (or worse, does so by implying Bitcoin Core is Bitcoin!)
13:43 -!- mxg [6881c240@gateway/web/freenode/ip.104.129.194.64] has joined #bitcoin-core-dev     
13:44 -!- mxg [6881c240@gateway/web/freenode/ip.104.129.194.64] has left #bitcoin-core-dev []     
13:50 < sturles> btc1 calls their node software Bitcoin Core as well.
13:50 <@wumpus> great, as if we didn't have enough confusion
13:51 < Murch> as usual with forks, both edit chains live and thrive. ;)
13:51 < Murch> There is some replay attacks going on though ;)
13:51 <@wumpus> we should have trademarked the name...
13:52 < Murch> ah, I thought you meant the two google docs
13:52 < luke-jr> wumpus: trademarks don't require registration
13:52 < luke-jr> at least in the US
13:52 <@wumpus> impersonating software projects isn't cool
13:52 < luke-jr> (BTW, if anyone wants direct edit/approval access to the GDoc, PM me your GDocs email)
13:52 <@wumpus> it's close to what many malware does
13:53 < luke-jr> wumpus: we could probably sue them and win if they're actually doing that, but who wants to deal with the lawyers? :p
13:53 <@wumpus> luke-jr: good point...
13:54 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
14:00 -!- protomar [~protomar@109.232.227.133] has quit [Quit: Leaving]     
14:06 -!- pandabull [~pandabull@2603:3005:715:c400:6c64:e924:34a0:346] has joined #bitcoin-core-dev     
14:07 -!- pandabull [~pandabull@2603:3005:715:c400:6c64:e924:34a0:346] has quit [Client Quit]     
14:08 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has quit [Quit: conversation terminated!]     
14:11 -!- Chris_St1 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
14:12 -!- cryptapus [~cryptapus@unaffiliated/cryptapus] has joined #bitcoin-core-dev     
14:17 -!- Chris_St1 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 248 seconds]     
14:32 -!- Chris_St1 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
14:40 < jimpo> cfields: Is there a reason that the "send rejects" part of SendRejectsAndCheckBanned should be called at the end of ProcessMessages as introduced in https://github.com/bitcoin/bitcoin/pull/9720?
14:41 < jimpo> Said otherwise, is it safe to split into SendRejects and separately CheckIfBanned and only call CheckIfBanned there?
14:46 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 276 seconds]     
14:48 < BlueMatt> jimpo: the reason is to (try, there are no guarnatees) to get reject messages out to the peer that we're about to disconnect
14:49 < BlueMatt> eg an "I banned you because" message
14:50 < praxeology> Maybe... the people who would be duped into downloading/installing btc1... haven't even/don't/won't install Bitcoin Core in the first place.  So that set of people is probably pretty small, like maybe 0 people?
14:53 < gmaxwell> praxeology: it would be true except they are advertising it as how to upgrade for segwit. Even though 90%+ of the network is already upgraded for segwit.
14:54 < morcos> karelb: re: estimate fee.. emphasis was on _slight_ differences..  I think you should upgrade to use estimatesmartfee, but if you do nothing, i don't think the world will end.  you'll probably be ok
14:56 < karelb> thx. I am already looking forward to it
14:56 < cfields> jimpo: what he said.
14:57 < jimpo> thx     
14:58 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
14:58 < cfields> jimpo: iirc i explained in pretty good detail in the commit message/pr for that change. You might want to have a quick look if you haven't already
14:59 -!- murr5y [ali@100.94.211.130.bc.googleusercontent.com] has quit [Quit: WeeChat 1.6]     
14:59 -!- murr4y [ali@100.94.211.130.bc.googleusercontent.com] has joined #bitcoin-core-dev     
15:06 -!- str4d [~str4d@host86-172-94-20.range86-172.btcentralplus.com] has joined #bitcoin-core-dev     
15:06 < jimpo> Thanks, the commit messages are very helpful. I understand why the call was added at the end of ProcessMessages, but why is it called again in SendMessages?
15:09 < karelb> morcos: I asked P2SH.info guy if he wants to update this - https://p2sh.info/dashboard/db/fee-estimation - to include the new estimatesmartfee
15:09 < karelb> I am interested in the graph
15:10 < karelb> on the bottom left you see the various estimators compared
15:10 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
15:12 < BlueMatt> jimpo: SendMessages is confusingly named, it really should be PeerProcessingTimerFunction
15:13 < BlueMatt> and, eg, block reject messages may be generated async
15:13 < BlueMatt> (and also dos points based on the same blocks)
15:14 < jimpo> OK, thx
15:15 < morcos> Just caught up on backlog, for the record, I was already asked about bitcoincoreorg retweeting or pointing to my medium posts and i was fairly strongly opposed
15:15 < BlueMatt> morcos: even in a "this is someone's view, but its informative" quote?
15:15 < morcos> I agree with jnewbery , I don't think we can all agree on what Core's opinions are, so we should steer very far away from core having opinions
15:15 < morcos> BlueMatt: yes, there is no reason that needs to come from core
15:16 < BlueMatt> morcos: see greg's comments - people are claiming to "be" bitcoin core saying otherwise
15:16 < morcos> you can retweet it (you probably did) and any one else can, but i think the official core communication should stay away from that
15:16 < BlueMatt> i did
15:17 < morcos> i haven't read the text yet about an announcement regarding 2x, but i think that makes a lot more sense to factually let people know what the Core project will be supporting in terms of rules
15:17 < instagibbs> i think there's the two issues: 1) claiming to be core 2) claiming to offer bitcoin upgrades
15:17 < morcos> But again we need to be quite careful with tone, to not judge what others are saying too much
15:17 < gmaxwell> then in our efforts to be so holy we'll suffer failures at the hands of people with no scruples, because when we don't speak they'll speak for us and use our names.
15:17 < morcos> instagibbs: re: upgrades, i think better than disputing their description is to just provide our own factual description
15:18 < morcos> people can individually condemn the "upgrade" nomenclature if they choose
15:18 < morcos> gmaxwell: i'd rather do that than stoop to their level
15:18 < morcos> certainly we can point out that people using similar names are not us and don't represent our views
15:19 < bitcoin-git> [bitcoin] luke-jr opened pull request #11082: Add new bitcoin_rw.conf file that is used for settings modified by this software itself (master...rwconf) https://github.com/bitcoin/bitcoin/pull/11082
15:20 < instagibbs> +1     
15:20 < gmaxwell> morcos: there aren't just those two choices though.
15:21 < gmaxwell> (also, "here is a really interesting view you should read and consider" is not morally equivilent to /pretending to be us/ or faking that s2x is just an uncontroversial and low risk bitcoin upgrade...)
15:22 < BlueMatt> ^ that
15:22 < BlueMatt> I mean can you seriously claim that almost the entirety of your rather short blog posts is disagreed with by almost any contributor to bitcoin core
15:23 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
15:25 -!- BashCo [~BashCo@unaffiliated/bashco] has quit []     
15:25 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
15:26 < gmaxwell> We shouldn't make the mistake of being naieve that thinking that being right is sufficent against opponents who will do whatever it takes.  That doesn't mean that I think we need to stoop to their level in any way.  I think you could potentially extend your argument about speaking for others against writing your post in the first place.
15:26 < bitcoin-git> [bitcoin] runn1ng closed pull request #10370: [pull request idea] addressindex, spentindex, timestampindex (Bitcore patches) (master...rebase_bitcoin_master) https://github.com/bitcoin/bitcoin/pull/10370
15:26 -!- Guyver2 [~Guyver@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
15:26 < gmaxwell> Surely even if we do not tweet it, some people will see it and think it speaks for the project.  Not many, nor would it be a reasonable conclusion to jump to.. but some will.
15:27 -!- vicenteH [~user@13.232.15.37.dynamic.jazztel.es] has quit [Ping timeout: 240 seconds]     
15:29 < BlueMatt> anyway, so thoughts on the current proposed doc? https://docs.google.com/document/d/1y6Hsqdg1xBrJY4dFeKP6y05XCceJoVMs0_M_VwKFReM/edit
15:29 < BlueMatt> (and the pending edits to it)
15:35 -!- promag [~Adium@128.28.43.5.rev.vodafone.pt] has joined #bitcoin-core-dev     
15:36 < morcos> I had one objection, i commented, but overall i think its quite good
15:37 < morcos> gmaxwell: yes its enough of a problem that people might mistake my posts as representing the project, thats why its important for the project to not tweet them
15:37 -!- davec [~davec@cpe-24-243-249-218.hot.res.rr.com] has joined #bitcoin-core-dev     
15:37 < morcos> they don't, i'm glad a lot of you guys like them.. but it would also be fine if you disagreed.
15:38 < gmaxwell> in this climate I hope we'd also consider tweeting it if we didn't agree but thought it was a useful contribution to the discussion.
15:38 < gmaxwell> In any case, lets talk about what the people suggesting this hope to achieve.
15:39 < gmaxwell> I want people to not be getting only the distorted s2x version of the world shoved down their throats, and know that many people have a dissenting view.
15:40 < gmaxwell> And in particular, the people that the users of bitcoin are generally reseting a fair amount of trust to create and maintain the software the network is using, for the most part (or completely though we can't be sure) don't agree with the narative they're being sold.
15:43 -!- Giszmo [~leo@ppp-88-217-118-128.dynamic.mnet-online.de] has joined #bitcoin-core-dev     
15:48 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
15:49 < morcos> I'm going to be mostly afk for rest of today, but will check back in.  I think we should let this proposed blog post sit for a while after we get the wording nailed down and just make sure contributors to the project are ok with it
15:52 -!- Chris_St1 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds]     
16:03 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds]     
16:06 -!- Chris_St1 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
16:16 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
16:20 < sipa> Receiving objects: 100% (98150/98150), 83.68 MiB | 3.68 MiB/s, done.
16:21 < sipa> i find it amazing that all of bitcoin core's history, is less than 100 MB
16:30 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has quit [Ping timeout: 248 seconds]     
16:59 -!- MeshNet2 [5896e622@gateway/web/cgi-irc/kiwiirc.com/ip.88.150.230.34] has joined #bitcoin-core-dev     
17:00 < gmaxwell> thats a lot, time for a reback.
17:00 < gmaxwell> repack.
17:00 < kanzure> also other unmerged branches though
17:00 < kanzure> sipa might even have elements.git branches in there
17:02 < sipa> no     
17:03 < kanzure> welp.
17:10 < luke-jr> cfields: it occurs to me the reason the dir is dirty, is because it's missing files; so if we want to defer doing a real fix, we can alternatively fix the missing-files issue instead, by generating the tarball from git-archive
17:20 -!- Chris_St1 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
17:25 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Plugging out.]     
17:26 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has joined #bitcoin-core-dev     
17:29 < cfields> luke-jr: I believe the dir is dirty because we extract the tarball into it
17:31 < luke-jr> that doesn't make sense..
17:40 -!- MeshNet2 [5896e622@gateway/web/cgi-irc/kiwiirc.com/ip.88.150.230.34] has quit [Quit: http://www.kiwiirc.com/ - A hand crafted IRC client]     
17:41 -!- Cryptocide [~Cryptocid@h88-150-230-34.host.redstation.co.uk] has joined #bitcoin-core-dev     
17:42 -!- JackH [~laptop@2a02:a210:2e00:300:655a:7cbf:d627:81fb] has quit [Ping timeout: 255 seconds]     
17:46 -!- rockhouse [~rockhouse@unaffiliated/rockhouse] has quit [Ping timeout: 240 seconds]     
17:53 -!- laurentmt [~Thunderbi@115.31.156.105] has joined #bitcoin-core-dev     
17:55 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
17:56 < praxeology> https://medium.com/@DCGco/bitcoin-scaling-agreement-at-consensus-2017-133521fe9a77 
17:56 < praxeology> sorry my 2yo grabbed my mouse
17:57 -!- str4d [~str4d@host86-172-94-20.range86-172.btcentralplus.com] has quit [Ping timeout: 240 seconds]     
17:57 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit []     
18:08 < cfields> luke-jr: I see what you mean
18:08 < promag> praxeology: I feel you too
18:11 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]     
18:16 < Cryptocide> Abra|BitClub Network|Bitcoin.com|BitFury|BitGo|Bitmain|BitPay Blockchain|Bloq|BTCC|Circle|Ledger|RSK Labs|Xapo, no thanks
18:17 < kanzure> why XORing them? i don't get it.
18:17 < kanzure> er, ORing
18:18 < kanzure> yes. anyway.
18:18 -!- promag [~Adium@128.28.43.5.rev.vodafone.pt] has quit [Quit: Leaving.]     
18:20 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
18:22 -!- Mattie161 [~matt@195.162.102.18] has quit [Ping timeout: 240 seconds]     
18:23 -!- Mattie161 [~matt@195.162.102.18] has joined #bitcoin-core-dev     
18:23 -!- niska [~niska@68.ip-149-56-14.net] has quit [Quit: Leaving]     
18:24 -!- Cheeseo [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
18:24 -!- niska [~niska@68.ip-149-56-14.net] has joined #bitcoin-core-dev     
18:30 -!- laurentmt [~Thunderbi@115.31.156.105] has quit [Quit: laurentmt]     
18:30 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
18:33 -!- cheese_ [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
18:33 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
18:35 -!- RoyceX [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
18:35 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has joined #bitcoin-core-dev     
18:39 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Ping timeout: 240 seconds]     
18:40 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-flobmvxoetgoeynj] has quit [Ping timeout: 276 seconds]     
18:42 -!- mariorz [sid490@gateway/web/irccloud.com/x-byaznygmpajbwomp] has quit [Ping timeout: 276 seconds]     
18:42 < kallewoof> I'm running a modified Bitcoin Core node to do some profiling on where resources are spent (CPU cycles and bandwidth in particular) and am seeing some really weird stuff. E.g:
18:42 < kallewoof>  0.77877            27892        282511326         24083459                0 131703419 SendMessages.inventory.trickle (tx-relay).LOCK(cs)
18:43 < kallewoof> The columns are "portion of CPU used", "min CPU cycles", "max CPU cycles", "medium CPU cycles per call", "bandwidth per call", "# of calls", "code path"
18:44 < kallewoof> So the LOCK(cs) in SendMessages for inventory for trickle for the tx relay part is taking 78% of all CPU cycles for my node. Does that seem normal?
18:44 -!- mariorz [sid490@gateway/web/irccloud.com/x-jnvzwgucbreolzqr] has joined #bitcoin-core-dev     
18:45 < kallewoof> Also baffled by the number of calls. 131 million. I started profiling yesterday.
18:49 < kallewoof> This is probably from the mempool.info(hash) call in the while loop btw. That probably explains the high # of calls, but 131 million in 24 hours is 1500/second. Maybe my profiling code is broken.
18:51 < kallewoof> ... Actually, it rose by 38k from 01:48:49 to 01:50:00, so doesn't seem improbable.
19:23 < gmaxwell> sometimes profiling is confused by locks. (and/or moderately condented locks in an otherwise inactive process can be a high percentage due to spinning).
19:23 < gmaxwell> Sounds like it might be interesting.
19:23 < praxeology> Re: https://docs.google.com/document/d/1y6Hsqdg1xBrJY4dFeKP6y05XCceJoVMs0_M_VwKFReM/edit  Maybe it would be a good idea to communicate with the exchanges and check and see who will continue to support Bitcoin Core's chain
19:23 < gmaxwell> Everyone okay with me doing a presentation on 0.15 improvements to a local group in 1.5 weeks?
19:25 -!- cheese_ [~Cheeseo@gateway/vpn/privateinternetaccess/cheeseo] has quit [Ping timeout: 240 seconds]     
19:26 < praxeology> Like... I know that BitPay and Coinbase are declaring that they will support Segwit2x... has any exchange declared that they will continue to support Bitcoin (Bitcoin Core's rules)?
19:27 < kallewoof> gmaxwell: there is some amount of overhead as I am doing the profiling on my own. Maybe that's the cause for the high portion of time spent there, but it still seems like a lot of LOCK calls, regardless of actual CPU cycle count. Would be cool if the mempool could be copied once and then not lock cs at all. Code is here btw: https://github.com/kallewoof/bitcoin/tree/profile-resources
19:28 < sipa> copying the whole mempool?
19:28 < kallewoof> Only the hashes.
19:28 < sipa> oh     
19:29 < kallewoof> Actually that wouldn't work. It uses txinfo for feeRate and tx etc.
19:29 < praxeology> kallewoof: does your bitcoin process have enough memory to hold the entire chainstate?
19:30 < praxeology> err, what -dbcache are you using?
19:30 < kallewoof> it has 16 GB of RAM. 223 MB free atm.
19:30 < kallewoof> Default
19:30 < kallewoof> (dbcache)
19:31 < praxeology> are you profiling while synching from genesis, or from the latest tip, or what?
19:31 < sipa> praxeology: he's talking about inv relay
19:31 < sipa> not about sync
19:31 < kallewoof> The node is fully synced up. I restarted it with profiling enabled so it's from tip
19:33 < bitcoin-git> [bitcoin] jonasnick opened pull request #11083: Fix combinerawtransaction RPC help result section (master...fix-combinerawtransaction-help) https://github.com/bitcoin/bitcoin/pull/11083
19:35 < praxeology> kallewoof: is your profiler sampling instruction pointer positions, or is it timing each function call?
19:37 < kallewoof> It's using rdtsc. Not sure which that falls under.
19:37 < praxeology> the latter can really mess up measurements
19:38 < praxeology> and potentially the profile is not actually measuring cpu usage... that could be misleading, instead it could just be saying where a thread is sleeping
19:40 < kallewoof> Right. It definitely keeps ticking even while waiting for locks. I was more intereted in the # of LOCK() calls/second rather than the actual CPU usage in this case, though.
19:41 < kallewoof> Since the code is auto-profiling all locks, I can simply reduct the lock times from the parent to get "time spent excluding lock wait times", if that seemed useful.
19:43 < praxeology> is it measuring the number of lock calls? or the number of times it sampled with the thread being at the Lock() call?
19:43 < kallewoof> # of calls
19:47 < praxeology> Does bitcoin's networking code operate on polling or interrupt?
19:47 < kallewoof> I logged every entry into the tx relay loop and logged the size of vInvTx. I don't have a lot of connections yet (14 or so) but I'm seeing 4-5 per second. Example of vInvTx sizes: 5, 0, 5, 0, 4, 4, 5, 1, 0, 1, 5, 1, 2, 0, 26, 6, 5, 0, 5, 5, 0, 5, 0, 2, 2, 13, 52, 0, 0, 0, 4, 4, 11, 21
19:47 -!- Fibonacci [~Jordan@c-73-155-128-180.hsd1.tx.comcast.net] has joined #bitcoin-core-dev     
19:48 < Fibonacci> o/     
19:49 < kallewoof> That doesn't match up with 1500/second at all, but maybe with more connections. Or maybe there was a bunch of txs in the last 24 hours.
19:53 < kallewoof> Actually, for comparison, the path into "trickle (tx-relay)" only has 543732 instances, which would mean there are on average 133867681/543732=246 calls to LOCK(cs) per entry. Huh.
19:56 < cfields> kallewoof: you can use my lock dumper to profile: https://github.com/theuni/bitcoin/commit/be49a294a240ec81a901af1aaabbba2172d38dc1
19:57 < cfields> it should cherry-pick cleanly
19:57 < cfields> lock stats are dumped at shutdown
19:57 < cfields> i should really clean that up and PR it
19:57  * cfields throws it on the pile
19:57 < kallewoof> Nice :)
19:58 < cfields> should tell you how long it's locked, and what percentage of the thread time it spent in it
19:58 < kallewoof> I sort of already know that. What is confusing me is the # of times it is locking.
19:58 < kallewoof> 350 million in <24h is a lot of LOCK()s.
19:58 < cfields> heh     
20:11 -!- Giszmo1 [~leo@ppp-88-217-112-70.dynamic.mnet-online.de] has joined #bitcoin-core-dev     
20:12 -!- Giszmo [~leo@ppp-88-217-118-128.dynamic.mnet-online.de] has quit [Ping timeout: 240 seconds]     
20:27 < Fibonacci> Bitcointalk will soon be irrelevant in the cryptoverse. Alternative methods for coin legitimization are popping up that will more carefully scrutinize developers intentions and identities, while at the same time allowing for an influx of new blood not associated with the corrupt financial institutions. Keep your eyes open for this shifting to a new paradigm 
20:28 < luke-jr> !ops spammer
20:28 < Fibonacci> That wasn't spam Luke-jr
20:28 < luke-jr> sure looks like it.
20:28 < Fibonacci> I typed that myself
20:29 < luke-jr> considering this channel has nothing to do with bitcointalk, altcoins, etc
20:29 < Fibonacci> well I think it's time
20:34 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
20:35 < Cryptocide> People can code whatever they want wherever, and if they have great coding skills they will shine, what is the issue we all agree on this
20:38 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
20:39 -!- hsmiths [uid95325@gateway/web/irccloud.com/x-tzsfdirxrshjzmkq] has joined #bitcoin-core-dev     
20:39 -!- Chris_St1 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
20:46 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has quit [Quit: ZZZzzz…]     
20:48 < kallewoof> Found part of why there are so many locks. It's locking cs twice for every entry in vInvTx, which is anything from a few up to 100+. With 4-5 per sec that adds up fast. The first lock is for the CompareInvMempoolOrder (std::pop_heap call at start of loop), and the second is for the actual mempool.info(hash) call.
20:55 < kallewoof> Actually, since the CompareInvMempoolOrder is a sorter, and each sort calls CompareDepthAndScore which locks cs, the number of lock calls are dependent on the size of the vector. That definitely explains things...
20:57 < kallewoof> I think this could all be solved by making a sub-mempool which takes a list of hashes and simply pulls them out of the mempool once. These operations could then be done on the sub-mempool without locking anything or at least without locking cs.
21:02 -!- fireofearth [~fireofear@S0106a84e3f63be13.vc.shawcable.net] has joined #bitcoin-core-dev     
21:05 -!- Chris_St1 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
21:09 -!- jimpo [~jimpo@ec2-54-175-255-176.compute-1.amazonaws.com] has quit [Ping timeout: 240 seconds]     
21:19 -!- treebear_ [~treebeard@73.109.61.134] has joined #bitcoin-core-dev     
21:20 -!- treebeardd [~treebeard@73.109.61.126] has quit [Ping timeout: 240 seconds]     
21:21 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 246 seconds]     
21:35 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]     
21:38 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
21:42 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]     
21:46 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
21:55 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has quit [Ping timeout: 240 seconds]     
21:58 -!- tripleslash [~triplesla@unaffiliated/imsaguy] has joined #bitcoin-core-dev     
22:02 < kallewoof> Woah.. size of vInvTx after running for a bit (grabbed latest bunch in order): 4596, 4, 0, 7, 2, 8, 3836, 4370, 21, 2, 3, 3806, 1, 5, 4340, 16, 16, 0, 4121, 7, 4478, 11, 16, 0, 4095, 4452, 4264, 5, 9, 6, 1, 4061, 11, 11, 4579, 4544, 7, 10, 1, 1, 0, 4318, 18, 54, 3, 3, 1, 1, 0, 0, 4421, 13. 4+k entries would definitely result in a lot of locking.
22:03 < sipa> kallewoof: wow
22:27 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection]     
22:27 -!- annanay25 [~csbtech@geekon.tech] has joined #bitcoin-core-dev     
22:29 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection]     
22:29 -!- annanay25 [~csbtech@geekon.tech] has joined #bitcoin-core-dev     
22:29 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection]     
22:34 -!- annanay25 [~csbtech@geekon.tech] has joined #bitcoin-core-dev     
22:35 -!- annanay25 [~csbtech@geekon.tech] has quit [Remote host closed the connection]     
22:58 -!- ekerstein [~ekerstein@ip-64-134-180-44.public.wayport.net] has joined #bitcoin-core-dev     
23:00 -!- Deacydal [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
23:03 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has quit [Ping timeout: 240 seconds]     
23:05 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has quit [Ping timeout: 240 seconds]     
23:11 -!- aj_ [aj@cerulean.erisian.com.au] has joined #bitcoin-core-dev     
23:11 -!- aj_ is now known as aj     
23:32 -!- jannes [~jannes@095-097-246-234.static.chello.nl] has joined #bitcoin-core-dev     
23:37 -!- elkalamar [~elkalamar@unaffiliated/elkalamar] has quit [Ping timeout: 255 seconds]     
23:46 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev     
23:50 -!- jtimon [~quassel@143.29.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
23:50 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]     
23:51 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev     
23:55 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Ping timeout: 240 seconds]     
23:59 -!- Dyaheon [~Dya@a91-156-192-39.elisa-laajakaista.fi] has joined #bitcoin-core-dev