< 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>
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>
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