< bitcoin-git>
[bitcoin] lucayepa opened pull request #15650: Handle the result of posix_fallocate system call (master...handle-posix-fallocate) https://github.com/bitcoin/bitcoin/pull/15650
< gmaxwell>
#proposedmeetingtopic Bech32 support shipped first in Bitcoin Core in Feb 2018, more than a year ago. We should consider making an announcement that Bitcoin Core intends to change the default addresstype from p2sh-segwit to bech32 in 0.19 or 0.20.
< bitcoin-git>
[bitcoin] luke-jr opened pull request #15651: torcontrol: Use the default/standard network port for Tor hidden services, even if the internal port is set differently (master...tor_standard_port) https://github.com/bitcoin/bitcoin/pull/15651
< gmaxwell>
(obviously we'd continue to support getting p2sh-segwit on demand, but any service that doesn't support sending to bc1x addresses would see a rise in complaints/support requests.
< gmaxwell>
(and now I think I've said enough that the discussion can be had without me around)
< gwillen>
gmaxwell: ties in well with the optech newsletter's upcoming 24-week series on bech32 sending support :-)
< gmaxwell>
It's what reminded me to proposedmeetingtopic it... I had intended to do this a few weeks ago (after observing the >1yr mark and dealing with a confused user) but I forgot.
< gmaxwell>
fanquake: nice!
< fanquake_>
wumpus: #15642 should be mergeable. The end of signrawtransaction.
< fanquake_>
wumpus I guess #15647 as well, which backports a single commit from what you just merged into 0.18.
< gribble>
https://github.com/bitcoin/bitcoin/issues/15647 | [rpc] Remove deprecated functionality message from validateaddress help by jnewbery · Pull Request #15647 · bitcoin/bitcoin · GitHub
< wumpus>
ok
< bitcoin-git>
[bitcoin] promag opened pull request #15652: wallet: Update transactions with current mempool after load (master...2019-03-fix-15591) https://github.com/bitcoin/bitcoin/pull/15652
< promag>
"bitcoind exited with status -6 during initialization"
< promag>
anyone knows what -6 is?
< wumpus>
6) SIGABRT
< promag>
wumpus: ty
< promag>
wumpus: oh, reason is POTENTIAL DEADLOCK DETECTED
< gmaxwell>
anyone recently test fallback? user with 0.16.3 and dns non-functional sat running for 20+ hours without getting any connections, but worked fine after oneshotting a running node.
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #15647: [rpc] Remove deprecated functionality message from validateaddress help (0.18...2019_03_backport_remove_verifyaddress_deprecated_warning) https://github.com/bitcoin/bitcoin/pull/15647
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #15654: net: Remove unused unsanitized user agent string CNode::strSubVer (master...1903-netUABytes) https://github.com/bitcoin/bitcoin/pull/15654
< wumpus>
gmaxwell: as the hardcoded seeds are only updated once per major version, I'd expect the ones for 0.16.3 to be thus old that there's been enough churn since to make it difficult to find a working one
< wumpus>
gmaxwell: that said, not finding *one* working node in 20+ hours is unexpected I think
< wumpus>
I'm sure some have been up since then
< wumpus>
nice how the cycle counter registers (cycle, cycleh) on RISC-V are readable from userspace like on x86, and unlike ARM
< wumpus>
also gcc 9.x generates very good code for RISC-V, I don't think I'm going to be able to improve this for secp256k1
< bitcoin-git>
[bitcoin] 251Labs opened pull request #15655: Resolve the checkpoints <-> validation circular dependency (master...patch/resolve-checkpoints-validation-cd) https://github.com/bitcoin/bitcoin/pull/15655
< luke-jr>
is anyone familiar enough with Neutrino and Bloom's inner workings to answer: can you use Neutrino filters to optimise Bloom? or are the two filters fundamentally incompatible?
< luke-jr>
roasbeef:
< luke-jr>
(if you can, this could also be possibly useful for pure Neutrino clients, to avoid checking each of its addresses one by one against the filters)
< sipa>
luke-jr: in scenarios where the server is trusted, you should just give the addresses/xpubs/... to the server and have them rescan for you
< sipa>
and that can definitely be optimized using bip158 filters
< luke-jr>
sipa: but the current standard for this is BIP37 (and I would expect such bloom filters to be smaller than sending every address?)
< luke-jr>
also, even if you do the checks node-side, checking <block filter> matches <all addresses filter> would presumably be quicker than checking every single address against the block filter
< sipa>
luke-jr: to answer your question, you can't compute the intersection between a bloom filter and a bip158 filter, as they use incompatible hash functions
< luke-jr>
could that be fixed, or would that hurt BIP158 filters somehow?
< luke-jr>
if not adjusting BIP158 to BIP37, maybe some other kind of address filter that could be compatible? (it won't help BIP37 then, but might reduce CPU time implementing BIP158 searches still)
< gmaxwell>
large bip37 filters are very slow to evaluate in any case because there are many hash functions.
< echeveria>
luke-jr: neutrino filters are sort of non optimal for most things, including neutrino itself.
< echeveria>
luke-jr: the thing they’re useful for in bitcoin core is wallet rescans.
< echeveria>
which you can do even when pruned, so long as you keep the 3GB of filters.
< sipa>
echeveria: as opposed to bip37, which is non optimal for everything :)
< gmaxwell>
sipa: sounds right to me.
< gmaxwell>
like, if you look at bip37's other applications such as leaking lite wallet addresses, electrum does that slightly better by sending the addresses directly.
< echeveria>
gmaxwell: it does it better by sending the list in a totally unambiguous way, mostly
< echeveria>
no luck, no analysis, just here's my wallet, yo.