< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #14930: test: pruning: Check that verifychain can be called when pruned (master...Mf1812-testPruneVerify) https://github.com/bitcoin/bitcoin/pull/14930
< promag>
MarcoFalke: I'd like that wallet :P
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #14931: test: mempool_persist: Verify prioritization is dumped correctly (master...Mf1812-testMempoolPrio) https://github.com/bitcoin/bitcoin/pull/14931
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #14932: ui: Warn the user on file corruption in mempool.dat (master...Mf1812-testFileCorruption) https://github.com/bitcoin/bitcoin/pull/14932
< nelsonhb>
The succession of these flame emperors, from Shennong, the first Yan Emperor, until the time of the last Yan Emperor's defeat by the Yellow
< nelsonhb>
Emperor, may have been some 500 years.
< ap4lmtree>
qt is a popular interface gui huh
< ap4lmtree>
how did you guys learn that qt related programming
< provoostenator>
I found that for Gitian building 0.17.1 of the Windows signer binary it's necessary to use gitian-builder.py from the 0.17 branch, not from master. Or it starts complaining about file names.
< wumpus>
provoostenator: I think the idea to use the gitian-builder from the branch you're building
< provoostenator>
The currently instructions tell you to copy gitian-builder during the setup phase, but are unclear on what to do after. Always using the one from the release branch makes sense.
< provoostenator>
Maybe it should do a diff against bitcoin/contrib/gitian-builder.py after it checks out the branch and then prompt the user.
< fanquake>
The 0.17.0.1 release binaries "seem" to work on Vista, but Qt dropped official support in 5.6, so I'd assume it's only a matter of time before they stop working.
< bitcoin-git>
[bitcoin] practicalswift opened pull request #14935: tests: Test for expected return values when calling functions returning a success code (master...test-return-values) https://github.com/bitcoin/bitcoin/pull/14935
< timothy>
fanquake: Microsoft deprecated support for Vista more than 1 years ago
< timothy>
do you REALLY want to run something like bitcoin on an unsupported OS?
< fanquake>
timothy nope, which is why I've suggested we increase our minimum supported version of Windows to Windows 7 in 0.18.0
< promag>
after this should it have support for "all or nothing" import?
< provoostenator>
I suggested in the comments to have a warning==error option, which would have that effect, at least for stuff we can detect in advance.
< provoostenator>
No actually it would still be a per entry thing.
< promag>
right
< promag>
let me rephrase my question, after 14565, should we _add_ support for "all or nothing"?
< wumpus>
fanquake: probably better to ask on twitter or reddit, but no, I don't think anyone is still using vista, it was extremely unpopular even at the time
< wumpus>
+indeed, as timothy says, using an unsupported OS for bitcoin is kind of stupid
< wumpus>
windows 7 is still used intentionally by some people (that dislike windows 10) so setting that as the baseline supported version would make sense, imo
< bitcoin-git>
[bitcoin] ken2812221 opened pull request #14937: travis: fix travis would always be green even if it fail (master...travis-fix-save-cache-2) https://github.com/bitcoin/bitcoin/pull/14937
< andytoshi>
sipa: i'm confused by https://github.com/bitcoin/bitcoin/pull/13191 ... it seems the new SHA256D64 does not append the sha256 length/padding anywhere, so how can `ComputeMerkleRoot` be consensus-compatible with the old code?
< andytoshi>
i assume i'm just being dumb/blind
< gmaxwell>
andytoshi: the length/padding is hardcoded into it.
< gmaxwell>
(because the length is fixed)
< andytoshi>
isn't it 512 * `blocks` ?
< sipa>
andytoshi: it can only hash 64-byte inputs
< gmaxwell>
thats what the D64 means.
< andytoshi>
what does the `blocks` argument mean then?
< sipa>
andytoshi: the 'blocks' is how many double-SHA256-on-64-byte-inputs are being computed *in parallel*
< andytoshi>
ah!
< andytoshi>
thank yuo
< andytoshi>
ah yeah, suddenly the code makes sense :P
< gmaxwell>
the speedup in this code over boring code comes mostly from hardcoding the lengths and padding, and in doing so elimiating the related expander rounds.
< gmaxwell>
(both from the 64 byte input and the 32byte inter-stage input)
< sipa>
and from using SSE4/AVX2 to compute 4 or 8 of them in parallel
< gmaxwell>
whered that patch using avx512 to do 16 in parallel go? :P
< andytoshi>
ok. the reason i ask is that in Elements we are directly using sha2 midstates to get the same speedup (which ofc changes the hash function so is completely incompatible with bitcoin)
< andytoshi>
and we're trying to rebase on #13191 and deciding the best course of action
< gmaxwell>
welp if you're not using SHA256D64 you can't use that code... it could be adapted to not include the length by changing some constants.
< andytoshi>
yep, that's what i'm concluding. thanks. probably we'll just keep our hacky midstate code and switch to SHA256D64 at the next hf opportunity
< gmaxwell>
is what elements does SHA256D64 that just doesn't run the second compression function run?
< andytoshi>
gmaxwell: correct
< gmaxwell>
yes, then it could be adapted with some work. it would be somewhat faster than this code.
< andytoshi>
hmm, ok, maybe it's worth doing that work. though i'm uncomfortable enough with our effectively-homebrew hash function already without trying to optimize it :)
< promag>
should running with -wallet=xxx be an error if it's configured with --disable-wallet?
< gmaxwell>
andytoshi: well fortunately if you get it wrong it probably just won't work. :P
< andytoshi>
hehe, this is true
< gmaxwell>
promag: hm in one sense, sure, but "I compiled differently and now I get an error on my config files" is not great.
< promag>
right, because config file
< gmaxwell>
promag: logging -wallet ignored due to ... is probably a reasonable middle ground, I dunno if we do that now.
< promag>
is there a long call like waitforblock but that holds a wallet?
< sipa>
i don't think so
< tryphe>
gmaxwell, it would be similar to setting some mempool options along with a "blocksonly=1" line in the config. one could uncomment the single "blocksonly=1" line to have the mempool options take effect. similar to commenting/uncommenting a "disable-wallet=1" line while having wallet= set.
< tryphe>
gmaxwell, uncomment=comment*, but you get the idea :)
< sipa>
tryphe: the difference is that with --disable-wallet, the wallet related code isn't even compiled in, so there would naively not be anything that can recognize those wallet lines as something meaningful in other configurations
< tryphe>
sipa, this is a good point
< gmaxwell>
the reason in favor of erroring on non-sensible configs is because silently giving the user something different than what they asked for isn't nice, and they might bash their head against a wall trying to figure out why it doesn't work because they didn't notice the other parameter.
< gmaxwell>
I generally prefer to log -- unless the interaction is one that if uncaught could cause funds loss.
< gmaxwell>
they'll find the log sometime between the third and fourth hour of troubleshooting. :P