--- Day changed Sat Feb 25 2017 00:00 < sipa> there may be more user-friendly things to do in some cases, but it's very hard... allocation failures can occur pretty much everywhere, and it seems really hard to avoid inconsistent states 00:00 < wumpus> sure, it's difficult 00:00 < wumpus> but this just feels like giving up on any kind of sane error handling 00:01 < sipa> i don't think so... OOM is different from disk errors, for example 00:01 < sipa> you can cleanly recover from that, usually 00:01 < wumpus> I really dislike global handlers like this, and I don't think much software uses this 00:01 < wumpus> it just changes the expectation of the c++ standard that allocations return an exception 00:02 < wumpus> which is adding surprising behavior at a low level 00:04 < sipa> i'm surprised to read that 00:04 < gmaxwell> on many systems allocation failures are just silently ignored and the program just crashes when it tries to use the memory. 00:04 -!- zrts_ [~z418@unaffiliated/zrts] has joined #bitcoin-core-dev 00:04 < sipa> i think that most software just doesn't try to catch bad_alloc 00:05 < sipa> and it just crashes 00:05 < gmaxwell> In virtually none of the software could an allocation even possibly be handled, esp as almost everything we do involves allocation. 00:05 < wumpus> ok ,never mind 00:06 < wumpus> seems you all agree, just do this 00:06 < gmaxwell> but I agree that just fixing the badalloc is not a full solution. What about other exceptions? If bad alloc can cause spurrious block invalidations how long until the next thing. 00:07 < sipa> well, i think we should get rid of the catch std::exception and catch ... everywhere 00:07 < wumpus> yes if the code is not exception-safe, that should be addressed 00:07 < sipa> and only catch expected exceptions 00:07 < gmaxwell> So I am of the opinion that bad alloc should just crash but also that the software needs to deal better with unexpected exceptions in block validation... as I mentioned before this is the third case of exceptions causing bogus block rejection that we've had. 00:07 < sipa> but by doing that, we'd still just crash in case of an OOM 00:08 < sipa> at least with this PR, we write to debug.log what happened 00:08 < wumpus> but unlike AbortNode() no attempt is made to show a dialog to the user 00:08 < gmaxwell> can't show a dialog without allocating. 00:09 < sipa> well in many cases, that would be possible 00:09 < wumpus> well the point is: maybe it needs less allocation than the original allocation request 00:09 < wumpus> not all allocations are equal 00:09 < sipa> indeed 00:09 < sipa> typically those that trip an OOM are large ones 00:09 < wumpus> someone might be trying to allocate a 4GB buffer, which fails, then after that the program could continue keeping in mind that it can't have that buffer 00:09 < gmaxwell> That is a fair point. Also if it did something like shut down the mempool it might free enough to display a message. 00:10 < gmaxwell> I wonder what the distribution of vm_overcommit settings is, it used to be ubiquitious, the fact that sipa even saw this suggests that it isn't anymore. 00:11 < sipa> for this specific issue, it may be possible to catch the bad_alloc inside the leveldb wrapper, and if so, mark the db object as read-only 00:11 < gmaxwell> apparently some hurestic is now the default. 00:11 < wumpus> in many cases showing a simple modal dialog woudl still work, especially on windows where it's sort of a direct sytem operation. It should at least we attempted 00:11 < sipa> that's fair 00:11 < sipa> but i think it requires too many changes for 0.14 00:11 < gmaxwell> I have no issue with that, so long as if it fails the system still shuts down. 00:11 < wumpus> and we have a general 'A fatal issuee has occured check debug.log' already in AbortNode 00:12 < sipa> i really want to think harder about possible inconsistent states 00:12 < wumpus> well an allocation failure in qt will just propagate the std::alloc_error 00:12 < wumpus> qt is exception safe 00:12 < gmaxwell> sipa: I'm kinda surprised that cfield's patch works. IIRC from gdbing boost asio it used to try to allocate 4TB of memory and the fail. I'm surprised nothing else in boost does. 00:12 < wumpus> so just catch that and abort() if there is one 00:13 < sipa> gmaxwell: it's c++11 00:13 < sipa> boost does not assume c++11 00:13 < sipa> for example, do we want to prevent writing to mempool.dat after some unhandled system error, to prevent corrupting it? 00:14 < wumpus> yes 00:14 < sipa> if catching of the exception occurs higher up, there is less risk of those things 00:14 -!- chjj [~chjj@unaffiliated/chjj] has quit [Ping timeout: 255 seconds] 00:14 < sipa> but what about writes that happen in unrelated background threads 00:14 < sipa> the wallet gets flushed in a background thread 00:14 < wumpus> set a flag and don't flush anything anymore 00:14 < wumpus> I mean all the databases are atomic right? 00:15 < wumpus> you can call writes, and as long as you don't flush, they'll be ignored on shutdown 00:15 < sipa> but a flag where? an exception can only propagate up to its threads' main function 00:15 < wumpus> a global flag 00:15 < wumpus> checked before each database flag 00:15 < wumpus> flush* 00:16 < sipa> if an OOM occurs inside the background runner thread, it will - if uncaught - just kill the background runner 00:16 < wumpus> a kind of alarm state, which makes sure nothing is permanently committed 00:16 < wumpus> catch the exception and call a handler to set that flag? 00:16 < sipa> that's really ugly... 00:17 < wumpus> why is that ugly? you should catch exceptions such as std::alloc anyway to warn the user, log something , and initiaite shutdown 00:17 < sipa> doesn't leveldb have some background writer thread? 00:17 < wumpus> why is leveldb's background thread a problem here? 00:18 < wumpus> we're concerned with corruptions of our own state, right? 00:18 < wumpus> leveldb won't be writing anything that we haven't committed 00:18 < wumpus> so as soon as there is the suspicion of inconsistent state, don't write anything to leveldb anymore 00:20 < sipa> i'm worried about an OOM caused by a thread we don't control 00:20 < wumpus> then the inconsistent state won't be committed to disk, and leveldb should be fine. Same for the wallet 00:20 < sipa> but i assume that would just cause a crash, as we can't catch a bad_alloc there anyway 00:21 < wumpus> well yes the writer thread could die in the middle of writing, sure, but there's no way to avoid that. The database needs t obe able to handle that, also for other crash robustness 00:22 < wumpus> what it won't do, however, is write inconsistent state if we haven't told it to 00:22 < sipa> yes, indeed 00:23 < sipa> i think you're right - with some changes it may be possible to do this safely 00:23 < sipa> if we make sure there is no code that may unintentionally catch a bad_alloc 00:24 < wumpus> right 00:24 < sipa> and that all the catches that do, also call AbortNode, which sets this flag 00:24 < wumpus> I think there should be a rule: if you catch a general std::exception, you can't continue there, and need to stop the program 00:24 < wumpus> as you have no idea what kind of error you have and whether it's recoverable 00:24 < sipa> right 00:24 < wumpus> (so that's for top-level handlers only) 00:25 < sipa> we have 53 places where std::exception is caught 00:26 < sipa> and 22 where ... is caught (even worse, as you can't even inspect the object) 00:26 < wumpus> the ptential worry is in the networking code... some parsing problems throw exceptions, we need to be really sure to catch them and continue otherwise there's a DoS 00:26 < wumpus> e.g. serialization throws std::runtime_error instead of something specific 00:27 < sipa> serialization throws std::ios_base 00:27 < sipa> serialization throws std::ios_base::failure 00:27 < wumpus> okay That's always an i/o error. Better than I thought 00:28 < sipa> there are some other things that can throw that 00:28 < wumpus> catching that and just reporting it and continuing in the network code would be ok 00:28 < sipa> network code or net_handling? 00:29 -!- panicstr [~panicstr@89-233-121-180.dynamic.t-2.net] has joined #bitcoin-core-dev 00:29 < sipa> net handling should catch serialization failures, and disconnect the offending peer 00:29 < wumpus> well the packet processing. It should make sure that one node is disconnected and not thewhole program comes tumbling down 00:29 < wumpus> yes 00:29 < sipa> right 00:29 < sipa> in fact, it's that except catch this is the culprit here 00:30 < sipa> *that exact 00:30 < wumpus> right, it should be more specific 00:30 < wumpus> catching ios::base and potentially a few others instead of std::exception would go a long way 00:30 < sipa> agree 00:33 < wumpus> and some exceptions like std::bad_alloc should initiate a quick shutdown. It could still be a DoS, but the program is probably in such a bad state when it happens that continuing with the other nodes is hopeless. 00:33 < wumpus> (though theoretically it could stil be a botched alloc due to the remote peer specifying a very large buffer which would never occur in reality) 00:36 < wumpus> so I guess uploading executables for rc2 is no longer necessary and we should merge #9856 and do rc3? 00:36 < gribble> https://github.com/bitcoin/bitcoin/issues/9856 | Terminate immediately when allocation fails by theuni · Pull Request #9856 · bitcoin/bitcoin · GitHub 00:42 < wumpus> speaking about memory usage: another report of running out of memory with 0.14. #9857 00:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9857 | Sync problem crashes Bitcoin: EXCEPTION: St9bad_alloc · Issue #9857 · bitcoin/bitcoin · GitHub 00:43 < wumpus> maybe 0.14 increased steady-state memory usage? 00:49 < sipa> maybe 00:49 < sipa> the reuse of mempool memory by coincache may contribute to it 00:49 < sipa> though that doesn't affect worst-case memory usage, it may increase the average 00:50 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 00:50 < sipa> for RPi we should recommend lowering the default settings, i'm afraid 00:51 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 00:56 < wumpus> bah, what really helps when creating a gdb parachute is propagating the exit code, if not it will just always return success https://github.com/bitcoin/bitcoin/pull/9851/commits/6d7a789fb510d540906955c377143b92acb1fbb6 . Forgot this and might have been spinning for nothing for a while :p 01:05 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 01:07 < wumpus> uhm. Caught that issue in the act now. Unfortunately, the traceback is useless. Gdb near-crashes while generating it! 01:07 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 01:07 -!- nabu [~jm@5.157.7.130] has joined #bitcoin-core-dev 01:07 -!- nabu [~jm@5.157.7.130] has quit [Client Quit] 01:07 < wumpus> "Error while running hook_stop: Cannot access memory at address 0x24" 01:08 < wumpus> okay, so much for gdb... 01:11 < wumpus> that leaves trying to make it cough up a core dump, and uploading that somewhere... 01:12 < jeremyrubin> wumpus: cuckoocache in theory may have increase memory usage a bit 01:13 < jeremyrubin> (if you're curious for all steadystate memory usage increases) 01:13 < wumpus> by how much? 01:13 < jeremyrubin> unclear 01:14 < jeremyrubin> it always uses 100% of whatever's it's allocated 01:14 < jeremyrubin> whereas the previous one only uses space when it has entries (in theory) 01:14 < sipa> the default max is 32 MB instead of 40 MB though 01:14 < sipa> so at peak, it's smaller 01:14 < jeremyrubin> so at startup, would be using 32 MB whereas the prior was 0 01:15 < jeremyrubin> it's just unclear how long you have to be on the network to experience a full cache w/ old code 01:16 < jeremyrubin> anyways I'm pretty sure this isn't the cause :) 01:17 < sipa> 1GB of memory is not much 01:18 < wumpus> indeed, runninga node with 1GB of memory has always required tweaking 01:18 < sipa> it's more surprising to me that 0.13.2 worked, though 01:18 < sipa> he's even reducing dbcache 01:18 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 268 seconds] 01:19 < wumpus> I do see increased reporting of out-of-memory errors with 0.14 01:19 < jeremyrubin> yeah, totally could be the sigcache, could definitely put someone over-edge 01:19 < jeremyrubin> especially if they set the value higher 01:19 < jeremyrubin> e.g., 128 mb 01:20 < jeremyrubin> prior version you could set it to a GB and run happily for a while 01:20 < wumpus> they don't touch that setting, just dbcache 01:20 < wumpus> possibly they should. We should update the recommedations for low-memory nodes. 01:21 < jeremyrubin> I don't think practically they'd need to adjust it down, just be less agressive adjusting it up -- not much benefit in making it too large 01:22 < jeremyrubin> Can we (by any chance) fast track sipa's hack to get cuckoocache back to be non pow 2? 01:23 < jeremyrubin> it sucks if they're picking between 8 16 32 MB sizes, some more resolution there would be good 01:23 < wumpus> which # is that? 01:24 < jeremyrubin> #9533 01:24 < gribble> https://github.com/bitcoin/bitcoin/issues/9533 | Allow non-power-of-2 signature cache sizes by sipa · Pull Request #9533 · bitcoin/bitcoin · GitHub 01:26 < wumpus> jeremyrubin: would help to have more than a concept ACK there from you 01:26 < jeremyrubin> k I'll do some more thorough review 01:26 < wumpus> thanks 01:28 < wumpus> also like gmaxwell I wonder what the performance difference would be, 8 multiplication would be slower than 8 logical AND 01:31 < jeremyrubin> I'm not currently set up to run great performance tests currently (will take some work to reset up my benching environment) 01:31 < jeremyrubin> But honestly performance was fine even when it was % 01:32 < wumpus> 'fine' hehe 01:32 < jeremyrubin> *shrug* 01:32 < sipa> jeremyrubin: i'm sure that for the sigcache it doesn't matter 01:32 < sipa> but maybe it does for other things in the future 01:32 < wumpus> well it's obviously a compromise between memory usage and performance 01:32 < jeremyrubin> I mostly changed it to hash_mask to make sipa happy :p 01:33 < wumpus> neither '&' or '* >>' is 'better', but we need to be careful what to choose 01:33 < sipa> well you violated the core tenet of never using integer division by a variable! 01:33 < sipa> it invokes the wrath of maxwell 01:33 < jeremyrubin> It was checked to not be 0 ;) 01:33 < jeremyrubin> anyways... 01:34 < wumpus> division? where? 01:34 < jeremyrubin> (old version of cuckoocache used % in the hash computation) 01:34 < wumpus> I saw only multiplies, if there's a division, I'm going to NACK this one 01:34 < wumpus> ooh :p 01:35 < sipa> and that PR brings back the flexibility of variable sizes, but with a * and a >> instead of a % 01:35 < jeremyrubin> I recall benchmarking and not being able to see a difference between %, &, >> 01:35 < wumpus> yes using % would be more straightforward code readability wise but division is even worse than multiplication 01:35 < jeremyrubin> yeah 01:35 < jeremyrubin> so I think it's fairly safe to take this one. 01:36 < wumpus> yes 01:36 < jeremyrubin> My one suggestion sipa is to convert size to a uint64_t 01:36 < jeremyrubin> like the member 01:36 < jeremyrubin> so you can get rid of all the casts in the hash part 01:36 < wumpus> would this result in more efficient code on 32-bit though? 01:36 < wumpus> as it guarantees that the top bits are zero 01:36 < jeremyrubin> I'm not sure 01:37 < jeremyrubin> but they have to be cast to uint64_t in hashing part now 01:37 < jeremyrubin> so my thought is not having to do that cast every hash is slightly more efficient code 01:37 < wumpus> casts don't generally generate code 01:37 -!- panicstr [~panicstr@89-233-121-180.dynamic.t-2.net] has quit [Ping timeout: 255 seconds] 01:37 < jeremyrubin> uint32_t to uint64_t even? 01:37 < jeremyrubin> there are instructions that auto-0 it to the alu? 01:38 < jeremyrubin> that's fine then 01:38 < wumpus> no. on 32-bit, it just means 'assume top bits are 0'. On 64 bit evrything is stored in 64-bit registers and the top bits are always 0 01:38 < jeremyrubin> cool, then that's fine as is 01:38 < wumpus> at least on x86_64 you can't load something into the lower 32 bits without zeroing the upper bits 01:39 < jeremyrubin> I'd consider it an Ack from me then. 01:39 < jeremyrubin> The tests are pretty agressive on cuckoocache, so if the hashing idea were broken in some way it would either catch it or it would be broken in a very minor way. 01:40 < wumpus> of course the considereations depend on the specific architecture, but in general casts are very cheap or generate no extra code at all especially between big types. Arithmetic with 8-bit and 16-bit values can result in extra 'ANDs' in some architectures you're right 01:40 < wumpus> but then it's not so much the cast that generates the code 01:40 < wumpus> yes, having good tests is great! 01:41 < wumpus> the state of testing in bitcoin core improved a lot last year 01:42 < jeremyrubin> *cough* merge my checkqueue tests *cough* :P 01:42 < wumpus> which reminds me I should merge #9847 01:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9847 | Extra test vector for BIP32 by sipa · Pull Request #9847 · bitcoin/bitcoin · GitHub 01:42 < wumpus> jeremyrubin: oh, aren't they yet? 01:42 < jeremyrubin> #9497 01:42 < gribble> https://github.com/bitcoin/bitcoin/issues/9497 | CCheckQueue Unit Tests by JeremyRubin · Pull Request #9497 · bitcoin/bitcoin · GitHub 01:42 < wumpus> usually test-only pulls are merged very quickly 01:43 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has quit [Remote host closed the connection] 01:43 < wumpus> then again I cannot really keep up anymore with the volume of pulls 01:43 < jeremyrubin> It's actually fine that they weren't, I found a mixed up loop condition (such that one test wasn't doing much) when I was sitting with kalle 01:43 < wumpus> which is good and bad 01:43 < bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f19afdbfb4cb...6206252e5073 01:43 < bitcoin-git> bitcoin/master 30aedcb Pieter Wuille: BIP32 extra test vector 01:44 < bitcoin-git> bitcoin/master 6206252 Wladimir J. van der Laan: Merge #9847: Extra test vector for BIP32... 01:44 < sipa> but division is even worse than multiplication -> nehalem can issue a 64-bit mul every 2 cycles; a division every 19-69 cycles 01:44 -!- d9b4bef9 [~d9b4bef9@web419.webfaction.com] has joined #bitcoin-core-dev 01:44 < jeremyrubin> But that's all fixed now 01:44 < bitcoin-git> [bitcoin] laanwj closed pull request #9847: Extra test vector for BIP32 (master...bip32up) https://github.com/bitcoin/bitcoin/pull/9847 01:44 < wumpus> sipa: yeah, that would classify as 'bad' in my eyes :) 01:44 < sipa> wumpus: the mul or the div? 01:44 < wumpus> the div 01:44 < jeremyrubin> nehalem? 01:44 < sipa> yes, absolutely 01:45 < sipa> but 'even worse' sounds like multiplication is already pretty bad... every 2 cycles is pretty good i'd say :) 01:45 < wumpus> divs have historically been really bad, some CPUs don't even have a specific instruction for it, but even those that have it's generally terrible 01:45 < wumpus> because of the underlying computational structure of course, not because those CPUs are badly implemented or so :) 01:45 < jeremyrubin> ah, nehalem: an intel arch name I'd thoroughly forgotten :) 01:46 < wumpus> 2 cycles is pretty good, espeically if it's *every* 2 cycles 01:46 < jeremyrubin> and that hash routine should pipeline well 01:46 < sipa> the latency is higher than 2 cycles 01:46 < wumpus> usually mul is quite quick but the number of multiplication units is limited, so issuing a lot will bottleneck on that 01:47 < wumpus> but not on nehalem, apparently :) 01:47 < sipa> but the throughput is once every 2 cycles 01:47 < sipa> same on skylaky, btw 01:47 < wumpus> what would be the throughput for logical and? 01:47 < sipa> 0.5 or 1, depending on the type of inputs 01:47 < wumpus> can't be much faster than per 2 cycles 01:47 < wumpus> oh! 01:48 < sipa> 0.25 for and with a constant, even 01:48 < sipa> http://www.agner.org/optimize/instruction_tables.pdf 01:48 < wumpus> modern CPU architectures are so fast we can almost ignore computation overhead. Too bad memory didn't keep up :) 01:48 < jeremyrubin> Also if you want to really make that hashing faster, could switch to balke2b or something 01:49 < wumpus> sipa: thanks , that seems like a very useful document 01:50 < jeremyrubin> wumpus: +1 thanks! 01:50 < sipa> LOCK ADD... 18 cycles! 01:51 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-isyvpwmrteiheaba] has joined #bitcoin-core-dev 01:53 < wumpus> ieeeh 01:57 < jeremyrubin> so I'm trying to write some test software 01:57 < jeremyrubin> and I want to force segwit active 01:58 < jeremyrubin> seems that isn't trivial to do? 01:58 < sipa> regtest? 01:59 < jeremyrubin> it seems to still require some blocks to vote for it before it can be made active? 01:59 < sipa> yes 01:59 < sipa> 3*144 blocks 02:00 < jeremyrubin> hmm... would be kinda nice to not have to do that, similar to how I can set BIPxxxHeight = 0. 02:01 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 02:06 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 02:08 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-dlcwxtutegzbjliz] has quit [Quit: Connection closed for inactivity] 02:14 < jeremyrubin> would it be safe to change VersionBitsState to read VersionBitsDeploymentInfo for an override state parameter? 02:17 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 02:19 < jeremyrubin> no I guess I'd neet to change GetStateFor 02:19 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 02:34 -!- Squidicc [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has joined #bitcoin-core-dev 02:34 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 02:36 -!- Squidicuz [~squid@pool-173-48-116-49.bstnma.fios.verizon.net] has quit [Ping timeout: 240 seconds] 02:36 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 02:39 -!- nohup [4445a482@gateway/web/freenode/ip.68.69.164.130] has quit [Quit: Page closed] 02:46 -!- Victor_sueca is now known as Victorsueca 02:50 -!- panicstr [~panicstr@89-233-121-180.dynamic.t-2.net] has joined #bitcoin-core-dev 03:01 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds] 03:08 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has left #bitcoin-core-dev [] 03:22 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has joined #bitcoin-core-dev 03:35 -!- panicstr [~panicstr@89-233-121-180.dynamic.t-2.net] has quit [Ping timeout: 260 seconds] 03:56 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 04:05 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 04:06 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 04:13 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:14 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has joined #bitcoin-core-dev 04:14 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has quit [Changing host] 04:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:17 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 04:18 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has joined #bitcoin-core-dev 04:18 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has quit [Changing host] 04:18 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 04:29 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 04:31 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer] 04:33 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 04:42 < btcdrak> jeremyrubin you could just turn down the number of blocks required on regtest from 144 to something lower like 10. 04:51 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 260 seconds] 05:01 -!- jl2012 [uid133844@gateway/web/irccloud.com/x-fbyzahebpztwxlzk] has joined #bitcoin-core-dev 05:28 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 05:28 -!- Aaronvan_ [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has joined #bitcoin-core-dev 05:54 -!- vFSgrcFGBJHg [~rYUtdcvYT@2a02:2f0a:b050:eea:934a:6abb:750c:602c] has joined #bitcoin-core-dev 05:55 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 06:00 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 06:02 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 06:06 -!- Aaronvan_ [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has quit [Remote host closed the connection] 06:06 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has joined #bitcoin-core-dev 06:06 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has quit [Changing host] 06:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:11 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 06:14 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 06:16 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds] 06:16 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 06:32 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has joined #bitcoin-core-dev 06:32 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has quit [Changing host] 06:32 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 06:38 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has joined #bitcoin-core-dev 06:46 -!- panicstr [~panicstr@89-233-121-180.dynamic.t-2.net] has joined #bitcoin-core-dev 06:51 -!- panicstr [~panicstr@89-233-121-180.dynamic.t-2.net] has quit [] 07:03 -!- arowser [~quassel@106.120.101.38] has quit [Quit: No Ping reply in 180 seconds.] 07:04 -!- arowser [~quassel@106.120.101.38] has joined #bitcoin-core-dev 07:13 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 07:24 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 255 seconds] 07:30 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 07:34 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has joined #bitcoin-core-dev 07:42 -!- MarcoFalke [~marco@host10-2.natpool.mwn.de] has quit [Quit: MarcoFalke] 07:45 < cfields> woohoo, 0.13 ec2 sync finally finished :) 07:51 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 07:58 < cfields> for those interested... ec2 xlarge 4core, 16gb ram. All default settings: 07:59 < cfields> v0.13.2: 01:12:39:43 07:59 < cfields> v0.14.0: 00:06:24:17 08:01 < paveljanik> nice! 08:03 < cfields> Setting a reasonable dbcache cuts the 0.14 time in half. Unsure what it does for 0.13. Similar, I assume 08:04 < cfields> Actually no... 0.13 is doing lots more validation. So it'd still be much more than half. 08:05 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 08:10 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 268 seconds] 08:18 -!- str4d [~str4d@host-78-145-23-219.as13285.net] has joined #bitcoin-core-dev 08:48 < wumpus> FYI rc2 executables are online: https://bitcoin.org/bin/bitcoin-core-0.14.0/test.rc2/ 09:06 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 09:06 < Lauda> sync is faster with 0.14.0? 09:10 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has joined #bitcoin-core-dev 09:10 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has quit [Changing host] 09:10 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 09:15 -!- Squidicc is now known as squidicuz 09:41 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds] 10:14 -!- alpalp [~alpalp@2605:6000:f4ea:ff00:dba:5c0f:355e:e899] has joined #bitcoin-core-dev 10:14 -!- alpalp [~alpalp@2605:6000:f4ea:ff00:dba:5c0f:355e:e899] has quit [Changing host] 10:14 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 10:54 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 240 seconds] 10:57 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-kicibfzlmvjvtssf] has quit [Ping timeout: 240 seconds] 10:57 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has quit [Ping timeout: 240 seconds] 10:58 -!- CodeShark [sid126576@gateway/web/irccloud.com/x-eekntfqmrlrnbeyy] has joined #bitcoin-core-dev 10:59 -!- GreenIsMyPepper [~GreenIsMy@2605:6400:20:11aa:189e:28a5:52ed:8948] has joined #bitcoin-core-dev 11:11 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has joined #bitcoin-core-dev 11:23 -!- LeMiner [LeMiner@unaffiliated/leminer] has joined #bitcoin-core-dev 11:31 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer] 11:32 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 11:57 < bitcoin-git> [bitcoin] jameshilliard opened pull request #9858: remove TestBlockValidity from CreateNewBlock critical path (master...remove-tbv) https://github.com/bitcoin/bitcoin/pull/9858 12:16 -!- laurentmt [~Thunderbi@176.158.157.202] has joined #bitcoin-core-dev 12:36 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 12:39 -!- chjj [~chjj@unaffiliated/chjj] has quit [Client Quit] 12:39 -!- chjj [~chjj@unaffiliated/chjj] has joined #bitcoin-core-dev 12:54 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-rymmioymisjvkbye] has quit [Read error: Connection reset by peer] 12:57 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 13:00 -!- str4d [~str4d@host-78-145-23-219.as13285.net] has quit [Ping timeout: 260 seconds] 13:01 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 13:01 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 13:08 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 13:11 -!- laurentmt [~Thunderbi@176.158.157.202] has quit [Quit: laurentmt] 13:12 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 13:17 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 13:19 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 13:22 -!- crudel [crudel@gateway/shell/fnordserver.eu/x-vjppnqqyorgsjvre] has joined #bitcoin-core-dev 13:40 -!- lclc [~lclc@unaffiliated/lclc] has quit [Ping timeout: 240 seconds] 13:42 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 13:44 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 268 seconds] 13:48 < cfields> luke-jr: jinx :) 13:48 < luke-jr> ? 13:49 < cfields> luke-jr: 9858 13:54 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 13:54 < luke-jr> i c ☺ 14:09 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has quit [Read error: Connection reset by peer] 14:11 -!- wumpus [~quassel@pdpc/supporter/professional/wumpus] has joined #bitcoin-core-dev 14:19 -!- owowo [~ovovo@unaffiliated/ovovo] has quit [Ping timeout: 268 seconds] 14:24 < luke-jr> would be nice if everything that went into stable branches were daggy fixes. 14:25 < sipa> daggy? 14:27 < luke-jr> sipa: http://wiki.secondlife.com/wiki/Creating_a_version_control_repository#The_.22Daggy.22_Fix 14:29 -!- Guyver2 [~Guyver2@guyver2.xs4all.nl] has quit [Remote host closed the connection] 14:31 < luke-jr> basically means bugfix commits are parented to the bug-introducing commit, allowing a merge into each branch of the same fix commit 14:35 -!- JackH [~laptop@79-73-188-131.dynamic.dsl.as9105.com] has joined #bitcoin-core-dev 14:37 < gmaxwell> are really that many of our fixes ones where there is a obvious bug inducing commit which is recent enough for that to be useful? 14:41 < luke-jr> gmaxwell: maybe not. as a middle-ground, I typically just try to rebase to the most recent branching point that is a clean merge to master 14:42 < luke-jr> eg, everything I do now would be based on 9828f9a at the latest (if possible) 14:42 < luke-jr> (which I have simple-tagged as "branch-0.14" in my repo) 14:56 -!- owowo [~ovovo@31.7.59.226] has joined #bitcoin-core-dev 14:56 -!- owowo [~ovovo@31.7.59.226] has quit [Changing host] 14:56 -!- owowo [~ovovo@unaffiliated/ovovo] has joined #bitcoin-core-dev 15:17 -!- justanotheruser [~justanoth@unaffiliated/justanotheruser] has joined #bitcoin-core-dev 15:19 -!- justan0theruser [~justanoth@unaffiliated/justanotheruser] has quit [Ping timeout: 240 seconds] 16:02 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has joined #bitcoin-core-dev 16:02 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has quit [Changing host] 16:02 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 16:02 < bitcoin-git> [bitcoin] jameshilliard opened pull request #9859: Make TestBlockValidity optional in CreateNewBlock (master...tbv-optional) https://github.com/bitcoin/bitcoin/pull/9859 16:18 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds] 16:38 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 16:42 < bitcoin-git> [bitcoin] keystrike opened pull request #9861: Trivial: Debug log ambiguity fix for peer addrs (master...patch-2) https://github.com/bitcoin/bitcoin/pull/9861 16:43 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has quit [Read error: Connection reset by peer] 16:45 -!- wudayoda [~goksinen@rrcs-50-75-193-138.nyc.biz.rr.com] has joined #bitcoin-core-dev 16:57 < jcorgan> btcdrak: addrindex has now been ported to 0.14 16:57 < jcorgan> https://github.com/jmcorgan/bitcoin/tree/addrindex-0.14 16:57 < jcorgan> reindexing now 17:00 -!- alpalp [~alpalp@unaffiliated/alpalp] has joined #bitcoin-core-dev 17:00 < btcdrak> jcorgan: sweet. I'll grab it. 17:44 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has joined #bitcoin-core-dev 17:44 -!- AaronvanW [~AaronvanW@110.red-88-20-218.staticip.rima-tde.net] has quit [Changing host] 17:44 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 17:51 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has quit [] 18:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Remote host closed the connection] 18:35 -!- Evel-Knievel [~Evel-Knie@d5152f744.static.telenet.be] has joined #bitcoin-core-dev 19:02 -!- shesek [~shesek@bzq-84-110-60-48.red.bezeqint.net] has quit [Ping timeout: 255 seconds] 19:14 -!- Ylbam [uid99779@gateway/web/irccloud.com/x-isyvpwmrteiheaba] has quit [Quit: Connection closed for inactivity] 19:22 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 19:25 -!- Victorsueca [~Victorsue@unaffiliated/victorsueca] has quit [Ping timeout: 255 seconds] 19:29 -!- Giszmo [~leo@pc-240-13-215-201.cm.vtr.net] has quit [Quit: Leaving.] 20:09 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has joined #bitcoin-core-dev 20:14 -!- AaronvanW [~AaronvanW@unaffiliated/aaronvanw] has quit [Ping timeout: 260 seconds] 20:39 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has quit [Read error: Connection reset by peer] 20:41 -!- Victor_sueca [~Victorsue@unaffiliated/victorsueca] has joined #bitcoin-core-dev 21:22 -!- mol [~molly@unaffiliated/molly] has joined #bitcoin-core-dev 21:24 -!- kinlo_ [~peter@unaffiliated/kinlo] has joined #bitcoin-core-dev 21:25 -!- moli_ [~molly@unaffiliated/molly] has quit [Ping timeout: 260 seconds] 21:26 -!- aspect__ [sid151486@gateway/web/irccloud.com/x-zjcouxcqfioezmvy] has joined #bitcoin-core-dev 21:32 -!- kewde[m]1 [kewdematri@gateway/shell/matrix.org/x-ndokqqyciyzuwqzi] has joined #bitcoin-core-dev 21:32 -!- baldur_ [~baldur@pool-100-2-139-91.nycmny.fios.verizon.net] has joined #bitcoin-core-dev 21:33 -!- kinlo [~peter@unaffiliated/kinlo] has quit [Ping timeout: 252 seconds] 21:33 -!- aspect_ [sid151486@gateway/web/irccloud.com/x-oemaofefvcsnwoqc] has quit [Ping timeout: 252 seconds] 21:33 -!- kewde[m] [kewdematri@gateway/shell/matrix.org/x-hewqhluqvjqqmjna] has quit [Ping timeout: 252 seconds] 21:33 -!- frabrunelle [frabrunell@safenetwork/frabrunelle] has quit [Ping timeout: 252 seconds] 21:33 -!- baldur [~baldur@pool-100-2-139-91.nycmny.fios.verizon.net] has quit [Ping timeout: 252 seconds] 21:33 -!- kinlo_ is now known as kinlo 21:34 -!- aspect__ is now known as aspect_ 21:35 -!- frabrunelle [frabrunell@safenetwork/frabrunelle] has joined #bitcoin-core-dev 21:48 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-tdjswpqodbvjcddl] has quit [Ping timeout: 240 seconds] 21:50 -!- wallet42 [sid154231@gateway/web/irccloud.com/x-fjgdyclkatnqzkwj] has joined #bitcoin-core-dev 22:10 -!- alpalp [~alpalp@unaffiliated/alpalp] has quit [Ping timeout: 240 seconds] 22:37 -!- Chris_Stewart_5 [~Chris_Ste@unaffiliated/chris-stewart-5/x-3612383] has quit [Ping timeout: 260 seconds] 23:15 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 23:31 -!- lclc [~lclc@unaffiliated/lclc] has quit [Read error: Connection reset by peer] 23:33 -!- lclc [~lclc@unaffiliated/lclc] has joined #bitcoin-core-dev 23:37 -!- panicstr [~panicstr@89-233-121-180.dynamic.t-2.net] has joined #bitcoin-core-dev