< 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
< bitcoin-git> [bitcoin] MeshCollider pushed 6 new commits to master: https://github.com/bitcoin/bitcoin/compare/f65bce858f26...3fff1ab817e7
< bitcoin-git> bitcoin/master 6be0fb4 Pieter Wuille: [refactor] Add a base DescriptorImpl with most common logic
< bitcoin-git> bitcoin/master 24d3a7b Pieter Wuille: [refactor] Use DescriptorImpl internally, permitting access to new methods
< bitcoin-git> bitcoin/master 1eda33a Pieter Wuille: [refactor] Combine the ToString and ToPrivateString implementations
< bitcoin-git> [bitcoin] MeshCollider closed pull request #14646: Add expansion cache functions to descriptors (unused for now) (master...201811_descriptcache) https://github.com/bitcoin/bitcoin/pull/14646
< bitcoin-git> [bitcoin] MeshCollider pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/3fff1ab817e7...ed2a2cebd362
< bitcoin-git> bitcoin/master bb24d68 Ben Woosley: Make CWallet::ScanForWalletTransactions args and return value const
< bitcoin-git> bitcoin/master 3002d6c Ben Woosley: Return a status enum from ScanForWalletTransactions...
< bitcoin-git> bitcoin/master bd3b036 Ben Woosley: Add stop_block out arg to ScanForWalletTransactions...
< bitcoin-git> [bitcoin] MeshCollider closed pull request #13076: Fix ScanForWalletTransactions to return an enum indicating scan result: success / failure / user_abort (master...scan-for-wallet-transactions-ret) https://github.com/bitcoin/bitcoin/pull/13076
< 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.
< provoostenator> For signing stuff on your local machine (instead of inside the VM) and pushing to Github, this maybe useful: https://github.com/bitcoin-core/docs/issues/18#issue-292936112
< 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.
< bitcoin-git> [bitcoin] hebasto closed pull request #14905: scripted-diff: Replace deprecated C headers (master...20181209-replace-c-headers) https://github.com/bitcoin/bitcoin/pull/14905
< bitcoin-git> [bitcoin] Sjors opened pull request #14934: Descriptor expansion cache clarifications (master...2018/12/rename_m_script_arg) https://github.com/bitcoin/bitcoin/pull/14934
< promag> hebasto: are you able to test #14573 in windows?
< gribble> https://github.com/bitcoin/bitcoin/issues/14573 | qt: Add Window menu by promag · Pull Request #14573 · bitcoin/bitcoin · GitHub
< hebasto> promag: unfortunately, no
< promag> ok ty
< meshcollider> promag: I can test it on windows tomorrow
< promag> ok cool :)
< fanquake> meshcollider which version/s?
< promag> well, regargding 14573, details on windows can be improved in a separate PR to avoid invalidating existing acks
< meshcollider> fanquake: windows 10
< wumpus> what's with the appveyor failures?
< wumpus> oh nm, it's only on some PRs
< fanquake> more than usual?
< wumpus> no, I don't think so :<
< fanquake> Probably just need rebasing after a test fix?
< promag> wumpus: nothing related with #14670 right?
< gribble> https://github.com/bitcoin/bitcoin/issues/14670 | http: Fix HTTP server shutdown by promag · Pull Request #14670 · bitcoin/bitcoin · GitHub
< wumpus> promag: nope
< fanquake> wumpus I'm happy for 14909 to just go in without the other additions
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/ed2a2cebd362...96bde4f01f41
< bitcoin-git> bitcoin/master b7bee6a fanquake: doc: Update minimum required qt
< bitcoin-git> bitcoin/master 96bde4f Wladimir J. van der Laan: Merge #14909: doc: Update minimum required Qt...
< bitcoin-git> [bitcoin] laanwj closed pull request #14909: doc: Update minimum required Qt (master...doc-qt-minimum-52) https://github.com/bitcoin/bitcoin/pull/14909
< fanquake> wumpus also happy for #14701 to go in as is
< gribble> https://github.com/bitcoin/bitcoin/issues/14701 | build: Add CLIENT_VERSION_BUILD to CFBundleGetInfoString by fanquake · Pull Request #14701 · bitcoin/bitcoin · GitHub
< fanquake> Would be interested to know if there are many/any? users running Bitcoin-Core on Windows Vista. Could use some more input in #14922.
< gribble> https://github.com/bitcoin/bitcoin/issues/14922 | windows: Set _WIN32_WINNT to 0x0600 (Windows Vista) by ken2812221 · Pull Request #14922 · bitcoin/bitcoin · GitHub
< fanquake> The 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> sipa: about #14565
< gribble> https://github.com/bitcoin/bitcoin/issues/14565 | Overhaul importmulti logic by sipa · Pull Request #14565 · bitcoin/bitcoin · GitHub
< 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
< fanquake> wumpus fair enough. If you agree with my comments here, https://github.com/bitcoin/bitcoin/pull/14922#issuecomment-446585696, I'll add that to 0.18.0 and ask ken to update (including docs).
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/96bde4f01f41...edc2822b9dc9
< bitcoin-git> bitcoin/master 8e20934 fanquake: build: Add CLIENT_VERSION_BUILD to CFBundleGetInfoString
< bitcoin-git> bitcoin/master edc2822 Wladimir J. van der Laan: Merge #14701: build: Add CLIENT_VERSION_BUILD to CFBundleGetInfoString...
< promag> looks like XP > vista
< bitcoin-git> [bitcoin] laanwj closed pull request #14701: build: Add CLIENT_VERSION_BUILD to CFBundleGetInfoString (master...add-build-version-to-info-plist) https://github.com/bitcoin/bitcoin/pull/14701
< wumpus> fanquake: I agree
< promag> IMO #14914 is ready
< gribble> https://github.com/bitcoin/bitcoin/issues/14914 | Docs: Add nice table to files.md by emilengler · Pull Request #14914 · bitcoin/bitcoin · GitHub
< 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
< bitcoin-git> [bitcoin] Sjors opened pull request #14938: Support creating an empty wallet (master...2018/12/create-empty-wallet) https://github.com/bitcoin/bitcoin/pull/14938
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/edc2822b9dc9...38fb1b40dfb3
< bitcoin-git> bitcoin/master 9b51b15 Emil Engler: Add nice table to files.md...
< bitcoin-git> bitcoin/master 38fb1b4 Wladimir J. van der Laan: Merge #14914: Docs: Add nice table to files.md...
< bitcoin-git> [bitcoin] laanwj closed pull request #14914: Docs: Add nice table to files.md (master...add-nice-table) https://github.com/bitcoin/bitcoin/pull/14914
< bitcoin-git> [bitcoin] lontivero opened pull request #14939: rpc: Add test_accept_unsigned flag to testmempoolaccept (master...TestAcceptanceForUnsignedTransactions) https://github.com/bitcoin/bitcoin/pull/14939
< bitcoin-git> [bitcoin] mrwhythat closed pull request #14476: RPC method 'encodescript' (master...encodescript-rpc) https://github.com/bitcoin/bitcoin/pull/14476
< 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
< gribble> https://github.com/bitcoin/bitcoin/issues/13191 | Specialized double-SHA256 with 64 byte inputs with SSE4.1 and AVX2 by sipa · Pull Request #13191 · bitcoin/bitcoin · GitHub
< gmaxwell> andytoshi: really? midstates, yuck. :P
< andytoshi> gmaxwell: yes, yuck :P
< 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
< promag> review beg #14641
< gribble> https://github.com/bitcoin/bitcoin/issues/14641 | rpc: Add min_conf option to fund transaction calls by promag · Pull Request #14641 · bitcoin/bitcoin · GitHub
< promag> gmaxwell: are you suggesting to not apply min_conf to ismine utxo?