< bitcoin-git>
[bitcoin] hebasto opened pull request #16077: docs: Follow ISO/IEC 14882 terms and definitions (master...20190523-iso-parameter) https://github.com/bitcoin/bitcoin/pull/16077
< stevenroose>
Does bitcoind have an RPC that either (1) gives the xpub of the master priv (the one that dumpwallet gives) or (2) allows calculating the xpub of an xpriv?
< dongcarl>
cfields: Trying to understand your fork of cctools-port... Out of the 5 commits that you made that's no upstream, they've taken care of openssl and uuid (the first 2 commits), but I'm having trouble understanding the remaining 3... Namely: 3a2152b8e4d74601d9976f75aa7c30fd2b54733f, 81589bba090b29989dee31d8f04a78d917b34589, and ee31ae567931c426136c94aad457c7b51d844beb
< wumpus>
fanquake:I think that should just be merged?
< wumpus>
fanquake: is there anything to discuss about it?
< luke-jr>
did configure finally get updated?
< luke-jr>
not that I see..
< wumpus>
I don't know...
< MarcoFalke>
Seems like it is just shuffling things around and not actually dropping support
< fanquake>
wumpus I haven't tested any of the changes, just seemed there was discussion about which versions to drop support for, and wether other versions had actually been patched.
< wumpus>
it's dropping support for <10, which is fine, the only thing controversial was <14
< luke-jr>
looks like it would detect older miniupnpc libraries, then fail to compile
< wumpus>
because that's still in debian table
< wumpus>
stable
< fanquake>
ok.
< fanquake>
One other topic is suggestions for 0.18.1 backporting that aren't already in #16035
< wumpus>
are we planning on doing a 0.18.1 soon btw?
< wumpus>
I mean, is there anything motivating it?
< MarcoFalke>
nothing urgent, no
< promag>
ops, forgot about #15453
< gribble>
https://github.com/bitcoin/bitcoin/issues/15453 | Starting bitcoin-qt with -nowallet and then opening a wallet does not show the wallet · Issue #15453 · bitcoin/bitcoin · GitHub
< fanquake>
A couple of bug fixes for potentially confusing behaviour, like #15952, but nothing catastrophic
< jamesob>
I tried but I don't think I was doing it right
< MarcoFalke>
sipa: We couldn't find any significant changes on our hardware
< wumpus>
I doubt it affects performance at all
< sipa>
MarcoFalke: that's not surprising, but good to confirm
< wumpus>
just stack use
< gmaxwell>
My only concern was that it would break some other performance optimization, sounds like it doesn't.
< wumpus>
anyhow, upgrade to a compiler that doesn't have the bug (when there's one)
< wumpus>
performance loss is preferable to random unpredictable corruption
< wumpus>
certainly for something like bitcoin
< MarcoFalke>
right
< wumpus>
(I mean it's obviously different if say, validation becomes two times as slow or something extreme like that, but we'd have noticed)
< gmaxwell>
if the performance loss were truly significant though, we might want to look for other alternative workarounds, good that we don't need to.
< MarcoFalke>
Yeah, sync is ~hours, so a second doesn't matter at all
< wumpus>
MarcoFalke: right
< promag>
wumpus: right, agree at the moment saving a couple of seconds isn't worth it
< gmaxwell>
that sounds like it maybe more more relevant to propagation at the tip.
< wumpus>
and that's within the measuring noise isn't it?
< gmaxwell>
e.g. time from getting a block to sending the first non-HB peer.
< wumpus>
gmaxwell: yes, that latency would be useful to measure
< wumpus>
if it makes a significant difference there then it could still be worth it
< gmaxwell>
the fact that we're rehashing in general suggests we've got something kinda wrong, layout wise.
< wumpus>
true
< promag>
ok, I'll keep doing those profiles
< MarcoFalke>
Could just cache the hash in the data structure?
< wumpus>
depends also on how much more complicated it makes the code, or whether it increases memory use, etc
< wumpus>
how much it increases memory use, of course caching increases memory use
< * MarcoFalke>
ducks
< sipa>
jamesob: mr profiling... do we have any way to generally benchmark block-propagation-speed-at-synced-tip ?
< jamesob>
mmm short of parsing verbose debug.log, I don't think so. not built into bitcoinperf yet, at any rate :)
< promag>
MarcoFalke: the hash is only necessary while processing/validating
< sipa>
jamesob: i think it would be very valuable to have; especially for scenarios where the block's transactions have already been validated in the mempool
< sipa>
as there are very relevant performance improvements there that'd generally be dwarfed by script validation
< MarcoFalke>
sipa: Would that require two nodes?
< MarcoFalke>
or are you talking about a micro benchmark
< jamesob>
sipa: yeah, agree that's a metric worth tracking
< jamesob>
happy to build something for it
< sipa>
perhaps we should do some brainstorming about that, but maybe outside the meeting
< wumpus>
jamesob: cool!
< fanquake>
If anyone is interested in guix building, dongcarl has been doing a lot of work in #15277. Would be good to get some more builds to compare hashes with.
< gmaxwell>
sipa: there are tests in bitcoinfibre.
< wumpus>
fanquake: if there's clear instructions to test, I'm happy to try
< promag>
ah btw, one thing that takes a while is base_uint<BITS>& base_uint<BITS>::operator>>=(unsigned int shift)
< dongcarl>
wumpus: I'll update and link you
< wumpus>
dongcarl: great !
< sipa>
promag: inside the division logic for retargetting that's expected
< sipa>
most of the time is in shifts
< gmaxwell>
MarcoFalke: The logical place to cache hashes in block objects themselves, doing so there is irrelevant memory use wise (32 bytes in a 1.2MB object), but complicates constness.
< gmaxwell>
promag: if thats actually taking a non-trivial amount of some real usecase, the division could be made faster... it uses a fairly naieve algorithim right now.
< wumpus>
agree it's irrelevant on block objects, it's mostly CBlockIndex where it counts because so many of them are permanently in memory
< jamesob>
fanquake: cool!
< wumpus>
fanquake:nice
< wumpus>
any other topics?
< wumpus>
#endmeeting
< lightningbot>
Meeting ended Thu May 23 19:47:00 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4)
< gmaxwell>
2019-05-23T20:07:22.654285Z SendMessages: sending header 00000000000000000013886cc5bfa15d88db56f024a66b92f4b10ecf46922ff5 to peer=2
< gmaxwell>
The first is getting the cmpct block, the second is sending the first HB block, and the third is the first non-HB announcement.
< jamesob>
gmaxwell: ah okay, that helps
< gmaxwell>
it might be interesting to setup a little stats datastructure that you can get at with an RPC.
< gmaxwell>
That keeps a couple relevant times --- like the above two deltas for the last block, and maybe a couple EWMA averages of them. Then the python test framework could be used to do some benchmarking without relying on log parsing (which we break with frustrating frequency)
< gmaxwell>
one thing to keep in mind is that cmpctblock is only the relevant start point when there are no missing txn, otherwise the blocktxn message is.
< gmaxwell>
(if you measure cmpct->cmpct when there are missing txn, you'll include the response time of the peer and network latency-- which is itself also very interesting but perhaps doesn't make for a clean test :) )
< jamesob>
gmaxwell: thanks for the pointers. I was actually about to start working on a bitcoind log parsing lib, but the RPC idea's interesting too. I wonder if maintaining some of those stats datastructures under an #if defined(DEBUG) wouldn't be too invasive
< jamesob>
err probably not DEBUG; we might want a separate configure flag I guess
< gmaxwell>
Ifdefs are kind of invasive, I don't think some operational stats would be bad to have at runtime regardless.