1 2017-10-08 02:08:00	0|meshcollider|How does this datadir path caching work? I don't see anywhere which writes to pathCached or pathCachedNetSpecific, only reads from it?
 2 2017-10-08 02:08:24	0|meshcollider|Is there some magic lower level caching happening somehow?
 3 2017-10-08 02:21:22	0|esotericnonsense|meshcollider: it's pointer fun
 4 2017-10-08 02:21:47	0|esotericnonsense|(github code search obscures it a bit by only showing a few matches)
 5 2017-10-08 02:22:17	0|esotericnonsense|in GetDataDir path = x is updating either pathCached or pathCachedNetSpecific
 6 2017-10-08 02:23:08	0|meshcollider|Ohhh true it is
 7 2017-10-08 02:23:14	0|meshcollider|Missed that, thanks :)
 8 2017-10-08 02:23:21	0|esotericnonsense|took me a while to work it out :P
 9 2017-10-08 02:24:49	0|esotericnonsense|something about the boost / operator on paths really frustrates me, i can't really get a handle on why, it just seems like an abuse of the operator
10 2017-10-08 04:04:53	0|StopAndDecrypt|hi, can someone provide me with the most recent hard fork that was not contentious? ie: miners adopted ~rapidly
11 2017-10-08 04:36:06	0|mryandao|StopAndDecrypt: monero?
12 2017-10-08 04:36:14	0|mryandao|oops off-topic here. Sorry.
13 2017-10-08 04:53:36	0|luke-jr|StopAndDecrypt: 2013 May; but miner adoption is not relevant to hardforks
14 2017-10-08 05:08:24	0|StopAndDecrypt|luke-jr, understood, just looking for a very easy example for something im writing, ty
15 2017-10-08 05:29:23	0|luke-jr|StopAndDecrypt: note it's fuzzy/disputed whether 2013 May was in fact a hardfork or not; to get the last certain hardfork, you need to go back to Satoshi pre-value days
16 2017-10-08 11:27:35	0|bitcoin-git|[13bitcoin] 15jackpot1136 opened pull request #11463: BIP148 user activated activation of segwit (06master...06bip-segwit-flagday) 02https://github.com/bitcoin/bitcoin/pull/11463
17 2017-10-08 11:36:29	0|bitcoin-git|[13bitcoin] 15MarcoFalke closed pull request #11463: BIP148 user activated activation of segwit (06master...06bip-segwit-flagday) 02https://github.com/bitcoin/bitcoin/pull/11463
18 2017-10-08 13:04:55	0|andytoshi|StopAndDecrypt: i wouldn't call 2013 may a HF because a validating node from before that time could still sync the chain up to today (if they weren't given too many stales along the way to use up db resources). other than that july 20 2010 when satoshi added a bunch of extra NOPs
19 2017-10-08 13:05:05	0|andytoshi|july 30*
20 2017-10-08 17:44:14	0|esotericnonsense|may? wasn't it march?
21 2017-10-08 17:44:56	0|esotericnonsense|if so, it's a weird one because it was kind of an 'unsuccessful unintentional hard fork'
22 2017-10-08 17:46:34	0|esotericnonsense|but yes i don't think the soft/hard fork terminology really makes sense in the context of an unintentional consensus break
23 2017-10-08 18:31:48	0|luke-jr|esotericnonsense: March was the unsuccessful, unintentional hardfork attempt; May was the intentional and clean hardfork success
24 2017-10-08 18:32:34	0|luke-jr|andytoshi: by that logic, one could argue that no hardfork is a hardfork until a block is mined; yet nodes clearly diverge on the rules even before then
25 2017-10-08 18:32:44	0|esotericnonsense|I thought it was august? but yeah, okay, that makes sense
26 2017-10-08 18:33:22	0|esotericnonsense|(i guess the block was mined in aug and the consensus updated in may)
27 2017-10-08 18:33:24	0|luke-jr|andytoshi: the only logical reason I see to question whether 2013 May was a HF, is that the previous consensus rules were not consistent across all nodes; but I would argue even then, it still is, because none of them would have allowed the now-allowed blocks
28 2017-10-08 19:24:06	0|Chris_Stewart_5|Has anyone seen errors like this related to our test_bitcoin executable and secp256k1 ?
29 2017-10-08 19:24:10	0|Chris_Stewart_5|https://pastebin.com/1iqQQvh2
30 2017-10-08 19:24:50	0|Chris_Stewart_5|it seems that running teh tests individually with '--run_test=test_suite_here/' works but running them all together fails
31 2017-10-08 19:35:40	0|Chris_Stewart_5|nvm, it appears that those failures were just occurring because another test case was failing. Not sure why the secp256k1 warning messages were coming up though..