< diegoviola>
will bitcoin core implement SPV like electrum and seeds?
< diegoviola>
I'd like to use core but I can't afford to download the whole blockchain
< diegoviola>
my connection sucks
< diegoviola>
my internet is only 1mb
< diegoviola>
:-(
< belcher>
once you have it all downloaded and verified you wont use much bandwidth at all
< diegoviola>
sure but will take days to download it
< belcher>
oh damn this channel, didnt realise, ask in #bitcoin
< diegoviola>
k
< 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
< phantomcircuit>
oh nvm...
< dcousens>
morcos: still intending to help with those stats, just waiting for a re-index to finish
< GitHub195>
[bitcoin] laanwj opened pull request #6919: Backport chainstate obfuscation to 0.11 (0.11...2015_10_backport_chainstate_obfuscation) https://github.com/bitcoin/bitcoin/pull/6919
< gmaxwell>
wumpus: sorry if I came across as suggesting we should wait on #6917 for any reason; that wasn't my goal. Rather, earlier you mentioned some doubt on which sync operation needed to do what, and maybe the new behavior is too strong, and my thought was if there isn't a performance regression "who cares, don't bother thinking about it."
< wumpus>
I think that optimization on windows should be a different issue. It's not like we ever paid attention to that before :-) I agree with sipa that benchmarking before and after would be nice - though I'm not sure exactly how - I have a slow windows laptop, probably bogged down by lots of crap, so I doubt it will yield any resuls within the noise margin :-)
< wumpus>
(that said, having looked at various syncs of block 0 to block 200000, I didn't notice any noticable difference)
< wumpus>
(and benchmarking in wine wouldn't be interesting, as these are exactly the OS specific things...)
< wumpus>
goal of Flush() seems to be 'flush application and OS buffers to file' and Sync() 'flush buffers to file, then wait for sync to disk to complete'. As far as I see windows' FlushFileBuffers has no way to distinguish between them
< wumpus>
what the previous implementation did was to leave Flush() empty. But that doesn't feel right at least...
< wumpus>
... it's something that could be done again later if it turns out to be safe
< wumpus>
(e.g. I think the rationale for that is "by using the OS API directly, anything written is by definition flushed to the OS". The POSIX implementation uses FILE* which has its own bufers)
< wumpus>
(then uses fflush in Flush(), "forces a write of all user-space buffered data for the given output or update stream via the stream's underlying write function". Yeah we don't need that...)
< GitHub48>
[bitcoin] Diapolo opened pull request #6920: remove unneded include from rpcserver.cpp and rpcclient.cpp (master...univalue) https://github.com/bitcoin/bitcoin/pull/6920
< gmaxwell>
Can we ask diapolo to test this leveldb fix?
< GitHub69>
[bitcoin] Diapolo opened pull request #6921: [Trivial] remove unneeded spaces from init.cpp (master...trivial_typo_space) https://github.com/bitcoin/bitcoin/pull/6921