< meshcollider>
How does this datadir path caching work? I don't see anywhere which writes to pathCached or pathCachedNetSpecific, only reads from it?
< meshcollider>
Is there some magic lower level caching happening somehow?
< esotericnonsense>
meshcollider: it's pointer fun
< esotericnonsense>
(github code search obscures it a bit by only showing a few matches)
< esotericnonsense>
in GetDataDir path = x is updating either pathCached or pathCachedNetSpecific
< meshcollider>
Ohhh true it is
< meshcollider>
Missed that, thanks :)
< esotericnonsense>
took me a while to work it out :P
< 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
< StopAndDecrypt>
hi, can someone provide me with the most recent hard fork that was not contentious? ie: miners adopted ~rapidly
< mryandao>
StopAndDecrypt: monero?
< mryandao>
oops off-topic here. Sorry.
< luke-jr>
StopAndDecrypt: 2013 May; but miner adoption is not relevant to hardforks
< StopAndDecrypt>
luke-jr, understood, just looking for a very easy example for something im writing, ty
< 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
< bitcoin-git>
[bitcoin] jackpot1136 opened pull request #11463: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/11463
< bitcoin-git>
[bitcoin] MarcoFalke closed pull request #11463: BIP148 user activated activation of segwit (master...bip-segwit-flagday) https://github.com/bitcoin/bitcoin/pull/11463
< 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
< andytoshi>
july 30*
< esotericnonsense>
may? wasn't it march?
< esotericnonsense>
if so, it's a weird one because it was kind of an 'unsuccessful unintentional hard fork'
< esotericnonsense>
but yes i don't think the soft/hard fork terminology really makes sense in the context of an unintentional consensus break
< luke-jr>
esotericnonsense: March was the unsuccessful, unintentional hardfork attempt; May was the intentional and clean hardfork success
< 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
< esotericnonsense>
I thought it was august? but yeah, okay, that makes sense
< esotericnonsense>
(i guess the block was mined in aug and the consensus updated in may)
< 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
< Chris_Stewart_5>
Has anyone seen errors like this related to our test_bitcoin executable and secp256k1 ?
< Chris_Stewart_5>
it seems that running teh tests individually with '--run_test=test_suite_here/' works but running them all together fails
< 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..