< MarcoFalke> I'd prefer to move the dbcrash test back to extended tests for now, if it causes timeouts
< wumpus> agree
< wumpus> and would be good to document why it's in the extended test, to prevent people from moving it back and forth all the time
< wumpus> release notes merged, going to tag v0.17.0 final in a bit
< queip> what is the outlook for Bitcoin Core for iOs? Grim? I'm looking forkward to building on top of it, glad to help in testing (though no iOs coding skill myself)
< queip> abcore for android, wrapping bitcoin core, works fine
< wumpus> if it's even possible to compile stock C++ projects on iOS, someone could do it, but no one is working on it as far as I know
< wumpus> * [new tag] v0.17.0 -> v0.17.0
< sdaftuar> \o/
< sipa> wumpus: \\o \o/ o//
< promag> woo hoo!
< * sipa> does the regular heptadecagon dance
< jonasschnelli> Core on iOS should not be overcomplicated... the toolchain we use for OSX is IMO also capable to compile for iOS armv7, etc.
< jonasschnelli> AFAIK sjors is working on it: https://github.com/bitcoin/bitcoin/issues/11720
< queip> jonasschnelli: I've seen you worked on that, what is the status now actually? to get basic cli
< jonasschnelli> #12557
< gribble> https://github.com/bitcoin/bitcoin/issues/12557 | [WIP] 64 bit iOs device support by Sjors · Pull Request #12557 · bitcoin/bitcoin · GitHub
< jonasschnelli> queip: no. I haven't really worked on it.
< jonasschnelli> I once did some work for cURL to compile it on iOS... and some other iOS cross compile stuff.
< queip> I've worked on gitian builds for mac, if that helps
< queip> I wonder between helping bitcoin core to work on iOs [mostly testing], or giving up and libbitcoin or some spv
< jonasschnelli> I think getting depends/ ready for iOS is the best thing you could go: #12557
< gribble> https://github.com/bitcoin/bitcoin/issues/12557 | [WIP] 64 bit iOs device support by Sjors · Pull Request #12557 · bitcoin/bitcoin · GitHub
< jonasschnelli> I though fail to see concrete use cases why one would run Bitcoin Core on iOS.
< queip> jonasschnelli: validate own money
< jonasschnelli> yeah... but the battery!
< queip> auto pause
< queip> (anyway indeed system will enforce it a lot)
< jonasschnelli> Yeah... maybe.
< jonasschnelli> If you want to see that happen (I'd like to see that happen as well), maybe help 12557 by commenting, testing, etc.
< achow101> \o/ 0.17.0
< provoostenator> jonasschnelli queip: any help is welcome with that PR. Battery use depends on the application developer, e.g. if you only sync on wifi it shouldn't be too bad.
< provoostenator> Once we have BIP-158 filter support (no plans that I know of), an app could use that while on a mobile network / on battery, only doing full sync on wifi or when receiving a large amount of coins.
< provoostenator> (I mean client side BIP-158 filter support, we do have a server side PR)
< luke-jr> provoostenator: could already do it with bloom stuff, albeit not privacy-safe
< gmaxwell> it's important to keep in mind that BIP-158 is not private either, it basically has the level of non-privacy bip37 was claimed/intended to have but bip37 turned out a lot worse than intended for several reasons.
< luke-jr> gmaxwell: even if you fetch blocks from different peers?
< gmaxwell> luke-jr: even if.
< luke-jr> how so?
< gmaxwell> by listening for a while and correlating what you do send, and/or running multiple sybil peers, so you see most of them anyways.
< gmaxwell> Generally any information leak becomes significant if you just wait a while
< gmaxwell> also, by paying you dust the attacker can stimulate you to keep fetching blocks
< gmaxwell> attacker doesn't even have to pay _you_ dust they can construct an address of their own that collides with yours in the filter, and just pay themselves.
< gmaxwell> er, scratch the doesn't have to dust you part, I forgot that the filter fiat-shamirs with the block hash.
< phantomcircuit> gmaxwell, well and you can pull the bip 158 filters over tor links which are not correlated to each other
< phantomcircuit> but you'd have to do one filter per connection per peer which seems nasty
< phantomcircuit> an have some random time delay
< phantomcircuit> which vaguely defeats the purpose
< gmaxwell> phantomcircuit: pulling the filters themselves aren't the problem: clients always pull all of them.
< gmaxwell> Plugging the blocks is. and indeed, pulling one block per tor connction would go a long way towards improving things.
< gmaxwell> but great care would be needed so that querying clients were actually indistinguishable.
< luke-jr> too bad nodes probably can't just connect+getblock only, need at least a version msg?
< phantomcircuit> should probably have a "standard" version message for that reason
< gmaxwell> luke-jr: they do, and we'd want to keep that just because version msg may indicate things that change how stuff gets serialized.
< luke-jr> would be nice if it could be simplified so the client end is just send+recv
< luke-jr> (and if the remote node can't handle it, just disconnects)
< phantomcircuit> luke-jr, then each message would need to encode that format it expected in response
< luke-jr> well, the send could use a preformatted version message
< phantomcircuit> im happy with #14335
< gribble> https://github.com/bitcoin/bitcoin/issues/14335 | net: refactor: cleanup ThreadSocketHandler by pstratem · Pull Request #14335 · bitcoin/bitcoin · GitHub
< phantomcircuit> it's much simplified over the previous cleanup pr
< phantomcircuit> everything is just a move into private methods, none of the logic should be changed at all
< rex4539> I'm currently running the extended tests for fun and I'm seeing multiple failures. I have never run the tests before. Is it known that multiple tests fail? Should I file a bug? And if so, one per failure or one that includes all of them?
< phantomcircuit> rex4539, which extended tests?
< rex4539> The functional ones.
< phantomcircuit> rex4539, what commit?
< rex4539> Latest master.
< phantomcircuit> rex4539, those same tests are run by travis which is doing continuous integration
< phantomcircuit> did you build with weird configuration flags or on a weird system?
< rex4539> I configured --with-gui=qt5 and I'm on macOS 10.13.6
< promag> rex4539: mind sharing those errors?
< rex4539> The test suite just finished. The ones that failed are: wallet_backup.py, feature_dbcrash.py, feature_block.py, feature_segwit.py, mining_prioritisetransaction.py, feature_assumevalid.py, rpc_createmultisig.py, feature_versionbits_warning.py, feature_nulldummy.py, wallet_import_rescan.py, wallet_bumpfee.py, mempool_packages.py, feature_dersig.py, feature_cltv.py, feature_pruning.py
< rex4539> Here's one example -> https://pastebin.com/7VUxBTue
< promag> running just, for instance, test/functional/feature_nulldummy.py also fails?
< rex4539> It passes. Also tried another one and passes too.
< promag> I guess it's some issue in your system
< promag> try test_runner with --jobs=1