--- Day changed Mon Dec 04 2017
00:07 -!- gwillen [~gwillen@unaffiliated/gwillen] has quit [Remote host closed the connection]     
00:07 < eck> fyi if you run configure with --disable-wallet you don't need berkeleydb, which would just leave you to figure out boost
00:14 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
00:16 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
00:18 < achow101> I gave up on valgrind. It was doing the rescanning thing and moving at one percent per hour. I'm going to do the git bisect stuff tomorrow
00:27 < eck> were you using massif or memcheck?
00:27 < achow101> memcheck
00:27 < eck> massif will just straight up tell you at any given point of time, where all the allocations came from
00:28 < eck> which is useful if you can't wait for the program to run to completion
00:28 < eck> iirc it's even slower than memcheck though
00:28 < achow101> the problem was that it wasn't getting passed the init part. the leak is definitely coming from somwehere past the init part
00:30 < eck> i have heard that ASAN is faster than valgrind but i haven't used it
00:30 < eck> http://www.chromium.org/developers/testing/addresssanitizer http://www.chromium.org/developers/testing/leaksanitizer
00:30 < eck> it's built into vlang
00:30 < eck> *clang
00:31 < eck> this is for a rescan?
00:32 < achow101> reindex
00:33 < achow101> the rescan I think is part of the reindex because the reindex was killed before it flushed
00:35 < eck> i might take a look at that this week (if i can reproduce it), i was interested in generally profiling bitocind -reindex using systemtap
00:37 < achow101> made an issue for this #11822
00:37 < gribble> https://github.com/bitcoin/bitcoin/issues/11822 | Severe memory leak on current master · Issue #11822 · bitcoin/bitcoin · GitHub
00:48 -!- noglar_ [~cl0uding@62.43.144.42.dyn.user.ono.com] has quit [Ping timeout: 260 seconds]     
00:59 < Randolf> eck:  Thanks.  There's an incompatibility because I have the wrong version of Boost.
01:00 < eck> it is pretty straightforward to build, if you have the patience
01:01 -!- noglar_ [~cl0uding@62.43.144.42.dyn.user.ono.com] has joined #bitcoin-core-dev     
01:01 < Randolf> eck:  I have plenty of patience, but my problem is meeting other deadlines at the moment so I've put this on hold for now.  I also need to learn more about compiling.
01:07 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:07 -!- timothy [tredaelli@redhat/timothy] has quit [Client Quit]     
01:13 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
01:13 -!- timothy [tredaelli@redhat/timothy] has joined #bitcoin-core-dev     
01:17 < achow101> I fairly quick and rather unscientific git bisect says that e545dedf72bff2bd41c93c93eb576929fce37112 is the commit that introduces the problem.
01:17 < achow101> so if you want to investigate, that commit and commits in its vicinity should be looked at. But I need to sleep, so I'll look at it tomorrow.
01:18 -!- eck [~eck@fsf/member/eck] has quit [Quit: we out here]     
01:18 -!- eck [~eck@fsf/member/eck] has joined #bitcoin-core-dev     
01:18 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
01:29 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
01:34 -!- rtm1046 [~zhangyh@183.160.105.82] has joined #bitcoin-core-dev     
01:35 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
01:38 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has joined #bitcoin-core-dev     
01:53 -!- rtm1046 [~zhangyh@183.160.105.82] has quit [Remote host closed the connection]     
01:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]     
01:55 -!- ufukkilic [~quassel@47.149.153.208] has quit [Read error: Connection reset by peer]     
01:55 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
01:57 -!- go1111111 [~go1111111@199.231.240.191] has quit [Ping timeout: 248 seconds]     
02:01 -!- go1111111 [~go1111111@199.231.240.191] has joined #bitcoin-core-dev     
02:10 -!- warxhead [warxhead@c-73-243-180-191.hsd1.co.comcast.net] has quit []     
02:14 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
02:15 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
02:16 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Ping timeout: 248 seconds]     
02:26 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #bitcoin-core-dev     
02:32 -!- go1111111 [~go1111111@199.231.240.191] has quit [Ping timeout: 260 seconds]     
02:48 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
02:48 -!- mryandao [~mryandao@unaffiliated/mryandao] has quit [Ping timeout: 240 seconds]     
02:48 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
02:50 -!- arubi_ [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
02:50 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
02:54 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
02:55 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:04 -!- mryandao [~mryandao@unaffiliated/mryandao] has joined #bitcoin-core-dev     
03:05 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
03:05 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:06 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
03:07 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
03:08 -!- go1111111 [~go1111111@199.231.240.191] has joined #bitcoin-core-dev     
03:13 -!- go1111111 [~go1111111@199.231.240.191] has quit [Ping timeout: 276 seconds]     
03:14 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
03:16 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #bitcoin-core-dev     
03:17 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 248 seconds]     
03:18 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 255 seconds]     
03:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
03:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
03:29 -!- mmhhtt [5b5d7bc3@gateway/web/freenode/ip.91.93.123.195] has joined #bitcoin-core-dev     
03:31 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
03:31 -!- tiagotrs [~tiago@p5DC47519.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
03:32 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
03:32 < mmhhtt> Hello, Is there anyone knows to how can build a exchange market for other country? Is there any request from bitcoin company to me for making exc market?
03:33 < mmhhtt> also how can work payment for buy/sell btc for other country local money?
03:39 -!- promag [~promag@bl6-24-70.dsl.telepac.pt] has quit [Remote host closed the connection]     
03:43 -!- dqx [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection]     
03:45 -!- go1111111 [~go1111111@gateway/vpn/privateinternetaccess/go1111111] has joined #bitcoin-core-dev     
04:04 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
04:08 -!- str4d [~str4d@183.191.6.51.dyn.plus.net] has quit [Ping timeout: 260 seconds]     
04:13 < sipa> achow101: that's what i feared...
04:14 -!- wxss [~user@87.236.196.99] has joined #bitcoin-core-dev     
04:15 -!- dqx [~dqx@unaffiliated/dqx] has quit [Remote host closed the connection]     
04:16 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
04:22 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 260 seconds]     
04:26 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
04:26 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
04:27 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has quit [Remote host closed the connection]     
04:28 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
04:29 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
04:43 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-bpvmxtpvrnlgfevw] has quit [Quit: Connection closed for inactivity]     
05:10 -!- RK_ [9d25def2@gateway/web/freenode/ip.157.37.222.242] has joined #bitcoin-core-dev     
05:11 < RK_> Hello
05:11 < RK_> I want to know about bitcoin 
05:14 -!- RK_ [9d25def2@gateway/web/freenode/ip.157.37.222.242] has quit [Client Quit]     
05:17 -!- dreamrunner [76b3d702@gateway/web/freenode/ip.118.179.215.2] has joined #bitcoin-core-dev     
05:21 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
05:21 -!- dreamrunner [76b3d702@gateway/web/freenode/ip.118.179.215.2] has quit [Ping timeout: 260 seconds]     
05:21 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
05:23 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
05:25 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Client Quit]     
05:25 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
05:26 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
05:28 < mmhhtt> #bitcoin-core-dev
05:28 < mmhhtt> hello
05:28 < mmhhtt> Is there any one?
05:30 -!- mmhhtt [5b5d7bc3@gateway/web/freenode/ip.91.93.123.195] has quit [Quit: Page closed]     
05:47 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 248 seconds]     
05:49 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has quit [Ping timeout: 248 seconds]     
05:50 -!- dermoth [~dermoth@gateway/tor-sasl/dermoth] has joined #bitcoin-core-dev     
05:51 -!- tiagotrs [~tiago@p5DC47519.dip0.t-ipconnect.de] has quit [Ping timeout: 248 seconds]     
05:52 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
05:54 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
05:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
06:03 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
06:04 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
06:11 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
06:12 -!- Cogito_Ergo_Sum [~Myself@ppp-94-64-159-66.home.otenet.gr] has joined #bitcoin-core-dev     
06:12 -!- Cogito_Ergo_Sum [~Myself@ppp-94-64-159-66.home.otenet.gr] has quit [Changing host]     
06:12 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
06:12 -!- notabot_ [63cb0f04@gateway/web/freenode/ip.99.203.15.4] has joined #bitcoin-core-dev     
06:12 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
06:16 < notabot_> mmhhtt: try #bitcoin channel or reddit
06:17 < notabot_> RK_: bitcoin.org is the best place to start.
06:17 -!- notabot_ [63cb0f04@gateway/web/freenode/ip.99.203.15.4] has quit [Quit: Page closed]     
06:24 -!- Murphy40Hermann [~Murphy40H@ns334669.ip-5-196-64.eu] has joined #bitcoin-core-dev     
06:29 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 240 seconds]     
06:32 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has quit []     
06:32 -!- rafalcpp [~racalcppp@84-10-11-234.static.chello.pl] has joined #bitcoin-core-dev     
06:33 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Ping timeout: 255 seconds]     
06:43 -!- CubicEarth [~cubiceart@81.92.27.129] has joined #bitcoin-core-dev     
06:46 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
06:48 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
06:49 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
06:53 -!- dqx [~dqx@unaffiliated/dqx] has quit [Ping timeout: 240 seconds]     
06:54 -!- CubicEarth [~cubiceart@81.92.27.129] has quit []     
07:02 -!- indistylo [~indistylo@119.82.105.106] has quit [Ping timeout: 276 seconds]     
07:07 -!- dqx [~dqx@unaffiliated/dqx] has joined #bitcoin-core-dev     
07:08 -!- izadev [b36cae60@gateway/web/freenode/ip.179.108.174.96] has joined #bitcoin-core-dev     
07:08 -!- izadev [b36cae60@gateway/web/freenode/ip.179.108.174.96] has quit [Client Quit]     
07:09 -!- dqx [~dqx@unaffiliated/dqx] has quit [Read error: Connection reset by peer]     
07:10 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
07:11 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev     
07:11 -!- Chris_Stewart_5 [~chris@unaffiliated/chris-stewart-5/x-3612383] has quit [Client Quit]     
07:12 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
07:19 -!- wxss [~user@87.236.196.99] has quit [Ping timeout: 248 seconds]     
07:24 -!- roidster [~chatzilla@71-84-200-106.dhcp.nrwl.ca.charter.com] has joined #bitcoin-core-dev     
07:24 -!- roidster is now known as Guest37184     
07:25 -!- Guest37184 is now known as roidster     
07:26 -!- zshlyk [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
07:26 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
07:28 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has joined #bitcoin-core-dev     
07:32 -!- saint_ [~saint_@unaffiliated/saint-/x-0540772] has joined #bitcoin-core-dev     
07:34 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
07:39 -!- laurentmt [~Thunderbi@92.154.68.134] has joined #bitcoin-core-dev     
07:41 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
07:42 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
07:54 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has joined #bitcoin-core-dev     
08:00 -!- tiagotrs [~tiago@p5DC47519.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
08:00 -!- tiagotrs [~tiago@p5DC47519.dip0.t-ipconnect.de] has quit [Changing host]     
08:00 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
08:03 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
08:03 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
08:04 < BlueMatt> sipa: #11403 looks to have failed travis to to a bad iterator deref ( https://travis-ci.org/bitcoin/bitcoin/jobs/309801879#L2838 )
08:04 < gribble> https://github.com/bitcoin/bitcoin/issues/11403 | SegWit wallet support by sipa · Pull Request #11403 · bitcoin/bitcoin · GitHub
08:05 -!- roidster [~chatzilla@71-84-200-106.dhcp.nrwl.ca.charter.com] has quit [Ping timeout: 255 seconds]     
08:06 -!- wxss [~user@87.236.196.99] has joined #bitcoin-core-dev     
08:07 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
08:08 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
08:23 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has joined #bitcoin-core-dev     
08:25 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
08:26 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
08:26 -!- wxss [~user@87.236.196.99] has quit [Ping timeout: 276 seconds]     
08:27 -!- wxss [~user@185.23.213.22] has joined #bitcoin-core-dev     
08:28 -!- roidster [~chatzilla@172.58.25.198] has joined #bitcoin-core-dev     
08:28 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 268 seconds]     
08:29 -!- roidster is now known as Guest290     
08:29 -!- Guest290 is now known as roidster     
08:40 -!- Dizzle [~dizzle@108.171.182.16] has joined #bitcoin-core-dev     
08:49 -!- roidster_ [~chatzilla@172.58.17.143] has joined #bitcoin-core-dev     
08:49 -!- roidster [~chatzilla@172.58.25.198] has quit [Ping timeout: 255 seconds]     
08:49 -!- roidster_ is now known as roidster     
08:49 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 260 seconds]     
08:59 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:00 -!- Murphy40Hermann [~Murphy40H@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 276 seconds]     
09:00 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
09:04 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds]     
09:14 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has quit [Ping timeout: 240 seconds]     
09:25 -!- microapple [~textual@mobile-130-126-255-103.near.illinois.edu] has joined #bitcoin-core-dev     
09:26 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
09:27 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
09:27 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
09:30 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
09:37 -!- timothy [tredaelli@redhat/timothy] has quit [Quit: Konversation terminated!]     
09:44 -!- gevs [~greg@unaffiliated/gevs] has joined #bitcoin-core-dev     
09:49 -!- microapple [~textual@mobile-130-126-255-103.near.illinois.edu] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
09:51 -!- laurentmt [~Thunderbi@92.154.68.134] has quit [Quit: laurentmt]     
09:56 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev     
09:58 -!- indistylo [~indistylo@122.171.220.58] has joined #bitcoin-core-dev     
10:01 -!- microapple [~textual@2601:240:8101:9698:cc92:14b1:65f:521f] has joined #bitcoin-core-dev     
10:05 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 255 seconds]     
10:08 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 240 seconds]     
10:16 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
10:18 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 264 seconds]     
10:22 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
10:23 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
10:23 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has joined #bitcoin-core-dev     
10:26 < BlueMatt> wumpus: I believe #10773 can be merge
10:26 < BlueMatt> d     
10:27 < gribble> https://github.com/bitcoin/bitcoin/issues/10773 | Shell script cleanups by practicalswift · Pull Request #10773 · bitcoin/bitcoin · GitHub
10:42 -!- Randolf [~randolf@S0106c8fb26572f40.vc.shawcable.net] has quit [Ping timeout: 260 seconds]     
10:44 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
10:46 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds]     
10:47 < BlueMatt> achow101: ping
10:47 < BlueMatt> can you reliably reproduce #11822 ?
10:47 < gribble> https://github.com/bitcoin/bitcoin/issues/11822 | Severe memory leak on current master · Issue #11822 · bitcoin/bitcoin · GitHub
10:47 < achow101> BlueMatt: pong-ish
10:47 < achow101> yes     
10:47 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
10:48 -!- gwillen [~gwillen@unaffiliated/gwillen] has joined #bitcoin-core-dev     
10:48 < achow101> I'm trying it in valgrind again, it's still going very slowly
10:49 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds]     
10:50 < BlueMatt> sec, I doubt its actually a leak, maybe just validation running ahead of wallet
10:50 < BlueMatt> do you have a big(ish) wallet?
10:51 < BlueMatt> achow101: can you try https://github.com/TheBlueMatt/bitcoin/tree/2017-12-11822-debug and see what debug log looks like?
10:51 < BlueMatt> do you get a ton of events generated and then not executed?
10:51  * BlueMatt didnt think this bug was realistically worse than previous master, but it may be, wasnt sure...
10:54 -!- DvdKhl [~Arokh@ip-37-201-211-111.hsi13.unitymediagroup.de] has joined #bitcoin-core-dev     
10:55 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
10:56 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:00 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
11:01 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:02 < achow101> BlueMatt: the wallet is literally empty
11:02 < achow101> I haven't used it; it's completely fresh
11:02 < BlueMatt> but it has a wallet?
11:03 < achow101> yes     
11:03 < BlueMatt> can you test with that patch? may be a lock issue or so
11:03 < achow101> I'll try as soon as it responds to the stop command
11:06 < GAit> am I correct if I say that the rpc doesn't support socket file?
11:06 < sipa> GAit: what rpc?
11:07 < GAit> bitcoin core rpc. Using a socket file rather than a port
11:07 < achow101> GAit: as in unix sockets?
11:07 < sipa> iirc there was a PR for that, but it needed a new version of libevent at the time
11:07 < BlueMatt> it does not (currently), I believe wumpus had some stuff to get it to work, but ...yea, libevent
11:08 < GAit> yes. Thinking because of Abcore. Other apps  could connect to it. 
11:08 < GAit> with a socket file i can prevent that. android app have a different user per app
11:08 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Remote host closed the connection]     
11:08 < achow101> #9979
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9979 | p2p: Bare minimum to support UNIX sockets by laanwj · Pull Request #9979 · bitcoin/bitcoin · GitHub
11:08 < achow101> and #9919
11:08 < gribble> https://github.com/bitcoin/bitcoin/issues/9919 | UNIX sockets support for RPC by laanwj · Pull Request #9919 · bitcoin/bitcoin · GitHub
11:08 < GAit> I managed to compile core for android with ndk by the way, which means i don't need the glibc hack + ld library path with archlinux/debian glibc
11:09 < GAit> thanks sipa & achow101 
11:10 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 260 seconds]     
11:12 < sipa> GAit: cool!
11:22 -!- jb55 [~jb55@208.98.200.100] has joined #bitcoin-core-dev     
11:24 -!- yoctopede [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
11:24 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
11:29 < achow101> BlueMatt: running your patch now. what exactly do you want?
11:30 < BlueMatt> achow101: looking for a pattern of debug.log entries like a bunch of "X event queued!" but not (enough) corresponding "X event executing..."
11:30 < BlueMatt> s     
11:31 < BlueMatt> (or just paste debug log
11:31 < achow101> eyballing this debug.log tail looks like each one is properly paired
11:31 < BlueMatt> hmmm, ok, so not the issue i assumed :(
11:32 < BlueMatt> but the memory is growing?
11:32 < achow101> yes     
11:32 < BlueMatt> hmmmm
11:32 < achow101> not as quickly as yesterday since I dropped the dbcache, but growing much faster than it did with 0.15.1
11:32 < BlueMatt> ok, then its news to me, have you checked a heap profile?
11:32 < achow101> no     
11:33 < BlueMatt> well i guess thats next? (did valgrind give you any actual leaks?)
11:33 < BlueMatt> i assuming circular shared_ptr refs
11:36 -!- wunpunch [~Alli@2a02:c7f:282a:6c00:944b:7c98:a9a4:62ba] has joined #bitcoin-core-dev     
11:36 < achow101> valgrind... died
11:36 < achow101> (I killed it)
11:37 < BlueMatt> ah :/
11:38 < achow101> but while it was running it did not output anything
11:39 < achow101> I'll try it again and be more patient this time
11:42 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 248 seconds]     
11:43 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
11:51 < ryanofsky> it's pretty use address sanitizer too. just: "./configure CXX=clang++ CXXFLAGS=-fsanitize=address LDFLAGS=-fsanitize=address" and run normally. it prints leaks at the end
11:54 < BlueMatt> ugh, fuck you cfields, you sent me down a rabbit hole to replace cvBlockChanged with CValidationInterface, but I think I decided that has to wait on replacing the signals backend with our own thing
11:55 < BlueMatt> cause you really end up wanting the validation interface stuff to have eg two threads where the ordering guarantees are only made per-client, and each new client that gets connected only receives events generated *after* when it was connected
11:55 < cfields> BlueMatt: heh, sorry
11:55 < BlueMatt> (pretty easy to do, I think, you just make events eg a struct and put shared_ptrs to it in each listener's queue)
11:55 < BlueMatt> but its way more work than just fixing a fucking missing cs_main
11:56 < BlueMatt> and is gonna have to wait for 20 other higher-priority things
11:57 < achow101> ryanofsky: will try that at some point
11:57 < BlueMatt> the cvBlockChanged/csBestBlock garbage is....garbage now that we have "real interfaces" to get notifications of validation events
11:59 < cfields> BlueMatt: fwiw, i was picturing just adding a cached uint256 and a function to update it rather than notifying the cv directly
12:00 < BlueMatt> i know you were, but lets *please* not add more in-thread callbacks out of validation :(
12:00 < BlueMatt> I've been working too hard to get rid of those things
12:00 < cfields> i understand your point about using our interfaces. but weighing quick fix against quick fix, that seems better to me
12:00 < BlueMatt> meh, its a short cs_main, why not just take the cs_main
12:02 < cfields> i'm worried that we'll end up locked there for milliseconds where we wouldn't have otherwise. Granted, the re-locking of cs_main at the bottom kinda nullifies that argument.
12:03 < BlueMatt> yea, we re-lock anyway
12:03 < BlueMatt> and, more importantly no one uses longpolling anyway
12:03 < BlueMatt> afaiu
12:04 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:04 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
12:06 < BlueMatt> achow101: you said you can repro by just -reindex'ing?
12:06 < achow101> BlueMatt: yes
12:12 -!- indistylo [~indistylo@122.171.220.58] has quit [Ping timeout: 240 seconds]     
12:12 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
12:13 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
12:14 -!- gevs [~greg@unaffiliated/gevs] has quit [Remote host closed the connection]     
12:24 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has joined #bitcoin-core-dev     
12:25 -!- wunpunch [~Alli@2a02:c7f:282a:6c00:944b:7c98:a9a4:62ba] has quit [Quit: Leaving]     
12:25 < BlueMatt> concept review on #11799 would be appreciated - ignore the code thats there, its useless, but the question is do we want negative-lock-annotations (ie you may not hold cs_main when calling function x) when they are only enforced if the lock is taken directly in the calling function (unlike the requires-lock annotations, these ones dont require you pollute your entire codebase to fully document locking states)
12:25 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev     
12:25 < gribble> https://github.com/bitcoin/bitcoin/issues/11799 | wallet: Add compile-time checking of (non-)locking assumptions for BlockUntilSyncedToCurrentChain() [wip] by practicalswift · Pull Request #11799 · bitcoin/bitcoin · GitHub
12:25 -!- wunpunch [~Alli@2a02:c7f:282a:6c00:944b:7c98:a9a4:62ba] has joined #bitcoin-core-dev     
12:26 < BlueMatt> someone want to close #11823 as NOTABUG
12:26 < gribble> https://github.com/bitcoin/bitcoin/issues/11823 | Shouldnt this be nOut? · Issue #11823 · bitcoin/bitcoin · GitHub
12:27 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Client Quit]     
12:29 < bitcoin-git> [bitcoin] practicalswift closed pull request #11799: wallet: Add compile-time checking of (non-)locking assumptions for BlockUntilSyncedToCurrentChain() [wip] (master...BlockUntilSyncedToCurrentChain-compile-time-warnings) https://github.com/bitcoin/bitcoin/pull/11799
12:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
12:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
12:35 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection]     
12:35 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
12:40 < achow101> hmm. valgrind didn't turn up with anything too frightetning, nor did the address sanitizer
12:40 < achow101> only 160 bytes leaked (granted I only ran then for ~10 minutes each)
12:42 < BlueMatt> achow101: nvm, i got it
12:42 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
12:42 < achow101> .. ok?
12:43 < achow101> BlueMatt: got it as in reproduced or found the leak?
12:44 < BlueMatt> working on fix
12:44 < BlueMatt> sec     
12:54 < BlueMatt> achow101: heh, well maybe I didnt have it, can repro and ran into a seemingly-related bug, however
12:58 -!- jnewbery_ is now known as jnewbery     
13:01 -!- Aaronvan_ is now known as AaronvanW     
13:05 < BlueMatt> achow101: nope, nvm, my first guess was right
13:05 < sipa> BlueMatt: care to elaborate?
13:06 < BlueMatt> validation running ahead of validationinterface, you end up with a deep queue of shared_ptr<CBlock>s of all the shit you connected
13:06 < BlueMatt> not normally an issue, but reindex is particularly easy to hit there
13:07 < sipa> i would guess the solution is to block progress if the queue gets too long?
13:07 < BlueMatt> indeed
13:08 -!- tiagotrs [~tiago@p5DC47519.dip0.t-ipconnect.de] has joined #bitcoin-core-dev     
13:10 < achow101> BlueMatt: oh, I see now. so that's probably why valgrind and address sanitizer wasn't catching it
13:11 < BlueMatt> its not a leak, thats why :p
13:11 < BlueMatt> just an unbounded queue
13:12 < achow101> was my git bisect correct?
13:12 < BlueMatt> yes     
13:12 < achow101> :D     
13:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
13:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
13:17 -!- tiagotrs [~tiago@p5DC47519.dip0.t-ipconnect.de] has quit [Changing host]     
13:17 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has joined #bitcoin-core-dev     
13:18 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
13:19 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
13:19 -!- roidster [~chatzilla@172.58.17.143] has quit [Ping timeout: 260 seconds]     
13:24 -!- Randolf [~randolf@S01066872516d2e74.vc.shawcable.net] has joined #bitcoin-core-dev     
13:24 -!- rhavar [uid237883@gateway/web/irccloud.com/x-vxvzmponiywejfmq] has joined #bitcoin-core-dev     
13:32 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 248 seconds]     
13:41 < cfields> BlueMatt: Hmm. doesn't that imply that at the time something (say wallet) is running a callback, chainActive's tip could've progressed significantly past the payload block?
13:42 < BlueMatt> cfields: yes, but that was always assumed to be allowed?
13:43 -!- Emcy_ [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
13:43 < BlueMatt> cfields: heh, you're gonna murder me...the "quick fix" for this requires a net_processing-specific CNode boolean to be added :/
13:43 < cfields> BlueMatt: how would that have manifested before moving to the scheduler thread?
13:43 < BlueMatt> well, the "super quick fix" is to add a bunch of std::this_thread::yield()s, butttt....
13:44 < BlueMatt> cfields: it wouldnt have, cause the calls are all on the thread that is generating the events
13:44 < cfields> BlueMatt: right. I'm trying to reconsile that with "yes, but that was always assumed to be allowed?"
13:45 < BlueMatt> oh, sorry, yes, just meant that that is the design of validationinterface now
13:45 < BlueMatt> ie shouldnt be news if you reviewed the last 5 prs :p
13:45 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 240 seconds]     
13:46 < cfields> well i didn't have this issue in mind, as I was still thinking too serially. Now I need to go re-review :(
13:46 < BlueMatt> heh, sorry
13:46 -!- jamesob [~james@199.230.10.198] has joined #bitcoin-core-dev     
13:46 < cfields> *synchronously
13:48 -!- shesek [~shesek@bzq-84-110-54-11.red.bezeqint.net] has joined #bitcoin-core-dev     
13:48 -!- shesek [~shesek@bzq-84-110-54-11.red.bezeqint.net] has quit [Changing host]     
13:48 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
13:49 -!- r0d3r5 [522610e4@gateway/web/freenode/ip.82.38.16.228] has joined #bitcoin-core-dev     
13:52 -!- r0d3r5 [522610e4@gateway/web/freenode/ip.82.38.16.228] has quit [Client Quit]     
14:01 -!- ds4tews [c35872e5@gateway/web/freenode/ip.195.88.114.229] has joined #bitcoin-core-dev     
14:06 -!- ds4tews [c35872e5@gateway/web/freenode/ip.195.88.114.229] has quit [Client Quit]     
14:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
14:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
14:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
14:20 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
14:20 -!- meshcollider [uid246294@gateway/web/irccloud.com/x-isiradulzdtbtnoj] has joined #bitcoin-core-dev     
14:43 -!- Randolf [~randolf@S01066872516d2e74.vc.shawcable.net] has quit [Ping timeout: 240 seconds]     
14:44 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 255 seconds]     
14:44 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
14:47 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has quit []     
14:51 < cfields> BlueMatt: see: SyncTransaction -> AddToWalletIfInvolvingMe -> MarkConflicted. That ends up testing against chainActive for conflicts rather than the view from the callback :(
14:52 < BlueMatt> cfields: heh, I know :(
14:53 < BlueMatt> oh, wait, sec
14:53 < BlueMatt> missed your point, sorry
14:54 -!- jb55 [~jb55@208.98.200.100] has quit [Ping timeout: 248 seconds]     
14:54 -!- Cheeseo [~Cheeseo@unaffiliated/cheeseo] has quit [Read error: Connection reset by peer]     
14:54 < cfields> BlueMatt: assuming the callbacks are lagging and chainActive is significantly ahead, MarkConflicted could be looking for conflicts on some future (or reorg'd) chain
14:56 < cfields> (i'm just looking around for things that could accidentally be using chainActive on the callback thread)
15:01 -!- JackH [~laptop@host-80-47-85-226.as13285.net] has quit [Quit: Leaving]     
15:14 < jamesob> cfields: you're looking into the shared_ptr<CBlock> backup?
15:15 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
15:15 < cfields> just having another look over the change that moves the validatioininterface callbacks to the scheduler thread. I guess that's what you mean?
15:16 < jamesob> yeah
15:16 -!- Guyver2 [AdiIRC@guyver2.xs4all.nl] has quit [Quit: Going offline, see ya! (www.adiirc.com)]     
15:17 < jamesob> didn't know if there was a particular fix in mind for that yet
15:23 -!- tiagotrs [~tiago@unaffiliated/tiagotrs] has quit [Ping timeout: 240 seconds]     
15:23 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
15:24 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
15:24 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
15:25 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
15:25 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
15:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
15:29 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
15:30 -!- Dizzle [~dizzle@108.171.182.16] has quit [Quit: Leaving...]     
15:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
15:30 < sipa> BlueMatt, cfields: if the wallet notifications can lag behind chainActive, the wallet needs its own "tip" to test against, no?
15:34 < BlueMatt> cfields: sorry, was just finishing the queue-drain branch...I do not believe that to be an issue? Specifically, in the conflicted case you mention here, the only way to hit it is if the wallet lags behind and the block that made a transaction conflict is already reorg'd off the main chain, in which case you dont want to mark it conflicted, and if its still gonna be conflicted once you get to the best chain a later callback will mark 
15:34 < BlueMatt> it conflicted appropriately
15:34 < BlueMatt> jamesob: yes, I have a branch
15:35 < BlueMatt> sipa: I do not believe that to be the case (currently), please prove me wrong!
15:36 < achow101> BlueMatt: cfields: are you working on the fix for the queue thing or something else?
15:36 < BlueMatt> achow101: yes
15:36 < BlueMatt> though cfields is trying to find other issues in the original pr
15:36 < achow101> ok     
15:38 < sipa> BlueMatt: it certainly sounds safer...
15:38 < cfields> sipa: agreed
15:39 < BlueMatt> sipa: I agree, but to do that you'd rewrite about another 10 functions in the wallet and probably end up refactoring half of it
15:39 < BlueMatt> (again, please prove me wrong :p)
15:39 < cfields> even if the conflicts aren't an issue, i still really don't like that we're testing against some seemingly random chain
15:40 < BlueMatt> well in that one specific case its fine (and kinda the way the function was written to begin with, strangely)
15:40 < sipa> BlueMatt: hmm, really? I would just replace every call to chainActive in the wallet with a local variable, which gets updated through the callbac
15:40 < cfields> BlueMatt: at least for the stuff affected by callbacks, can't we just pass a pindex around instead?
15:41 < BlueMatt> cfields: isnt that like the one place that matters from the callbacks (its been like 8 months since I've looked though)
15:41 < cfields> BlueMatt: unsure. I'll take a closer look before commenting further
15:41 < BlueMatt> sipa: the number of places I'd have to go read to make sure GetDepthInMainChain being disconnected from main chain is fine to be convinced of that is....high
15:42 < BlueMatt> sipa: though I'm sure ryanofsky would appreciate it greatly
15:44 < BlueMatt> sipa: the obvious issue is that gui would have to be aware of the wallet chain state
15:44 < sipa> right
15:44 < sipa> and if there's anything that looks at pcoinsTip from the wallet (is there?) that would also be affected
15:45 < BlueMatt> I dont think there is
15:45 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
15:48 < BlueMatt> sipa: ReacceptWalletTransactions/RelayWalletTransactions would need a only-if-caught-up-to-main-chain condition, but thats the only obvious ones in wallet.cpp...it may be much easier than I thought, but I already have too many open prs to want to do it any time soon
15:51 -!- wunpunch [~Alli@2a02:c7f:282a:6c00:944b:7c98:a9a4:62ba] has quit [Read error: Connection reset by peer]     
15:52 -!- D__ [4f28a212@gateway/web/freenode/ip.79.40.162.18] has joined #bitcoin-core-dev     
15:52 < D__> Dd     
15:52 -!- bule2 [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
15:52 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Remote host closed the connection]     
15:52 -!- D__ is now known as Guest72935     
15:57 -!- Guest72935 [4f28a212@gateway/web/freenode/ip.79.40.162.18] has quit [Ping timeout: 260 seconds]     
16:00 < BlueMatt> achow101: give 11824 a spin?
16:00 < bitcoin-git> [bitcoin] TheBlueMatt opened pull request #11824:  Block ActivateBestChain to empty validationinterface queue (master...2017-12-11822-debug) https://github.com/bitcoin/bitcoin/pull/11824
16:00 < BlueMatt> seems to be working for me
16:00 < achow101> pulling now
16:01 < achow101> why's it so big?
16:02 -!- dpg [4063e058@gateway/web/freenode/ip.64.99.224.88] has joined #bitcoin-core-dev     
16:02 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds]     
16:04 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
16:05 < BlueMatt> cause you cant call the callbacks themselves with cs_main held...I mean the first commit is just a nice-to-have that makes the queue drain faster, the third commit adds DEBUG_LOCKORDER annotations and removes spurious locks in tests, and the last two should probably be squashed
16:05 < achow101> BlueMatt: build error ---> validation.cpp:2480:18: error: ‘promise’ is not a member of ‘std’
16:05 < BlueMatt> its not as bad as it looks
16:05 < BlueMatt> achow101: oops, try now, forgot to commit that line
16:05 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
16:07 < achow101> what's the queue depth set to?
16:08 < BlueMatt> max is 10
16:08 < BlueMatt> feel free to play with it
16:09 < achow101> well it compiled and it's running
16:10 < sipa> ship it.
16:10 < BlueMatt> someone should tag 11822 as 0.16
16:11 < achow101> I'll let you know how it goes, so far so good.
16:11 < BlueMatt> I mean it definitely fixes the obvious infite-queue issue, but there could be other gremlins hiding
16:11 < BlueMatt> I doubt it
16:12 < BlueMatt> my bigger worry with that patch is future lockorder violations, but not a ton to be done about it, honestly
16:12 < sipa> tagged
16:15 < cfields> BlueMatt: i think it'd make for a smoother transition if a fence was inserted after each block's callbacks had been queued, rather than stalling at an arbitrary depth
16:16 < cfields> that way we could still work with the same assumptions as before, while we work out any remaining out-of-sync issues
16:16 < BlueMatt> cfields: ugh, we started the fence-removal process two releases ago, I'd rather not add it back if we can avoid it :(
16:16 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Ping timeout: 248 seconds]     
16:18 < cfields> BlueMatt: the PR is the same thing, I'm just suggesting using a block-callback-depth (depth == 1 initially) rather than an individual callback depth.
16:18 < BlueMatt> hmm, that patch may not be sufficient :/ achow101 you see it staying low?
16:18 < achow101> BlueMatt: it's reasonable given my current dbcache of 8000
16:19 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
16:19 < BlueMatt> cfields: well if you want to do that we should move the blocking to the end and not the beginning and set it to 1 right before release/on the backport branch, not on master, please
16:20 < BlueMatt> cfields: 90% of the reason to merge this stuff sooner rather than later is to get testing cycles on it
16:20 < BlueMatt> otherwise its never gonna happen
16:21 < achow101> BlueMatt: I'd like this to be merged so I can run my fucking node :p
16:22 < BlueMatt> achow101: lol, you dont carry patches on your node?
16:23 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
16:23 < achow101> BlueMatt: my node is also what I test and develop on and I would like to be able to test the other stuff I'm working on and PR it without extra patches
16:23 -!- wxss [~user@185.23.213.22] has quit [Quit: leaving]     
16:24 -!- microapple [~textual@2601:240:8101:9698:cc92:14b1:65f:521f] has quit [Ping timeout: 255 seconds]     
16:24 < BlueMatt> heh, well feel free to review
16:26 < cfields> BlueMatt: to be clear, i was suggesting that we let it run a full block ahead (depth of single block's callbacks). I wasn't suggesting that we use an actual depth of 1.
16:26 < BlueMatt> well res size seems to have stabilized on my reindex-chainstate node
16:26 < BlueMatt> cfields: I dont know how much that'd do aside from hide bugs?
16:27 < BlueMatt> if we want to neuter it cause we're worried, we should make ProcessNewBlock/ActivateBestChain block until callbacks finish for the latest action
16:27 < BlueMatt> letting it run ahead but heavily limiting how much it can run ahead just sounds like it'll hide more bugs than anything, no?
16:29 < cfields> well yes, but it'd ensure that we're only introducing one class of bugs at a time
16:33 < achow101> for each extra item in the queue, how much extra memory does that use
16:34 -!- microapple [~textual@mobile-130-126-255-103.near.illinois.edu] has joined #bitcoin-core-dev     
16:35 < sipa> a few MB, i expect
16:36 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 260 seconds]     
16:36 -!- ensign [~ensign@2001:41d0:8:d711::1] has quit [Ping timeout: 258 seconds]     
16:37 < BlueMatt> achow101: (or not reindex)
16:37 < BlueMatt> achow101: its (during IBD, mostly just) a shared_ptr<const CBlock>
16:38 < achow101> BlueMatt: I'm not sure if the problem I saw was limited to reindex only though
16:38 < BlueMatt> cfields: I'm not sure which class of bugs is resolved by your suggestion, tbh?
16:38 < BlueMatt> achow101: it should almost entirely be
16:38 < BlueMatt> your wallet shouldnt take 10 minutes to process a new block....
16:38 < achow101> BlueMatt: the node crashed at some point before I had to reindex, and I think that was because of an OOM to (had to do the whole reboot computer stuff as I did when it crashed during reindex)
16:38 < BlueMatt> cfields: blocking before return may fix some stuff, but....
16:39 < achow101> that crash caused me to need to reindex it now
16:39 < BlueMatt> achow101: thats.....weird
16:39 < achow101> it's possible that that was unrelated, but I'm not sure
16:39 -!- ensign [~ensign@2001:41d0:8:d711::1] has joined #bitcoin-core-dev     
16:41 < BlueMatt> was that like right after a restart where you needed to catch up a few days blocks?
16:41 < BlueMatt> though even that shouldnt use all that much memory....
16:41 -!- dcousens [~dcousens@CPE-101-181-109-10.lnse5.cha.bigpond.net.au] has joined #bitcoin-core-dev     
16:41 < BlueMatt> i mean this has been on master a while...
16:42 < achow101> no, it had been up for a few days at that point, and I had it running for several weeks with a build of master prior to that
16:42 < achow101> although it is possible that the build I was running before did not have your PR merged
16:44 < achow101> I can grep through my log file to see what was running before I started on this build. although it may take a while since that log file is 42 GB because I forgot to turn of debug=net
16:45 < BlueMatt> hmm, I mean I did a read-through of the queue logic and didnt see any obvious races
16:45 < BlueMatt> ls -lh ~/.bitcoin/debug.log
16:45 < BlueMatt> -rw------- 1 matt matt 6.5T Dec  4 19:45 /home/matt/.bitcoin/debug.log
16:45 < BlueMatt> errr, s/races/leaks/
16:46 < achow101> BlueMatt: do you have your node patched to not shrink the debug.log at each restart?
16:46 -!- DvdKhl [~Arokh@ip-37-201-211-111.hsi13.unitymediagroup.de] has quit [Ping timeout: 240 seconds]     
16:46 < BlueMatt> i believe it does not shrink by default if -debug? or something like that
16:46 -!- microapple [~textual@mobile-130-126-255-103.near.illinois.edu] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
16:47  * BlueMatt -> out, if bug is still there, do a heap profile
16:47 -!- microapple [~textual@mobile-130-126-255-103.near.illinois.edu] has joined #bitcoin-core-dev     
16:52 -!- microapple [~textual@mobile-130-126-255-103.near.illinois.edu] has quit [Ping timeout: 248 seconds]     
16:53 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
16:55 -!- dabura667 [~dabura667@p98110-ipngnfx01marunouchi.tokyo.ocn.ne.jp] has joined #bitcoin-core-dev     
16:59 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds]     
17:03 < jamesob> going to test #11824 with -reindex
17:03 < gribble> https://github.com/bitcoin/bitcoin/issues/11824 | Block ActivateBestChain to empty validationinterface queue by TheBlueMatt · Pull Request #11824 · bitcoin/bitcoin · GitHub
17:05 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev     
17:06 -!- Aaronvan_ [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection]     
17:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 248 seconds]     
17:18 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-pnxbawoshzwesjrl] has quit [Quit: Connection closed for inactivity]     
17:19 -!- Deacyde [~Deacyde@unaffiliated/deacyde] has joined #bitcoin-core-dev     
17:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
17:23 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
17:24 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
17:40 -!- microapple [~textual@mobile-130-126-255-103.near.illinois.edu] has joined #bitcoin-core-dev     
17:56 -!- cdecker [~cdecker@mail.snyke.net] has quit [Ping timeout: 276 seconds]     
17:57 -!- cdecker [~cdecker@mail.snyke.net] has joined #bitcoin-core-dev     
17:57 -!- lifeofguenter [~lifeofgue@bnc.pro.to.co.ls] has quit [Ping timeout: 276 seconds]     
17:57 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Ping timeout: 248 seconds]     
17:59 -!- lifeofguenter_ [~lifeofgue@bnc.pro.to.co.ls] has joined #bitcoin-core-dev     
17:59 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #bitcoin-core-dev     
18:01 -!- microapple [~textual@mobile-130-126-255-103.near.illinois.edu] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
18:03 -!- rhavar [uid237883@gateway/web/irccloud.com/x-vxvzmponiywejfmq] has quit [Quit: Connection closed for inactivity]     
18:09 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
18:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
18:14 -!- Murch [~murch@96-82-80-28-static.hfc.comcastbusiness.net] has quit [Quit: Snoozing.]     
18:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
18:15 < promag> please give feedback to #11826, ty
18:15 < gribble> https://github.com/bitcoin/bitcoin/issues/11826 | RFC: Activity feature · Issue #11826 · bitcoin/bitcoin · GitHub
18:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
18:19 -!- microapple [~textual@2601:240:8101:9698:b909:42d5:e2b:4551] has joined #bitcoin-core-dev     
18:21 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has joined #bitcoin-core-dev     
18:26 -!- microapple [~textual@2601:240:8101:9698:b909:42d5:e2b:4551] has quit [Ping timeout: 255 seconds]     
18:31 -!- Randolf [~randolf@96.53.47.42] has quit [Ping timeout: 268 seconds]     
18:32 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 268 seconds]     
18:42 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
18:44 -!- Emcy_ [~Emcy@unaffiliated/emcy] has quit [Ping timeout: 248 seconds]     
18:47 -!- jamesob [~james@199.230.10.198] has quit [Ping timeout: 248 seconds]     
18:48 -!- shesek [~shesek@unaffiliated/shesek] has joined #bitcoin-core-dev     
18:49 -!- Emcy [~Emcy@unaffiliated/emcy] has quit [Read error: Connection reset by peer]     
18:52 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
19:18 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
19:20 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
19:23 -!- Emcy [~Emcy@unaffiliated/emcy] has joined #bitcoin-core-dev     
19:23 -!- Chris_Stewart_5 [~chris@gateway/vpn/privateinternetaccess/chrisstewart5/x-62865615] has quit [Ping timeout: 260 seconds]     
19:26 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has joined #bitcoin-core-dev     
19:29 -!- microapple [~textual@2601:240:8101:9698:b909:42d5:e2b:4551] has joined #bitcoin-core-dev     
19:53 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
20:02 -!- jtimon [~quassel@164.31.134.37.dynamic.jazztel.es] has quit [Ping timeout: 255 seconds]     
20:08 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 240 seconds]     
20:09 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev     
20:10 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
20:11 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
20:27 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer]     
20:28 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev     
20:38 -!- microapple [~textual@2601:240:8101:9698:b909:42d5:e2b:4551] has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]     
20:44 < bitcoin-git> [bitcoin] kallewoof closed pull request #11489: [wallet] sendtoaddress style argument (master...201709_segwitwallet2_sendtoaddress) https://github.com/bitcoin/bitcoin/pull/11489
20:44 -!- Randolf [~randolf@96.53.47.42] has joined #bitcoin-core-dev     
20:46 -!- brianhoffman [~brianhoff@pool-96-231-163-68.washdc.fios.verizon.net] has quit [Read error: Connection reset by peer]     
20:46 -!- brianhoffman [~brianhoff@pool-96-231-163-68.washdc.fios.verizon.net] has joined #bitcoin-core-dev     
20:48 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
20:48 -!- bule2 [~bule@gateway/tor-sasl/bule] has quit [Remote host closed the connection]     
20:59 -!- roidster [~chatzilla@172.58.75.73] has joined #bitcoin-core-dev     
21:00 -!- roidster is now known as Guest70224     
21:00 -!- Guest70224 is now known as roidster     
21:07 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
21:08 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
21:11 -!- musalbas [~musalbas@2001:bc8:30c2:ff00::] has joined #bitcoin-core-dev     
21:16 -!- bule [~bule@gateway/tor-sasl/bule] has quit [Remote host closed the connection]     
21:16 -!- bule [~bule@gateway/tor-sasl/bule] has joined #bitcoin-core-dev     
21:22 < kallewoof> I've been asked about address index on top of bitcoin core (to replace the unmaintained fork that exists somewhere else). What are people's opinions on this? I know some people prefer a minimal code base, but having an address index option seems like it would alleviate a lot of problems in a lot of places.
21:27 < gmaxwell> a history address index is unsustainable; anyone who uses it is eventually going to be forced to use trust a third party service.  
21:27 < kallewoof> Why?
21:28 < kallewoof> Too much space, or..?
21:28 < gmaxwell> I don't see any problems with having hooks to support such things, but directly incorporating an index of history wouldn't just be a waste of our review and maintaince resources, it would be actively harmful to the ecosystem.
21:28 < gmaxwell> Yes too much space, too much seek load, and incompatible with pruning; or any kind of pruned sync.
21:29  * kallewoof nods
21:29 < gmaxwell> we've also already seen that behavior where people using such indexes constructed via abe or other tools that created them, failed back to blockchain.info and similar.
21:29 < gmaxwell> They're also not required except for unusual cases (like making an explorer, which also requires spent-position indexes).   An index of unspent outputs would be far more reasonable.
21:30 < kallewoof> Yeah, this would be used by explorers, I would expect. I think some (lots?) of them use the unmaintained fork I mentioned earlier.
21:30 < gmaxwell> I sure hope not.
21:31 < kallewoof> Rumor says it is so. Part of why I was asked to look into it.
21:31 < gmaxwell> I know with absolute certanty that that old index patch could lose data, I just don't know _how_.
21:31 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
21:32 < kallewoof> I think having hooks in bitcoin core that let such a system exist separately is a good plan. It would only rely on API breakage, which bitcoin core is very careful about.
21:32 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
21:32 < gmaxwell> As in I had a node with it where it was faliing to actual spendable outputs connected to an address, and I tested that it was incorrect quite throughly. I assumed the bad data was some gotcha with reorgs or likewise, but no one investigated.
21:32 < gmaxwell> Yes, hooks for such things seem fine to me.
21:32 < kallewoof> Ah.. yeah, reorgs is definitely a challenge.
21:35 < sipa> if i had infinite time i'd write a separate efficient indexing service, which just speaks the p2p protocol
21:36 < sipa> which you then can connect to bitcoind 
21:38 < kallewoof> sipa: I guess that would have the obvious benefit of not actually needing a node at all if it could just sync from the network?
21:38 < sipa> right
21:39 < sipa> it would be nice to reuse some of the headers sync logic in core, but if you assume you're connected to a trusted peer anyway, i don't think it needs to be allthat complicated
21:39 < sipa> just deal with reorgs
21:40 -!- xRavenheart [~Daryl@116.197.231.34] has joined #bitcoin-core-dev     
21:40 < gmaxwell> from an arch perspective you'd even want it to just keep a SQL database in sync, unfortunately the performance would be horrible except on gold plated system. (massive nvem raid 1 arrays and gobs of ram or whatever)
21:42 < kallewoof> SQL db sounds like it would be kinda slow yeah.
21:42 < gmaxwell> thats how abe worked.
21:42 < kallewoof> I was thinking of using redis, but I think I'm gonna have to do profiling to find a good solution.
21:43 < gmaxwell> last I heard of anyone successfully running it, it required well over 1TB state and would take a month to sync or something.
21:43 < kallewoof> Wow..
21:43 < sipa> i think it's been unusably slow for the better part of 5 years now
21:44 < gmaxwell> this was years ago, it would presumably be some multiple of that now.
21:49 < kallewoof> It would be address -> tx list, tx -> address list, block -> tx list.. tx'es could be compressed as block height + index (so ~8b). Not sure what else neat stuff you could do. sipa's work on tx format should be inspiring.
21:50 < esotericnonsense> blockheight + index doesn't work well at all, what about reorgs
21:51 < kallewoof> Maybe keep track of last 1000 entries and undo all based on shared fork point height?
21:51 < gmaxwell> works fine, so long as you're only tracking a single chain at a time.
21:51 < gmaxwell> you have to back out the index and reapply.
21:51 < kallewoof> Could just look at block again and undo, yeah.
21:53 < esotericnonsense> eh I suppose that's right. SQL is a bit abstracted for me i'm not sure how it stores repeated data internally. f.ex. if you have a ton of tables with foreign keys do they store the keys repeatedly or use a more space efficient method.
21:55 < esotericnonsense> for example on chain you might have a 256bit txid used hundreds of times if it has a bunch of outputs but you can probably just store that as a 32bit(?) incrementing integer on every tx you've seen since genesis.
21:55 < kallewoof> I really doubt SQL would work well for this, but I could be wrong.
21:56 < Randolf> esotericnonsense:  It depends on the SQL server software being used.  As far as I know, whatever you choose to store in the columns is what's stored there.
21:57 < Randolf> esotericnonsense:  Usually it's up to the DBA to choose to set up smaller IDs that reference more data in a separate row.
21:58 < kallewoof> We've used up 6.5% of a uint32 (278236762/4294967295), but it could work for awhile at least.
21:58 < Randolf> esotericnonsense:  For Bitcoin stuff, I'd create custom datatypes that save the data in binary format.
21:59 < esotericnonsense> basically what i'm thinking is that these indexes can easily multiply the blockchain size by five  and possibly more depending on how you do it if you store the full data.
21:59 < Randolf> It's possible.
22:00 < esotericnonsense> address -> txlist, block -> txlist, and tx (unless you don't store tx but pull it out of a stored blockchain) is 3x txid
22:00 < Randolf> An index normally refers to an internal reference that's usually smaller than the column data it's indexing.
22:01 < Randolf> Can arrays help?  In PostgreSQL a column type can be an array.
22:01 < Randolf> These can also be indexed efficiently.
22:02 < Randolf> While you'd still be storing TX data, you could cut down on the number of rows.
22:08 < gmaxwell> this sort of speculation isn't so useful.
22:09 < gmaxwell> IIRC the abe schema wasn't too offensively inefficienct, but there are overheads and billions of records add up... but nothing is really learned from this discussion.  just "I think this would be not efficienct" and "I think it would be, maybe" :P
22:09 < esotericnonsense> yeah agree.
22:09 < kallewoof> I'll just try a bunch of stuff I guess.
22:10 < esotericnonsense> it sounds to me like what might be useful is to have a seperate service that only maintains the set of things core doesn't
22:11 < esotericnonsense> so basically addrindex but as an external thing. all it needs is addr->[txids]. if you want the transactions just ask core rpc with txindex on
22:12 < esotericnonsense> that'd only need the core rpc api to remain (relatively) static and not have to be maintained as a thing on an ongoing basis if internals shuffle around.
22:12 < kallewoof> If txs are stored as height+index you don't even need txindex, at least if #10275 is merged.
22:12 < gribble> https://github.com/bitcoin/bitcoin/issues/10275 | [rpc] Allow fetching tx directly from specified block in getrawtransaction by kallewoof · Pull Request #10275 · bitcoin/bitcoin · GitHub
22:13 < kallewoof> And yeah, we agreed this should be an external thing that either uses hooks in bitcoin or implements the p2p protocol and talks to the network directly.
22:15 < esotericnonsense> i guess i was commenting on "address -> tx list, tx -> address list, block -> tx list" and how i don't think you need the latter two because bitcoind does it
22:15  * kallewoof nods
22:16 < kallewoof> I wasn't assuming the person running had a local synced node. Maybe I should.
22:17 < esotericnonsense> eh? addrindex implies that no? (well that or that you have rpc access anyway).
22:18 < kallewoof> sipa had the idea of an efficient indexing service which speaks the p2p protocol.
22:19 < gmaxwell> that assumption saves you basically 1x copy of the blockchain at most, but then means you can't run the indexer on the seperate hardware from the node or fail over between multiple nodes, etc.
22:19 < gmaxwell> or upgrade the node independantly from the indexer
22:21 -!- roidster [~chatzilla@172.58.75.73] has quit [Ping timeout: 260 seconds]     
22:22 < kallewoof> Makes sense
22:22 < kallewoof> (to not assume local node)
22:23 < esotericnonsense> i'm confused. you can run the indexer on seperate hardware just fine. failover works in the same way anyway (you can have multiple bitcoinds if you want)
22:24 < esotericnonsense> height+index storing of transactions becomes complicated in that case sure.
22:25 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
22:25 < kallewoof> Ultimately it doesn't matter to the indexer if you have a local node or not. It won't use it directly, it will use the p2p network. The only time it needs the RPC is when it wants to convert e.g. block height+index into a tx, but it might just as well give you the height+index pairs and let you deal yourself.
22:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
22:26 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
22:29 < gmaxwell> also if the node the indexer is behind is pruned then the overhead of a redundant copy mostly goes away.
22:30 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
22:33 -!- indistylo [~indistylo@119.82.105.106] has joined #bitcoin-core-dev     
22:38 < kallewoof> If the node is pruned, the indexer will not be able to use it for any lookups of block height <= pruned height
22:38  * esotericnonsense is in a state of befuddlement
22:39 < esotericnonsense> if it has p2p logic (basically it's a node) then what is the seperate bitcoind node being used for at all
22:39 -!- dcousens [~dcousens@CPE-101-181-109-10.lnse5.cha.bigpond.net.au] has quit [Quit: Ping timeout (120 seconds)]     
22:39 < esotericnonsense> trusted verifier i guess?
22:39 -!- dcousens [~dcousens@CPE-101-181-109-10.lnse5.cha.bigpond.net.au] has joined #bitcoin-core-dev     
22:39 < kallewoof> The indexer doesn't store anything but the indexing parts, so it needs a node to resolve the 8 byte (block height + tx index) into actual transactions. It could store the entire block chain while at it, but that seems a bit redundant.
22:40 < sipa> kallewoof: that seems inefficient
22:40 < sipa> relying on a node for storage won't gove the kind of performance a blockexplorer needs
22:41 < kallewoof> I thought you were suggesting a p2p indexer that doesn't depend on a local node. Why not use RPC then?
22:42 < sipa> rpc is slow
22:42 < kallewoof> Or are you saying store the entire transaction in the indexer db?
22:42 < sipa> yes     
22:42 < kallewoof> Ah     
23:07 -!- DvdKhl [~Arokh@ip-37-201-211-111.hsi13.unitymediagroup.de] has joined #bitcoin-core-dev     
23:14 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
23:15 -!- jb55 [~jb55@70-36-49-138.dyn.novuscom.net] has quit [Ping timeout: 248 seconds]     
23:15 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
23:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
23:17 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
23:17 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has quit [Remote host closed the connection]     
23:19 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]     
23:20 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-vydubdncpgodhzmx] has joined #bitcoin-core-dev     
23:22 -!- intcat [~zshlyk@gateway/tor-sasl/intcat] has joined #bitcoin-core-dev     
23:33 -!- shesek [~shesek@unaffiliated/shesek] has quit [Ping timeout: 260 seconds]     
23:39 -!- xRavenheart [~Daryl@116.197.231.34] has quit [Quit: Leaving]     
23:41 -!- Cogito_Ergo_Sum [~Myself@ppp-94-64-159-66.home.otenet.gr] has joined #bitcoin-core-dev     
23:41 -!- Cogito_Ergo_Sum [~Myself@ppp-94-64-159-66.home.otenet.gr] has quit [Changing host]     
23:41 -!- Cogito_Ergo_Sum [~Myself@unaffiliated/cogito-ergo-sum/x-7399460] has joined #bitcoin-core-dev     
23:44 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has joined #bitcoin-core-dev     
23:53 -!- unholymachine [~quassel@c-69-248-123-139.hsd1.nj.comcast.net] has quit [Ping timeout: 255 seconds]     
23:54 -!- unholymachine [~quassel@c-69-248-123-139.hsd1.nj.comcast.net] has joined #bitcoin-core-dev     
23:57 -!- promag [~promag@bl22-247-244.dsl.telepac.pt] has quit [Remote host closed the connection]