--- Day changed Fri Oct 30 2015
00:01 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .]
00:01 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
00:13 -!- danielsocials [~AndChat20@106.120.101.38] has joined #bitcoin-core-dev
00:21 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has quit [Ping timeout: 240 seconds]
00:24 -!- Luke-Jr [~luke-jr@unaffiliated/luke-jr] has joined #bitcoin-core-dev
00:27 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
00:29 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 260 seconds]
00:32 -!- danielsocials [~AndChat20@106.120.101.38] has quit [Ping timeout: 240 seconds]
00:33 -!- danielsocials [~AndChat20@106.120.101.38] has joined #bitcoin-core-dev
00:38 -!- danielsocials [~AndChat20@106.120.101.38] has quit [Remote host closed the connection]
00:48 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wfteurwcahvxprlc] has joined #bitcoin-core-dev
01:02 -!- danielsocials [~AndChat20@106.120.101.38] has joined #bitcoin-core-dev
01:15 < jonasschnelli> ping https://github.com/bitcoin/bitcoin/pull/6780
01:15 < jonasschnelli> should get in before it gets outdated
01:16 -!- danielsocials [~AndChat20@106.120.101.38] has quit [Remote host closed the connection]
01:40 < GitHub158> [bitcoin] laanwj closed pull request #6913: 0.11 (master...0.11) https://github.com/bitcoin/bitcoin/pull/6913
01:41 -!- pavel_ [~paveljani@79-98-72-216.sys-data.com] has quit [Quit: Leaving]
01:42 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has joined #bitcoin-core-dev
01:42 -!- paveljanik [~paveljani@79-98-72-216.sys-data.com] has quit [Changing host]
01:42 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has joined #bitcoin-core-dev
01:44 -!- BashCo_ [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
01:55 -!- rubensayshi [~ruben@91.206.81.13] has joined #bitcoin-core-dev
02:03 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
02:50 -!- PRab_ [~chatzilla@2601:40a:8000:8f9b:e53e:6986:5865:2f1f] has joined #bitcoin-core-dev
02:51 -!- PRab [~chatzilla@2601:40a:8000:8f9b:e53e:6986:5865:2f1f] has quit [Ping timeout: 246 seconds]
02:51  * wumpus has an old crappy laptop with windows now, let the carnage begin...
02:51 -!- PRab_ is now known as PRab
02:56 < wumpus> I'm sure it comes with rootkits and malware pre-installed to simulate a true, out in the wild windows environment
02:57 < phantomcircuit> :P
02:59 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has quit [Ping timeout: 255 seconds]
03:15 < dcousens> wumpus: what would you say an average time for re-index is?
03:16 < dcousens> (ballpark, obv. very dependent on hardware)
03:19 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
03:31 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Quit: Leaving]
04:27 -!- NLNico [~NLNico@unaffiliated/nlnico] has joined #bitcoin-core-dev
04:28 -!- NLNico [~NLNico@unaffiliated/nlnico] has quit [Client Quit]
04:45 -!- tulip [~tulip@162.248.140.238] has joined #bitcoin-core-dev
05:04 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
06:12 < morcos> sipa: i've been trying to track down some odd slowness in ConnectBlock and I found something I think interesting
06:13 < morcos> When we do UpdateCoins and we need to add the outputs for the new coins we are now creating.  We call ModifyCoins(new tx hash) which will end up doing a database read.
06:14 < morcos> so even if our cache is completely up to date, we have to read the database anyway
06:14 < morcos> There is already an existince check for BIP30 earlier
06:14 < morcos> I'm wondering if we should have some sort of negative cache too
06:16 < morcos> Also do we need to persist the BIP30 check?  Is it still possible to violate that or now that the old duplicate coinbases are sufficiently buried, its not necessary
06:16 < morcos> Anwyay, I have to go afk.  I'll look into it more later.
06:59 -!- ParadoxSpiral [~ParadoxSp@p508B8509.dip0.t-ipconnect.de] has joined #bitcoin-core-dev
07:00 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has joined #bitcoin-core-dev
07:03 -!- testing-tape [~testing-t@cpe-172-73-230-228.carolina.res.rr.com] has quit [Remote host closed the connection]
07:08 -!- Guest75176 [~pigeons@94.242.209.214] has quit [Ping timeout: 260 seconds]
07:08 -!- pigeons [~pigeons@94.242.209.214] has joined #bitcoin-core-dev
07:08 -!- pigeons is now known as Guest35844
07:31 < morcos> sipa: still afk, but yep, thats a cause of SIGNIFICANT slowness in ConnectBlock.  I think we'd have to change/remove the BIP30 check to really eliminate it, which might be the harder part, bc I think adjusting ModifyCoins to know its a new tx and not lookup seems easy and safe?
07:41 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Ping timeout: 256 seconds]
07:45 -!- goregrind [~goregrind@unaffiliated/goregrind] has joined #bitcoin-core-dev
07:55 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]
07:55 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
08:04 < wumpus> cfields: what would be the best way to include the windows determinism postprocessing in the gitian build (in https://github.com/bitcoin/bitcoin/pull/6900) - call it from the descriptor or 'make'?
08:05 < cfields> wumpus: since that's really only useful for gitian (and a specific version of binutils), i'd say in the descriptor is fine
08:05 < wumpus> yeah, thought as much
08:05 -!- zooko [~user@c-24-9-79-61.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:06 < wumpus> do wonder how to make it output the linker map though
08:06 < cfields> wumpus: i haven't taken a good look yet, but i'm surprised that you can't find the necessary offsets with objdump/nm/etc. I suppose you tried all those first?
08:06 < wumpus> objdump and friends all report virtual addresses
08:06 -!- zooko` [~user@c-24-9-79-61.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:06 -!- zooko [~user@c-24-9-79-61.hsd1.co.comcast.net] has quit [Client Quit]
08:06 -!- zooko` [~user@c-24-9-79-61.hsd1.co.comcast.net] has quit [Remote host closed the connection]
08:07 < cfields> mm, ok
08:07 -!- zooko [~user@c-24-9-79-61.hsd1.co.comcast.net] has joined #bitcoin-core-dev
08:07 < wumpus> and within a section they're no help at all, for finding the offset, it's not like there's a pointer to this variable (the other option may be to parse DWARF information, but hm...)
08:08 < wumpus> that may not even work, I don't think gdb has an offset to it, it reports it as GS_ExceptionPointers+8/16
08:08 < cfields> wumpus: another fleeting thought.. in the mailing-list link you posted, some of my binutils changes are listed in the same changelog...
08:08 < cfields> you completely sure that this is the only hack necessary?
08:09 < cfields> iirc it was the one that removed timestamps from windres
08:09 < wumpus> well I found no other differences between multiple builds
08:09 < wumpus> remember, we still use faketime
08:10 < cfields> ah, right
08:10 < wumpus> the tor folks build binutils themselves
08:11 < wumpus> but anyhow, the current script works, so I'll just integrate that for now
08:11 < cfields> sounds good
08:13 < cfields> wumpus: one last quick thought, another option might be using LD_PRELOAD to wrap malloc (or whatever is leaving unsanitized data)
08:17 < wumpus> hehe.
08:18 < wumpus> wonder if  mallopt(M_PERTURB,...) can be set from the environment
08:18 < wumpus> I think so! it should do exactly this
08:19 < cfields> hah! neat. I was just doing a quick malloc->calloc wrapper. That looks smarter :)
08:22 < wumpus>  'export MALLOC_PERTURB_=23'  seems to work
08:22 < wumpus> (at least outside of gitian, let's try inside)
08:22 < wumpus> that was an awesome idea
08:23  * wumpus resents having written a PE parser :-)
08:24 < cfields> should probably wrap the linker in a script and export it there, rather than globally. It's hard to imagine anything build-side dependent on that, but i'd hate to see something like the debian-openssl thing crop up again :)
08:24 < wumpus> also reduces the performance hit
08:25 < cfields> yep
08:26 < cfields> wumpus: nice find on MALLOC_PERTURB_. that makes this very simple :)
08:27 < wumpus> but the linker is invoked as 'g++' isn't it?
08:27 < cfields> g++ invokes ld
08:27 -!- zooko [~user@c-24-9-79-61.hsd1.co.comcast.net] has quit [Remote host closed the connection]
08:28 < wumpus> oh yes it's even worse for mingw, it invokes collect2, which is a wrapper for ld. I wonder if it's possible to interpose somehwere there
08:28 < wumpus> (well obviously, by replacing the executable... but I wonder if it uses path somewhree)
08:29 < cfields> uhmm, you can specify your own linker i believe
08:30  * Luke-Jr imagines each of these is used for a reason
08:31 < wumpus> Luke-Jr: 'collect2' is MS's linker, which for mingw is emulated by ld
08:32 < Luke-Jr> oh, it's just emulating it?
08:33 < wumpus> yes - it could really use MS's linker, if you have it available
08:33 < Luke-Jr> interesting
08:37 < cfields> wumpus: yup, looks like it checks for 'real-ld'
08:38 < cfields> and ${prefix}-real-ld
08:40 < wumpus> I haven't been able to trick it yet into running a different linker outside the $prefix (created all sorts of variants of collect2 and ld in my PATH)
08:41 < wumpus> one remaning option would be to override gcc's specs, but bleh
08:46 < wumpus> seems it only looks for 'linker' outside its hardcoded path  /usr/lib/gcc/x86_64-w64-mingw32/4.8 if it cannot find it there
08:47 -!- zooko [~user@50.141.117.98] has joined #bitcoin-core-dev
08:48 < wumpus> what works is: 'gcc -dumpspecs > specsfile' 'sed -i s/collect2/mycollect2/g specsfile' 'gcc -specs=specsfile'
08:48 < wumpus> then put mycollect2 somewhere in the path...
08:48 < wumpus> it's kind of stupid though
08:49 < wumpus> hmm overrding GCC_EXEC_PREFIX may work too
08:49 < wumpus> but that means copying the other files
08:49 < wumpus> oh there is COMPILER_PATH  too, where it will look for subprograms if it cannot find in EXEC_PREFIX
08:49 < wumpus> great, this may yet be solvable
08:50 < cfields> wumpus: heh, was just testing that one
08:50 < cfields> no luck
08:51  * wumpus considers just defining the malloc perturb globally and be done with it...
08:51 < cfields> wait, that worked :)
08:51 < cfields> export COMPILER_PATH=`pwd`
08:51 < cfields> then wrap ./collect2
08:52 < wumpus> according to the docs it only looks there if it cannot find it in the EXEC_PREFIX, but will try
08:52 < wumpus> yep, seems to work!
08:58 < wumpus> cfields: something like this? https://gist.github.com/laanwj/10b0981d9d75510a124f
08:58 < cfields> wumpus: http://pastebin.com/W350ZGK5
08:58 < cfields> hah!
08:59 < cfields> looks great
08:59 < wumpus> ah yes, $CC -print-prog-name=collect is nice
09:03 < wumpus> updated to use that https://gist.github.com/laanwj/10b0981d9d75510a124f  (now request the path of the collect2 tool while creating the wrapper script instead of hardcoding it in the descriptor)
09:04 < cfields> wumpus: need to unset COMPILER_PATH or you get an infinite loop
09:04 < wumpus> COMPILER_PATH is not set at that point yet :)
09:05 < wumpus> it's set in the per-host build loop later on
09:06 < cfields> oh heh, you're finding the path outside of the script. nm :)
09:06 -!- zooko [~user@50.141.117.98] has quit [Ping timeout: 264 seconds]
09:06 < wumpus> yes I look up the path upfront
09:06 < cfields> well that's nice and simple if it works
09:09 < cfields> wumpus: just to be on the paranoid side, should probably compare before/after to make sure that only the expected bytes changed.
09:10 < wumpus> well if more bytes change then we should definitely skip trusty, agreed
09:12 < cfields> (i just mean eyeballing it once, ofc. not suggesting scripting that part)
09:16 < wumpus> leaking heap data into output is really ugly, can be e.g. a privacy issue, I'm happy it was solved two years ago ;)
09:16 < wumpus> MS office had some legendary fuckups in this regard
09:17 < cfields> wumpus: assuming mingw is self-hosted,  we can check the bins for leaks and see if the dev had anything interesting in mem :)
09:19 < wumpus> hehe
09:20 < wumpus> well in this case it seems it leaks some internal address; could be used to bypass ASLR, if it was a longer running process
09:20 -!- dixson3 [~textual@cpe-72-182-110-15.austin.res.rr.com] has joined #bitcoin-core-dev
09:30 < sipa> morcos: we should get rid of the bip30 check; it's superseeded by bip34
09:31 < cfields> wumpus: for the qt fix, can that ifdef just be c/p to the header as well?
09:33 < wumpus> cfields: yes I suppose the same principle can be used to use either PIDLIST_ABSOLUTE or ITEMIDLIST
09:34 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev
09:34 < wumpus> (just copy pasting won't work though because the typedef won't help_
09:34 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has quit [Ping timeout: 246 seconds]
09:35 < cfields> wumpus: ok. mind PRing that separate? or I can? That needs fixing regardless of when we switch gitian
09:35 < wumpus> no problem if you do :)
09:35 < cfields> i'm happy to do it, not trying to con you into that one :)
09:35 < cfields> sure, will do
09:36 -!- dgenr8 [~dgenr8@unaffiliated/dgenr8] has joined #bitcoin-core-dev
09:36  * wumpus just crashed a windows PC in the middle of initial sync, came back fine after reboot...
09:37 -!- dixson3 [~textual@cpe-72-182-110-15.austin.res.rr.com] has quit [Quit: Textual IRC Client: www.textualapp.com]
09:37 -!- dixson3 [~dixson3@cpe-72-182-110-15.austin.res.rr.com] has joined #bitcoin-core-dev
09:38 < wumpus> "NotMyFault: Use this executable and driver to crash your system in several different ways" lovely
09:42 -!- BashCo [~BashCo@unaffiliated/bashco] has quit [Remote host closed the connection]
09:44 -!- challisto [~challisto@unaffiliated/challisto] has quit [Quit: Leaving]
09:48 < wumpus> the only thing hard to reproduce with a laptop would be a direct power failure
09:51 < sipa> remove the battery :)
09:53 < wumpus> I'm not sure that's possible with this one without disassembling it
09:54 < wumpus> and not sure bitcoin core should be resilient to motherboard-bends-while-application-is-running crashes :-)
10:04 -!- goregrind [~goregrind@unaffiliated/goregrind] has quit [Ping timeout: 265 seconds]
10:05 -!- BashCo [~BashCo@unaffiliated/bashco] has joined #bitcoin-core-dev
10:10 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
10:16 -!- Thireus2 [~Thireus@icy.thireus.fr] has quit [Quit: Leaving.]
10:30 < wumpus> cfields: it worked! windows trusty build is now deterministic http://s7.postimg.org/bhrf0eui3/Naamloos.png
10:30 < cfields> woohoo :)
10:30 < cfields> but... wtf am i looking at?
10:31 < mcelrath> What's that usha256?
10:31 < wumpus> my hex-as-unicode-blockelements hack
10:32 < wumpus> (somewhat easier to compare patterns than letters/numbers)
10:33 < cfields> ah, neat
10:34 < wumpus> "Fout bij openen blokkendatabase" ah, this time I crashed windows and the block database got corrupted
10:35 < wumpus> usha256: https://gist.github.com/laanwj/3a142c48046ef862bf91
10:36 < helo> corrupted your error messages too! ;)
10:37 < zooko> wtf-8
10:38 < wumpus> lol zooko
10:38 < zooko> Seriously, what is this for ?
10:40 < zooko> Wow.
10:40 < zooko> Intriguing.
10:41 < mcelrath> I can't decide whether that's easier to differentiate or not. Better let the computer decide: sha256sum a b | awk '{print $1}' | uniq
10:43 < mcelrath> Also diff -q
10:48 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Ping timeout: 260 seconds]
10:52 < wumpus> mcelrath: what I don't like about that is that in the succesful case it provides no output, so I can never be sure whether it crashed (and hence produced no output) or succeeded
10:52 < mcelrath> What provides no output?
10:52 < wumpus> diff, when files match
10:53 < sipa> wumpus: how many such block elements are there?
10:54 < wumpus> sipa: I used the 16 2x2 ones to get 16 bits - but there are also e.g. 1/8th horizontal/vertical full ones, see https://en.wikipedia.org/wiki/Block_Elements
10:54 < wumpus> to get 4 bits*
10:55 < wumpus> and if you combine with reverse-video you can get even more, e.g. "right one eights block"
10:56 < wumpus> most console applications that use thsese, use them for progress bars/gauges etc
10:57 -!- Thireus [~Thireus@icy.thireus.fr] has joined #bitcoin-core-dev
10:59 < wumpus> you could also do a kind of Chernof faces visualization using emojis, esp. on mac consoles which render those silly things in color
11:07 -!- PaulCape_ [~PaulCapes@204.28.124.82] has quit [Quit: .]
11:08 -!- PaulCapestany [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
11:12 < wumpus> "2015-10-30 17:30:05 Corruption: error in middle of record" that's the error with the windows chainstate db after crash
11:14 -!- jl2012_ [~jl2012@119246245241.ctinets.com] has quit [Read error: Connection reset by peer]
11:14 -!- jl2012 [~jl2012@unaffiliated/jl2012] has joined #bitcoin-core-dev
11:15 < wumpus> this happens while reading the log, so it is a partial record error
11:15 < wumpus> partial write*
11:22 -!- rubensayshi [~ruben@91.206.81.13] has quit [Ping timeout: 240 seconds]
11:37 < wumpus> https://github.com/bitcoin/bitcoin/blob/master/src/leveldb/util/env_win.cc#L587  shouldn't the FlushFuleBuffers and FlushViewOfFile be the other way around?
11:37 < wumpus> the former syncs changes in the file to disk, the latter changes in the memory map to the file
11:37 < wumpus> I may be misunderstanding something of course...
11:39 < sipa> wumpus: that code may well be wrong
11:40  * wumpus wants to implement a WritableFile with just the win32 base file API and none of this fancy mapping stuff
11:40 < wumpus> like PosixWritableFile but for windows... oh wait, maybe I can even just copy PosixWritableFile and rely on mingw to do the rest for me
11:56 -!- CodeShark [~CodeShark@cpe-76-167-237-202.san.res.rr.com] has joined #bitcoin-core-dev
12:18 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has quit [Read error: Connection reset by peer]
12:19 -!- davec [~davec@cpe-24-243-251-52.hot.res.rr.com] has joined #bitcoin-core-dev
12:24 -!- zooko [~user@c-24-9-79-61.hsd1.co.comcast.net] has joined #bitcoin-core-dev
12:25 < GitHub92> [bitcoin] sipa opened pull request #6916: Remove BIP30 enforcement, as it is impossible to trigger since BIP34 (master...nobip30) https://github.com/bitcoin/bitcoin/pull/6916
12:26 < sipa> wumpus: we should do that, I think
12:55 < GitHub118> [bitcoin] sipa closed pull request #6916: Remove BIP30 enforcement, as it is impossible to trigger since BIP34 (master...nobip30) https://github.com/bitcoin/bitcoin/pull/6916
12:56 < gmaxwell> :)
12:58 < sipa> gmaxwell: i'm trying to think whether enforcing it for all blocks (except those two) that don't have BIP34 is safe
12:59 < sipa> as BIP34 is only sufficient when there are no actual duplicate coinbases
12:59 < sipa> but there are
12:59 < gmaxwell> sipa: if we ship a wad of the 32 least significant bits of the block hashes up to the height bip 34 activates; and then require that, that would be sufficient.
13:01 < sipa> that's not very different from a checkpoint...
13:02 < morcos> sipa: ok so i have an even stranger one for you
13:03 < morcos> when TestBlockValidity ends, between then and when control returns to CreateNewBlock, consistently takes 10-15 ms
13:03 < morcos> if you recently flushed your cache, i think this number can be 20-25 ms
13:04 < gmaxwell> sipa: checkpoints don't fix this, since the corruption can slip in between them.
13:04 < gmaxwell> is it spending 10-15ms in free? :)
13:04 < morcos> but i have no idea what if anything should be happening then, the CCoinsViewCache destructor runs, but what else
13:04 < morcos> gmaxwell: is that possible?
13:04 < sipa> and that destructor doesn't do anything...
13:05 < sipa> except deleting cacheCoins
13:05 < sipa> morcos: you could try to do a cacheCoins.clean() in the CCoinsViewCache destructor, and time that?
13:05 < morcos> ok
13:06 < sipa> or add a .Clean() method that dispatches to cacheCoins.clear()
13:06 < gmaxwell> morcos: it's possible e.g. freeing a kazillion and one tiny objects. I'd done some profiling in the past that suggested to me we were losing a lot of time in the allocator.
13:06 < sipa> #6914 should help there too
13:12 < morcos> yep, clearing the cache takes 10+ ms
13:13 < sipa> try with #6914 :)
13:13 < sipa> actually, it can at most give a 2x speedup
13:13 < morcos> now the confusing thing is it sometimes takes twice as long if pcoinsTip (the base cache, had recently been semi-flushed)
13:13 < morcos> i wonder if thats a memory thrashing thing,or it has something to do with the flags on those coins
13:24 < wumpus> replaced the leveldb win32 writable file, let's see how it goes https://github.com/laanwj/bitcoin/commit/86050deaabe7ca0a19db1c5a65e3174c9cb14511
13:25 < gmaxwell> \O/ always good to see a fix that removes a lot of code.
13:26 < wumpus> it is! it's extremely simple now, the only thing I'm not sure about is Sync() versus Flush(), they both do a sync to disk now
13:27 < wumpus> that's probably overkill but it cannot hurt either
13:31 < wumpus> going to let it sync a bit and then cause another IRQL_NOT_LESS error and see if it avoids ending up in broken state
13:32 < sipa> great!
13:32 < sipa> we don't need particularly good write performance, i guess
13:32 < sipa> as we mostly do batch writes
13:33 < morcos> gmaxwell: so the easy simple thing re: BIP 30 would to just be to disable it for blocks after a certain height right?  
13:34 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
13:34 < morcos> eh, never mind
13:35 < wumpus> agreed
13:35 < morcos> we could disable it for blocks that have a certain block as their ancestor
13:35 -!- zooko [~user@c-24-9-79-61.hsd1.co.comcast.net] has quit [Ping timeout: 252 seconds]
13:35 < morcos> such block being after BIP 34 and the pre existing duplicate coinbases diverged and were buried
13:35 < sipa> morcos: fundamentally, the bip30 check can be disabled for any transaction that depends on a bip34 coinbase
13:36 < gmaxwell> sipa: the existing BIP30 violations overwrote without proliferation.
13:36 < sipa> but there have been duplicated coinbases in the past, so there can be transactions that spend such a duplicate, which can become duplicated as well
13:36 < gmaxwell> meaning there can be no duplicate children.
13:36 < sipa> gmaxwell: if you know the chain
13:36 < sipa> you can be fed an alternative chain in which that's not the case
13:37 < sipa> no?
13:37 < morcos> right so if we only disable if you have an ancestor block which sufficietnly buries those, then you're good on the main chain
13:37 < gmaxwell> Right but we could enforce BIP30 for all chains until the point where BIP34 activates.
13:37 < morcos> andif you're fed an alternate chain you won't disable the check
13:37 < gmaxwell> oh I see if it proliferates its not enough.
13:37 < sipa> gmaxwell: BIP34 or not is not enough
13:38 < sipa> even post BIP34, a transaction that spends a previous duplicate coinbase is possible (in an alternative chain)
13:38 < sipa> so a checkpoint would work
13:38 < gmaxwell> yea, so we could disable BIP30 when BIP34 acitivates if and only if the the ancestor chain is the real one.
13:38 < morcos> yes, thats what i was trying to say
13:39 < morcos> thats the best kind of checkpoint it doesn't require you to actually be on the real chain, it just saves you some work if you are
13:39 < sipa> indeed
13:41 < gmaxwell> the constant ancestor tests are slightly annoying but much better than running bip30 everywhere.
13:44 < morcos> so erasing these caches is absurdly expensive.  sometimes its 40ms+ 
13:45 < morcos> but why is it higher shortly after the underlying cache has been erased, that i don't understand
13:45 < sipa> how many entries?
13:45 < morcos> the 10ms case was on the order of 5000 entries
13:46 < sipa> maybe we need a special throw-away-cache which uses an append-only pooled allocation
13:46 < sipa> ... though again, a per-txout cache would be better for that
13:46 < morcos> but the number of entries is irrelevant, its the number of txins in those entries i guess right?
13:46 < sipa> txouts
13:47 < morcos> yeah, 
13:58 < gmaxwell> what are the heap allocated objects in it? the entries themselves. scripts inside them (largely fixed by pieters alt-vector)? what else? 
13:58 -!- jtimon [~quassel@74.29.134.37.dynamic.jazztel.es] has quit [Remote host closed the connection]
13:59 < sipa> gmaxwell: one allocation in the hashmap per txid; for each txid there is one allocation for a vector of txouts; for each txout there is one allocation for the script (partially fixed by prevector)
14:00 < gmaxwell> interesting that we always load all the txouts but are still taking per-txout allocation overhead.
14:02 < gmaxwell> so in any case if transactions are tending to gather from many distinct txids, then you potentially have a huge blowup in allocations; it's e.g. two heap allocations for each txout, ... so if you gather from a 100 txout transaction there is 200 heap allocations for each txin that does that.
14:03 < gmaxwell> (well, 201) and pieter's vector thingy would reduce that to 101 heap allocations.
14:04 < gmaxwell> They're probably destroyed in the same order they're created, which is probably a fairly expensive order for malloc too.
14:05 < gmaxwell> as an aside, after thinking about the heap behavior; I would guess a non-trivial amount of the 'remove on replace' memory savings is ficticious.
14:06 < gmaxwell> Due to fragmentation.
14:08 < morcos> "remove on replace"?
14:09 < gmaxwell> attempts to remove cache entries for transactions evicted from the mempool.  Remove on reject is probably effective, since it's removing things it just added.
14:10 < morcos> ah yes, well the whole thing i'm trying to accomplish here is making that unnecessary
14:10 < morcos> if flushing the cache more often is doable (b/c you don't flush out the hot entries you're about to use)
14:10 < gmaxwell> sipa: so an append only arena that we can dump as a single operation would ... be a thing that could be done, _but_ it leaves us in a world were the only management thing we can do is flush() which would be unfortunate.
14:10 < morcos> then instead of worrying about what you're adding, just check far more often that you're not too big.  most of the time you wont' have new stuff to write to the DB anyway
14:11 < sipa> gmaxwell: it would be awesome for blocks, not for the mempool
14:11 < morcos> but for some reason, the cache clearing of the child cache is slower if you've done one of these controlled flushes on the parent cache (or a real full flush) right before you create the child cache
14:11 < morcos> that makes no sense to me
14:13 < gmaxwell> sipa: hm. even for blocks, say you process block 100 and read in transactions X,Y,Z. then you flush. Then block 101 needs transactions Y and Z again. I'm not sure how often that happens, but I would be that its way way more common than chance.
14:15 -!- ParadoxSpiral [~ParadoxSp@p508B8509.dip0.t-ipconnect.de] has quit [Remote host closed the connection]
14:15 < sipa> gmaxwell: i mean for the scripts in a block
14:16 < sipa> gmaxwell: the scriptSigs
14:16 < sipa> not talking about UTXO set or mempool
14:20 < gmaxwell> ah, indeed. you even have a nice figure on the size of the arena to allocate: just allocate the size of the block, and then it never needs to be realloced.
14:21 < sipa> even for a single transaction it's probably worth it
14:21 < sipa> as they're immutable
14:21 < sipa> hell, a whole transaction could be a single malloced block
14:22 < sipa> with some internal offsets/pointers in it
14:24 < gmaxwell> sipa: thats really what I'd prefer to see. I don't think having one allocation per transaction is unreasonable; but these nested allocations are goofy.
14:27 < gmaxwell> sipa: similar to that: AFAIK utxo cache entries cannot change in size. 
14:28 < sipa> individual txouts no; the per-tx ones can
14:30 < gmaxwell> sipa: why? the only operation is that they can have entries spent, but that can be a flag that doesn't require resizing the object.
14:31 < gmaxwell> (and the operation flushes the dirty part could resize the object when it does so, I suppose, as it will already have exclusive access to it, no?)
14:32 < sipa> gmaxwell: you want to remove the allocated scripts for spent entries, no?
14:33 < sipa> gmaxwell: otherwise a full in-memory sync from scratch needs memory for every UTXO every created, rather than a working set
14:33 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has joined #bitcoin-core-dev
14:34 < gmaxwell> sipa: not quite, if it's spent completely you just drop the object. So how much partially spent would there be?  Thats also an unusual case. In any case, it could trigger a rebuild at any time you have exclusive acccess. basically batching the malloc overhead. 
14:35 < sipa> you always have exclusive access
14:36 < gmaxwell> e.g. when you spend an entry you set a dity flag and increment a wasted bytes counter. Then if the wastes bytes are over X when you spend from it, you rebuild in place and realloc.
14:36 < wumpus> partial spent (of transaction outputs) are quite common
14:36 < wumpus> there are lots of transactions with many outputs
14:36 < gmaxwell> And if it's spent completely, you just free it.
14:37 < gmaxwell> but say a block spends the 100 outputs in order in a block, it makes no sense to resize the object 100 times and then free it.
14:38 < sipa> vectors never reallocate on shrink
14:38 < sipa> only on grow
14:39 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Ping timeout: 260 seconds]
14:39 < gmaxwell> sipa: With a vector we instead have 201 mallocs and 201 frees in that case. (and probably a few reallocs along the way)
14:40 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
14:41 -!- paveljanik [~paveljani@unaffiliated/paveljanik] has quit [Quit: Leaving]
14:41 < gmaxwell> where as if the cache entry is a single fixed size object, which never grows, and shrinks only in a deferred way when the amount of memory saved by shrinking would be non-trivial, it's 1 malloc, 1 free, and a few reallocs for shrinking along the way... and always in chunks large enough where its meaningful (e.g. where fragmentation doesn't prevent the freed memory from being used anyways).
14:43 < GitHub21> [bitcoin] laanwj opened pull request #6917: leveldb: Win32WritableFile without memory mapping (master...2015_10_leveldb_win_nomap) https://github.com/bitcoin/bitcoin/pull/6917
14:44 < wumpus> seems to have worked...
14:44 < gmaxwell> \O/
14:46 < gmaxwell> too bad the chainstate obfscuation is a bit invasive; it would be nice to have a 0.11.2 that fixes all known corruption issues for windows users.
14:47 < sipa> i think it's backportable
14:48 < wumpus> it's not too bad
14:49 < gmaxwell> (it wasn't that interesting to consider when the leveldb ones remained)
14:52 < gmaxwell> warren: if you want to do a bounty, instead of fixing windows (which wumpus just did, and we should send him flowers)-- perhaps the bounty we should ask for is this:  A NBD server that sakes an initial disk image file (compatible with loopback mount) and logs all writes to it, instead of actually writing them, and then applies the writes as a patch in memory (doesn't matter if uses lots of ram).
14:52 < gmaxwell>   Then it lets you restart it with a image + old log + N and it will truncate the last N writes off the old log.  This would let you construct a test harness where we start a node against an existing chain, sync one block, and shut down. Then attempt to restart with one write less. and so on, for every single write back to the first one, and make sure the node can restart at every point. 
14:54 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Quit: :)]
14:58 < wumpus> yes, that could be useful
15:03 < gmaxwell> without that kind of test harness I dunno how _anyone_ manages to write database software that actually works (well: answer, according to that usenix paper, they mostly just fail. :) )
15:04 < warren> gmaxwell: you might have convinced me that I shouldn't be spending personal income on bounties anymore, I'd be happy to specify it though =)
15:04 < warren> kanzure: ping
15:05 < kanzure> pong
15:05 < kanzure> for which thing have i been summoned?
15:07 < wumpus> there are a few debugging and reverse engineering tools that can rewind execution in memory, but I know of no file systems that can rewind/replay operations explicitly in fine granularity. You'd say that with journalling file systems it should be possible by truncating/rewinding the journal, but never been able to find reports of anyone doing that...
15:07 < gmaxwell> kanzure: ever seen people who own both a parrot and a dog, ... and the parrot will sometimes call the dog just to see it come?
15:07 < kanzure> there was a linux tool for replay but requires kernel module, does replay and rewind of execution state, very bizarre alien thing
15:07 < gmaxwell> wumpus: I wasted a bunch of time searching and could find nothing.  But it seems to me that this is probably only a few days work on top of a simplistic NBD server.
15:07 < kanzure> http://velvetpulse.com/2012/11/27/scribe-the-deterministic-transparent-record-replay-engine/
15:08 < kanzure> and maybe http://rr-project.org/ but more the last link
15:08 < wumpus> yes, for execution state for example pandare can do that
15:08 < kanzure> this could possibly be extended to windows vm things but w/e
15:08 < gmaxwell> RR is awesome, and can do this for execution state, but we need it for disk state seperate from execution. 
15:08 < kanzure> can't find pandare, please link?
15:09 < wumpus> but that's not really what we want here - we want to restart the application at every point of disk writing
15:09 < wumpus> kanzure: https://github.com/moyix/panda
15:09 < gmaxwell> I expect most of the work related to my NBD suggestion will be discovering that all filesystems are broken, and being unable to get results against bitcoin until the file systems are fixed. :(
15:09 < kanzure> yeah probably just write your own fusefs plugin or something
15:10 < kanzure> and ramfs with snapshotting or something
15:10  * kanzure handwaves
15:10 < gmaxwell> NBD is bascially the perfect interface for this. It is a remote block device whos primitives are "read this block" and "write this block"
15:11 < kanzure> "network block device"
15:11 < kanzure> i hope this isn't samba
15:11 < gmaxwell> so the code becomes  if read  check the log replay hashtable, no hits? go to the read only backing device. if hit return that.  if write, append log, and add to the hashtable.   On restart, replay old log into hashtable up to the cutoff point.
15:12 < wumpus> samba is not a network block device, but a network filesystem :)
15:12 < kanzure> (samba is many things)
15:14 < gmaxwell> the test harness is, mount the thing, sync a block. shut down. unmount. restart daemon with -1, mount, start daemon sync next block and record success, unmount, go back to the original oldlog, start with -2 ... and so on. for each offset. If there are a million writes made while syncing that first block, you restart a million times.   Once that starts failing, you change the behavior so that it 
15:14 < gmaxwell> turns the last write to line-noise... and try it again.
15:16 < gmaxwell> and then you know that, absent reordering at lower levels, there is no point where unclean termination can leave the state irrecoverable in the log-under-test. 
15:16 < gmaxwell> obviously this could model reordering too, if barriers get communicated across NBD (I dunno if they do)... but the state space becomes huge fast, so I think you could only try random cases, and not an exhaustive test.
15:18 < kanzure> warren: random pings in the future are much appreciated, thank you
15:19 < gmaxwell> wumpus: please post test binaries with the leveldb fix. 99.9% of windows users won't test from source.
15:20 < wumpus> the randomized brute force approach would be to crash, restart, crash, restart a VM running bitcoind in a loop, then a zillion times, trying to get it into a state where it won't recover
15:20 < GitHub91> [bitcoin] sipa opened pull request #6918: Make sigcache faster, more efficient, larger (master...smallsigcache) https://github.com/bitcoin/bitcoin/pull/6918
15:20 < wumpus> gmaxwell: maybe jonasschnelli would like to post executables; I don't have the infrastrcuture for that at the moment
15:20 < gmaxwell> sipa: "faster, stronger, better!"
15:21 < kanzure> you could selectively break parts of the vm maybe
15:21 < kanzure> e.g. increase unreliability of different system calls
15:23 < gmaxwell> sipa: hitrate could be improved further if you store the height at the time an entry is added the random eviction picks N entries and drops the one with the lowest height.
15:24 < gmaxwell> sipa: even with it 10x larger, hitrate for a transactions in the current mempool will not be 100% and thats nuts. 
15:25 -!- randy-waterhouse [~kiwigb@opentransactions/dev/randy-waterhouse] has quit [Quit: Leaving.]
15:26 < sipa> gmaxwell: around 99.3% hitrate on average for the last 8000 entries
15:28 < gmaxwell> so lets say the block has 2000 signatures drawn from the last 8000, and a 99.3% hitrate. So 14 misses.  If a verify takes 420 microseconds (as it does for openssl), then thats 6 ms added to block processing. 
15:28 < sipa> the last 1000 have 99.9% hitrate
15:29 < sipa> one way to do it would be to use a unordered_map to int64_t, which just increases sequentially
15:29 < sipa> and when removing, randomly find 4 entries and sort them by that number
15:29 < gmaxwell> or 1%-6% slowdown (depending on how much we speed up the rest of block processing).
15:29 < sipa> maintaining a fully ordered index adds a lot of memory
15:29 < gmaxwell> I was basically suggesting that but using height, because I think we actually want the oldest of the ones at the current height usually.
15:30 < sipa> otherwise we need to pass down height through several layers of code that are currently height-oblivious
15:30 < gmaxwell> so map to int32_t, with the height at insertion time. and then pull four entries and reject the lowest height. 
15:31 < gmaxwell> oh well meh, true. though block height advance is the magical event that should cause entries to become useless. Not age.
15:31 < sipa> we could make it wipe entries on block verify
15:31 < sipa> that's trivial
15:33 < gmaxwell> sounds even better. I think with that we could avoid increasing its memory usage, and stay at 10mb. 
15:34 < gmaxwell> sipa: if we can do that, then we could also have that same event trigger a counter that a block has been accepted, no?
15:34 < sipa> gmaxwell: it's a boolean passed down saying whether we want to store or not
15:34 < sipa> per entry
15:34 < phantomcircuit> er
15:34 < phantomcircuit>     bool Encrypt(const CKeyingMaterial& vchPlaintext, std::vector<unsigned char> &vchCiphertext);
15:35 < phantomcircuit> actually nvm
15:35 < phantomcircuit> i had them reversed in my brain
15:36 < gmaxwell> sipa: the eviction is probably enough, though it still has a bias towards the more recent inserts rather than a bias towards preserving the oldest inserts which are since the prior block.
15:36 < sipa> gmaxwell: meh
15:37 < gmaxwell> I don't think it matters much, but evict on verify will make that sighash single trick for spending dustspam slow to verify.
15:41 < gmaxwell> sipa: what is the average hit rate for a transactions 6000 to 8000 ago?
15:42 < phantomcircuit> gmaxwell, to verify that im reading this right, each time an encrypted wallet is unlocked the first key in mapCryptedKeys is checked against it's pubkey and the first time the wallet is unlocked all of the keys are checked against their pubkey, correct?
15:44 < gmaxwell> phantomcircuit: thats my recollection of what it does, yes.
15:45 < gmaxwell> it's a slow and not very good test-- the problem, of course, is you get no verification at all if the wallet is never unlocked.
15:45 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has quit [Remote host closed the connection]
15:45 -!- [b__b] [~b__b]@ec2-54-85-45-223.compute-1.amazonaws.com] has joined #bitcoin-core-dev
15:46 < phantomcircuit> gmaxwell, right
15:46 < phantomcircuit> how about make a list for eviction and evict only when a block is completely verified?
15:47 < gmaxwell> phantomcircuit: complicated and screws up the layering.
15:47 < gmaxwell> phantomcircuit: I'd rather have a hash basked check that stays with the key, and gets checked on load and any time its used.
15:48 < phantomcircuit> gmaxwell, no i meant for the sigcache thing
15:48 < gmaxwell> phantomcircuit: I know, mutiple threads of discussion.
15:48 < sipa> phantomcircuit: complicated and screws up the layering :)
15:48 < sipa> phantomcircuit: the sigcache code doesn't know about a 'block' concept at all
15:49 < gmaxwell> sipa: I don't see why the sigcache couldn't just have a counter in it, and every time you verify a block you take a lock on the sigcache and increment that counter.  And the current counter value rides with the entries in an ordered map, and does the biased eviction I suggested.
15:50 < sipa> gmaxwell: perfectly doable
15:50 < gmaxwell> that won't require passing anything height around, it's not hight anymore then, it's just 'sigcache epoch'
15:50 < sipa> going to benchmark without it to see how large the sigcache actually gets
15:51 < gmaxwell> well it will get to the maximum size, since there is no eviction except on full. :)
15:52 < sipa> with the evict-when-seen-in-block rule
15:54 < phantomcircuit> gmaxwell, heh
15:54 < gmaxwell> k, that does have that patalogical performance I mentioned. sadly I don't see a nice way to fix that, except perhaps having a one entry FIFO for the last evicted item.
15:55 < sipa> gmaxwell: hmm, what pathological performance?
15:56 < gmaxwell> sipa: There is, for example, a block with a 1MB tx of SIGHASH_SINGLE bug using transactions that have all the same signature.   If it's cached its almost instant to verify ... otherwise....
15:57 < sipa> oh!
15:57 < gmaxwell> similar OP_DUP2 CHECKSIG OP_DUP2 CHECKSIG ... (or checkmultisig with the same pubkey).
15:58 -!- belcher [~user@unaffiliated/belcher] has joined #bitcoin-core-dev
16:03 < phantomcircuit> we still end up calling SignatureHash even with the sigcache right?
16:04 < sipa> yes
16:05 < phantomcircuit> any reason CryptedKeyMap is in keystore.h instead of src/wallet/crypter.h ? (it's not used anywhere outside of src/wallet/crypter.{h,cpp})
16:06 < sipa> nope
16:06 < sipa> CKeyStore itself should move to script/sign.h
16:06 < sipa> CBasicKeyStore can stay
16:06 < sipa> and CCryptoKeyStore can indeed move to wallet/crypter
16:12 < phantomcircuit> gmaxwell, also yes that was my basic plan for adding hashing for ckey entries
16:22 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Read error: Connection reset by peer]
16:22 -!- danielsocials [~quassel@45.32.248.113] has joined #bitcoin-core-dev
16:22 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has joined #bitcoin-core-dev
16:34 < GitHub83> [bitcoin] laanwj closed pull request #6893: forward-declare univalue in rpcclient + remove include in rpcserver.cpp (master...univalue) https://github.com/bitcoin/bitcoin/pull/6893
16:37 -!- zooko [~user@c-73-14-173-69.hsd1.co.comcast.net] has quit [Ping timeout: 240 seconds]
16:38 < GitHub43> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/725539ea0376...d482c0a7b246
16:38 < GitHub43> bitcoin/master e9e6163 Pieter Wuille: Make -checkmempool=1 not fail through int32 overflow
16:38 < GitHub43> bitcoin/master d482c0a Wladimir J. van der Laan: Merge pull request #6896...
16:39 < GitHub192> [bitcoin] laanwj closed pull request #6896: Make -checkmempool=1 not fail through int32 overflow (master...fixchainsize) https://github.com/bitcoin/bitcoin/pull/6896
16:40 < GitHub164> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/d482c0a7b246...48b5b84ee511
16:40 < GitHub164> bitcoin/master 30d9662 Gregory Maxwell: Reject invalid pubkeys when reading ckey items from the wallet....
16:40 < GitHub164> bitcoin/master 48b5b84 Wladimir J. van der Laan: Merge pull request #6906...
16:40 < GitHub146> [bitcoin] laanwj closed pull request #6906: Reject invalid pubkeys when reading ckey items from the wallet. (master...ckey_pubkey_check) https://github.com/bitcoin/bitcoin/pull/6906
16:46 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
16:47 -!- danielsocials [~quassel@45.32.248.113] has quit [Ping timeout: 244 seconds]
16:48 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
16:49 < dcousens> sipa: don't mind my nits
16:49 < sipa> dcousens: you're welcome to ask questions :)
16:50 < dcousens> PR is super clean, the only semantics that weren't clear to me was the logic around `store`
16:52 < dcousens> What does it represent? A data 'store', or, whether to allow the sigCache to be used?
16:52 < sipa> store==true is set for mempool transactions, store==false is set for block validation
16:53 < sipa> the original intent was that we wouldn't store validations done during block validation, only query the cache
16:54 < dcousens> So the current usage is whether or not it should use a cache at all
16:54 < sipa> no
16:54 < sipa> with store==false, the cache is still queried; the result of validation is just not stored
16:54 < dcousens> But the cache would be empty no?
16:56 < dcousens> The set only gets inserted into if `store == true`
16:56 < sipa> it gets filled by mempool validations
16:56 < sipa> and queried for block validations
16:56 -!- PaulCape_ [~PaulCapes@204.28.124.82] has joined #bitcoin-core-dev
16:56 < dcousens> AH
16:56 < dcousens> bloody inline statics
16:56 < dcousens> sorry, missed the static
16:56 < dcousens> That makes sense now
16:57 < dcousens> Though signatureCache was a member of CachingTransactionSignatureChecker
16:57 < dcousens> Thought*
16:59 -!- PaulCapestany [~PaulCapes@204.28.124.82] has quit [Ping timeout: 264 seconds]
16:59 < dcousens> I'm too used to just never having globals haha, anyway, cheers for answering questions :)
17:00 < dcousens> explains the locking too
17:07 -!- sipa [~pw@unaffiliated/sipa1024] has quit [Ping timeout: 256 seconds]
18:29 -!- diegoviola [~diego@unaffiliated/diegoviola] has joined #bitcoin-core-dev
18:29 < diegoviola> heya
18:29 < diegoviola> will bitcoin core implement SPV like electrum and seeds?
18:29 < diegoviola> I'd like to use core but I can't afford to download the whole blockchain
18:29 < diegoviola> my connection sucks
18:29 < diegoviola> my internet is only 1mb
18:29 < diegoviola> :-(
18:30 < belcher> once you have it all downloaded and verified you wont use much bandwidth at all
18:30 < diegoviola> sure but will take days to download it
18:31 < belcher> oh damn this channel, didnt realise, ask in #bitcoin
18:31 < diegoviola> k
18:33 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has quit [Quit: Lost terminal]
18:40 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has quit [Quit: WeeChat 1.4-dev]
18:45 -!- ghtdak [~ghtdak@unaffiliated/ghtdak] has joined #bitcoin-core-dev
19:08 -!- Arnavion [arnavion@unaffiliated/arnavion] has quit [Quit: Arnavion]
19:09 -!- Arnavion [arnavion@unaffiliated/arnavion] has joined #bitcoin-core-dev
19:43 -!- diego2 [~diego@191.23.50.56] has joined #bitcoin-core-dev
19:43 -!- diego2 [~diego@191.23.50.56] has quit [Changing host]
19:43 -!- diego2 [~diego@unaffiliated/diegoviola] has joined #bitcoin-core-dev
19:43 -!- diegoviola is now known as Guest20844
19:43 -!- diego2 is now known as diegoviola
19:45 -!- Guest20844 [~diego@unaffiliated/diegoviola] has quit [Ping timeout: 250 seconds]
20:20 -!- diego2 [~diego@177.188.89.16] has joined #bitcoin-core-dev
20:20 -!- diego2 [~diego@177.188.89.16] has quit [Changing host]
20:20 -!- diego2 [~diego@unaffiliated/diegoviola] has joined #bitcoin-core-dev
20:20 -!- diegoviola is now known as Guest32811
20:20 -!- diego2 is now known as diegoviola
20:21 -!- Guest32811 [~diego@unaffiliated/diegoviola] has quit [Ping timeout: 260 seconds]
20:27 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has quit [Read error: Connection reset by peer]
20:28 -!- diego2 [~diego@200-100-141-46.dial-up.telesp.net.br] has joined #bitcoin-core-dev
20:28 -!- diegoviola [~diego@unaffiliated/diegoviola] has quit [Ping timeout: 250 seconds]
20:28 -!- diego2 [~diego@200-100-141-46.dial-up.telesp.net.br] has quit [Changing host]
20:28 -!- diego2 [~diego@unaffiliated/diegoviola] has joined #bitcoin-core-dev
20:28 -!- diego2 is now known as diegoviola
20:44 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-wfteurwcahvxprlc] has quit [Quit: Connection closed for inactivity]
20:45 -!- diegoviola [~diego@unaffiliated/diegoviola] has quit [Ping timeout: 240 seconds]
21:12 -!- belcher [~user@unaffiliated/belcher] has quit [Quit: Leaving]
21:19 < phantomcircuit> gmaxwell, that's interesting, it looks like if we fail to load a key from the wallet we exit without writing anything to the log
21:23 < phantomcircuit> oh nvm...
22:13 -!- dcousens [~anon@c110-22-219-15.sunsh4.vic.optusnet.com.au] has joined #bitcoin-core-dev
23:16 < dcousens> morcos: still intending to help with those stats, just waiting for a re-index to finish
23:52 -!- evoskuil [~evoskuil@c-73-225-134-208.hsd1.wa.comcast.net] has joined #bitcoin-core-dev
23:56 -!- ParadoxSpiral [~ParadoxSp@p508B8237.dip0.t-ipconnect.de] has joined #bitcoin-core-dev