< benthecarman> Is the mailing list down? It won't let me add myself
< wajz> Hi there!, just a simple question. I'm reading a blockchain paper which I would like to discuss. Is this an appropiate channel or there's any 'research channel'?
< kanzure> /join #bitcoin-wizards
< wajz> Thanks kanzure
< bitcoin-git> [bitcoin] sdaftuar opened pull request #15169: WIP: Parallelize CheckInputs() in AcceptToMemoryPool() (master...2018-12-parallel-mempool-scriptchecks) https://github.com/bitcoin/bitcoin/pull/15169
< bitcoin-git> [bitcoin] koalaman opened pull request #15170: refactor/lint: Add ignored shellcheck suggestions to an array (master...master) https://github.com/bitcoin/bitcoin/pull/15170
< meshcollider> gwillen: maybe only one or two more, hopefully promag or someone who commented early on is willing to do a full review
< gwillen> meshcollider: cool, thanks
< gwillen> I would ping promag here but he doesn't seem to be on at the moment
< meshcollider> He'll get pinged by my message anyway :)
< gwillen> well he would if he were here, anyway :-)
< bitcoin-git> [bitcoin] Empact opened pull request #15171: test: Wait before cleanup on exit (master...test-wait-cleanup) https://github.com/bitcoin/bitcoin/pull/15171
< gmaxwell> Security warning: if you scp files from a malicious ssh server, it can overwrite arbritary files in/under your target directory.
< DeanGuss> so you're saying don't work with malicious ssh servers?
< booyah> gmaxwell: that seems like a serious bug. you are not controling the file name? scp foo@bar.org:/tmp/a.txt ./ can result in something else then ./a.txt ?
< cjd> that's what it sounds like
< cjd> or worse, a.txt as you expected plus also click_here_please.exe as well
< cjd> or .bashrc or any of a plethora of other nasties
< wumpus> wonder if rsync has the same problem? that's what I usually yse
< cjd> hmm, my intuition is that ssh to malicious machines is a minefield
< promag> #14941 should be ready for last ack and merge
< gribble> https://github.com/bitcoin/bitcoin/issues/14941 | rpc: Make unloadwallet wait for complete wallet unload by promag · Pull Request #14941 · bitcoin/bitcoin · GitHub
< wumpus> but do you ever know for sure that the machine you're sshing to is not 'malicious'? if exploits can easily travel from ssh servers to clients, this makes e.g. VMs mostly useless as an isolation mechanism
< wumpus> but yes, if you know you're sshing to a compromised machine it's good to be careful I guess
< bitcoin-git> [bitcoin] laanwj pushed 3 new commits to master: https://github.com/bitcoin/bitcoin/compare/cf0c67b62c20...1b6fc3053045
< bitcoin-git> bitcoin/master c37851d João Barbosa: rpc: Make unloadwallet wait for complete wallet unload
< bitcoin-git> bitcoin/master 645e905 João Barbosa: doc: Add release notes for unloadwallet change to synchronous call
< bitcoin-git> bitcoin/master 1b6fc30 Wladimir J. van der Laan: Merge #14941: rpc: Make unloadwallet wait for complete wallet unload...
< bitcoin-git> [bitcoin] laanwj closed pull request #14941: rpc: Make unloadwallet wait for complete wallet unload (master...2018-12-sync-unloadwallet) https://github.com/bitcoin/bitcoin/pull/14941
< wumpus> whoa, bitcoin-git is *working* again
< wumpus> gkrizek: is that your bot now?
< bitcoin-git> [bitcoin] Mr-Leshiy closed pull request #15160: Optimization improvements (master...MrLeshiy_Improvements) https://github.com/bitcoin/bitcoin/pull/15160
< bitcoin-git> [bitcoin] Mr-Leshiy reopened pull request #15160: Optimization improvements (master...MrLeshiy_Improvements) https://github.com/bitcoin/bitcoin/pull/15160
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/1b6fc3053045...a5daf70ffb80
< bitcoin-git> bitcoin/master a88640e Hennadii Stepanov: Fix minimized window bug on Linux...
< bitcoin-git> bitcoin/master a5daf70 Wladimir J. van der Laan: Merge #14594: qt: Fix minimized window bug on Linux...
< bitcoin-git> [bitcoin] laanwj closed pull request #14594: qt: Fix minimized window bug on Linux (master...20181028-restore-minimized) https://github.com/bitcoin/bitcoin/pull/14594
< bitcoin-git> [bitcoin] Mr-Leshiy closed pull request #15160: Optimization improvements (master...MrLeshiy_Improvements) https://github.com/bitcoin/bitcoin/pull/15160
< luke-jr> yikes re scp
< luke-jr> is there a CVE?
< bitcoin-git> [bitcoin] laanwj closed pull request #14965: minor: fix extra "non" in source code comment (master...minor-comment-double-negation) https://github.com/bitcoin/bitcoin/pull/14965
< timothy> luke-jr: yes, much CVE-s
< wumpus> thanks timothy
< luke-jr> ^
< luke-jr> wumpus: rsync supports wildcards, so I suspect it has the same problem :/
< luke-jr> eg, rsync foo@bar:/path/to/\* ./
< wumpus> hmm true, but if you use a wildcard you're kind of asking for the remote to be able to overwrite any file locally (unless you provide the flag not to)
< wumpus> well any file within the destination path obviously not outside it
< luke-jr> wumpus: yes, but that feature implies the local client needs to do its own globbing check
< wumpus> luke-jr: but the remote can always lie about which files are available, I'd think
< wumpus> oh you mean to match against the globs, of course
< wumpus> promag: please rebase #14458
< gribble> https://github.com/bitcoin/bitcoin/issues/14458 | WIP: Add JSON-RPC interface documentation by promag · Pull Request #14458 · bitcoin/bitcoin · GitHub
< gkrizek> wumpus: no, I commented about it when it started up yesterday. "GitHub IRC Service is out of its brown out until the 31st when it’s fully depreciated. I’m still working on a replacement and it’s close to done. Will def be done before the 31st."
< gkrizek> So it's still GitHub back for a couple weeks before it's really really dead
< wumpus> gkrizek: okay ! thanks again for working on it
< wumpus> apparently missed that comment :)
< gkrizek> No problem, happy to do it!
< promag> wumpus: on it
< promag> wumpus: #14958 could also go
< gribble> https://github.com/bitcoin/bitcoin/issues/14958 | qa: Remove race between conneting and shutdown on separate connections by promag · Pull Request #14958 · bitcoin/bitcoin · GitHub
< wumpus> ook
< wumpus> would be nice if MarcoFalke could take a look at that one
< promag> no problem
< promag> there's like 1 month until feature freeze?
< wumpus> 'for (uint64_t j = static_cast<uint64_t>(1) << (i - 1); (j >> i) == 0; ++j) {'
< wumpus> isn't there a shorter way to do this? static_casting 1 to uint64_t seems... outrageous
< wumpus> (concerning #14151)
< gribble> https://github.com/bitcoin/bitcoin/issues/14151 | windows: Fix remaining compiler warnings (MSVC) by practicalswift · Pull Request #14151 · bitcoin/bitcoin · GitHub
< wumpus> promag: yes exactly a month you're right ! (#14438)
< gribble> https://github.com/bitcoin/bitcoin/issues/14438 | Release schedule for 0.18.0 · Issue #14438 · bitcoin/bitcoin · GitHub
< luke-jr> at the very least it could be uint64_t(1)
< luke-jr> FWIW, I confirmed rsync IS vulnerable to the same
< wumpus> luke-jr: thanks for the suggestion, will try
< luke-jr> (to reproduce, make a dummy shell script that just does exec ${SSH_ORIGINAL_COMMAND/dummyA\/a/dummyA\/*}, and use SSH forced commands to call it)
< sipa> wumpus: so it's counting from 2**(i-1) to (2**i)-1 ?
< phantomcircuit> wumpus, remote can also send sym and hard links with rsync so like... yeah
< luke-jr> phantomcircuit: depends on client configuration in theory
< luke-jr> and that's expected behaviour at least
< phantomcircuit> luke-jr, iirc the flags just control what the client requests
< wumpus> sipa: it kind of confuses me, according to the test it's supposed to generate bit patterns in j with i bits set
< luke-jr> phantomcircuit: ugh
< phantomcircuit> luke-jr, tons of stuff works that way
< luke-jr> wumpus: actually, looking at that further looks .. dumb
< * luke-jr> wonders wtf that's *trying* to do
< luke-jr> for (unsigned j = 1U << (i - 1); (j >> i) == 0; ++j) {
< wumpus> that creates an 'unsigned int' which is probably 32 bit, won't the shift potentially shift out of the register or even create undefined behavior
< luke-jr> wumpus: unsigned int is guaranteed to be at least 16-bit, and this is only done when i is <10
< wumpus> hhmm okay
< wumpus> I... don't think adding that reliance is very nice
< luke-jr> it's gotta rely on some bit width regardless. no reason to do 64-bit when we know it won't be 64-bit :p
< wumpus> the input to that bitcounting function is 64-bit, and it's a test for that, so limiting it at that makes some sense
< luke-jr> and if the standards-required assumption of 16-bit ever fails, the test will just fail
< luke-jr> which we probably want anyway, considering other code currently assumes it's 32-bit :p
< wumpus> true; I wish C++ had 1u64 like rust
< sipa> e could define a user-defined literal for it
< sipa> c++11 feature :)
< wumpus> interesting
< luke-jr> sipa: ?
< wumpus> nice feature, I don't think that's used anywhere in the code yet
< sipa> luke-jr: in c++11 you can define compile-time code to evaluate expressions of the form 1234_u64 for example
< wumpus> kind of overkill for this, but still, nice :)
< sipa> kinda surprising they didn't include a few default instances of it in the std library for things like this
< luke-jr> wow
< wumpus> looks like they defined a few default instances for std::complex and std::chrono::*
< wumpus> but not this unfortunately yeh
< wumpus> oh wait that's *C++14* nm\
< sipa> and only in c++14, and a few more in c++20
< wumpus> right
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/a5daf70ffb80...e8ad580f5153
< bitcoin-git> bitcoin/master fb3ce75 Hennadii Stepanov: Don't label transactions "Open" while catching up...
< bitcoin-git> bitcoin/master e8ad580 Wladimir J. van der Laan: Merge #14556: qt: fix confirmed transaction labeled "open" (#13299)...
< bitcoin-git> [bitcoin] laanwj closed pull request #14556: qt: fix confirmed transaction labeled "open" (#13299) (master...20181023-fix13299) https://github.com/bitcoin/bitcoin/pull/14556
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/e8ad580f5153...eb2aecfb8066
< bitcoin-git> bitcoin/master 03b8596 TheCharlatan: Add checksum in gitian build scripts for ossl...
< bitcoin-git> bitcoin/master eb2aecf Wladimir J. van der Laan: Merge #14433: Add checksum in gitian build scripts for ossl...
< bitcoin-git> [bitcoin] laanwj closed pull request #14433: Add checksum in gitian build scripts for ossl (master...osslChecksum) https://github.com/bitcoin/bitcoin/pull/14433
< dongcarl> Anything else that needs doing for: https://github.com/bitcoin/bitcoin/pull/12255
< luke-jr> dongcarl: the release notes seem wrong
< dongcarl> luke-jr: Comment on the PR, happy to fix.
< luke-jr> yeah, will do
< luke-jr> (it's actually init.md)
< bitcoin-git> [bitcoin] MarcoFalke pushed 5 new commits to master: https://github.com/bitcoin/bitcoin/compare/eb2aecfb8066...82ffd4d91832
< bitcoin-git> bitcoin/master fac4558 MarcoFalke: sync: Add RecursiveMutex type alias
< bitcoin-git> bitcoin/master fafe941 MarcoFalke: test: Add missing validation locks
< bitcoin-git> bitcoin/master fa5c346 MarcoFalke: doc: Add comment to cs_main and mempool::cs
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #14963: mempool, validation: Explain cs_main locking semantics (master...Mf1812-docValLocks) https://github.com/bitcoin/bitcoin/pull/14963
< dongcarl> luke-jr: Thanks!
< bitcoin-git> [bitcoin] Sjors opened pull request #15173: [doc] explain what .python-version does (master...2019/01/pyenv_doc) https://github.com/bitcoin/bitcoin/pull/15173
< bitcoin-git> [bitcoin] jonasschnelli pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/82ffd4d91832...c7c84209bb0a
< bitcoin-git> bitcoin/master f411c8b João Barbosa: gui: Remove unused return type in some BitcoinGUI methods
< bitcoin-git> bitcoin/master 8a79261 João Barbosa: gui: Keep network style in BitcoinGUI
< bitcoin-git> bitcoin/master fe7048b João Barbosa: gui: Show current wallet name in window title
< bitcoin-git> [bitcoin] jonasschnelli closed pull request #15149: gui: Show current wallet name in window title (master...2019-01-updatewindowtitle) https://github.com/bitcoin/bitcoin/pull/15149
< jamesob> is there any good reason that ofstream objects can't be used as a stream with the serialize functions?
< sipa> jamesob: i think it just diverged; they used to implement a similar interface, but nothing used stdlib stream objects, so changes over time broke the compatibility?
< sipa> what causes it? the GetVersion etc?
< jamesob> trying to figure that out atm but I don't think it's GetVersion; top line of the compiler barf is
< jamesob> ./compressor.h:55:15: error: invalid operands to binary expression ('std::basic_ofstream<char>' and 'Span<typename std::remove_pointer<decltype(std::declval<vector<unsigned char, allocator<unsigned char> > >().data())>::type>' (aka 'Span<unsigned char>'))
< jamesob> in the meantime I can do a CDataStream intermediary I guess
< gwillen> heh, I just tried to do this the other day
< gwillen> and assumed it was just not meant to work
< gwillen> and wrote a little std::string returning wrapper around CDataStream nonsense instead
< jamesob> ah funny. I'm dealing with binary and so want to avoid string
< luke-jr> followup on the random_tests failure the other day, apparently some are seeing it with raii_tests instead: https://bugs.gentoo.org/675546 :/
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/c7c84209bb0a...391a27376b30
< bitcoin-git> bitcoin/master 04215eb Sjors Provoost: [doc] explain what .python-version does
< bitcoin-git> bitcoin/master 391a273 MarcoFalke: Merge #15173: [doc] explain what .python-version does...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #15173: [doc] explain what .python-version does (master...2019/01/pyenv_doc) https://github.com/bitcoin/bitcoin/pull/15173
< ryanofsky> jamesob, std::string is fine for binary data
< gwillen> I can confirm what ryanofsky
< gwillen> says*
< gwillen> I checked this very carefully before going that route, it was slightly surprising to me too
< gwillen> std::string will happily hold binary data as long as you do not like, call c_str and try to use the result as a zero-terminated string
< gwillen> but std::string itself is 100% binary safe
< luke-jr> gwillen: in standard or practice only?
< gwillen> in standard
< sipa> std::string is just a weirdly specialized vector of chars
< gwillen> and much to my chagrin, in Clang its iterator is interchangeable with one to a vector<char> but in g++ it is not.
< gmaxwell> but why not use a vector<char> ? :)
< gwillen> in my case it was because there are other interfaces that use std::string
< gwillen> and converting back and forth is extra lines of code