< promag> Maybe replace "Overall workflow" and "RPCs" sections with "Refer to the [PSBT documentation](doc/psbt.md) for more details."
< wumpus> * [new tag] v0.16.3 -> v0.16.3
< midnightmagic> lol "And to those[...]" "+- beardnboobies"
< luke-jr> wumpus: did someone get a CVE number yet?
< achow101> wouldn't been nice to have had 14196 in rc4 ...
< achow101> *would've
< sipa> #14196
< gribble> https://github.com/bitcoin/bitcoin/issues/14196 | [0.17][psbt] always drop the unnecessary utxo and convert non-witness utxo to witness when necessary by achow101 · Pull Request #14196 · bitcoin/bitcoin · GitHub
< sipa> oh yes
< bralyclow> is v0.16.3 official release yet?
< bralyclow> I see listed as unofficial release, but it is not tagged Latest Release yet
< fanquake> bralyclow It was only tagged a few hours ago, gitian builds still need to be done
< gmaxwell> bralyclow: it's been tagged but the binaries are not up yet, since it takes time for the determinstic build process do to its thing.
< fanquake> (which are under way at the moment)
< bralyclow> very good, thank you for update/clarify, will wait on binaries for mac
< bralyclow> btw, when might 0.17 be released as I see at rc4 now?
< achow101> bralyclow: 0.17 will be released when we stop finding bugs in it for a week or 2
< fanquake> bralyclow There are still some outstanding issues/PRs that need to be resolved for 0.17 https://github.com/bitcoin/bitcoin/milestone/33
< bralyclow> thank you for that info
< fanquake> I've PR'd some 0.17.0rc4 unsignedsigs, as I already had depends built, will PR 0.16.3 this arvo.
< wumpus> fanquake: great!
< wumpus> i've pushed 0.16.3 unsigned sigs to gitian.sigs
< zndtoshi> Pierre Rochard explained in a presentation about Bitcoin Governance that consensus is reached similary to people meeting at the Schelling point: they know the city but not the location and hour to meet. They will think what the other would do and vice versa and in NY meet in Grand Central Station at noon without communicating. So conseus in Bitcoin is the same: everyone gravitates to the right software to use or the rig
< zndtoshi> miners. They have a veto option by signaling acceptance or not of a future softfork. But they should/will meet with everyone else at the Schelling point as well. Is there a REAL need for mining nodes to signal inside the Bitcoin Network? If not, are there any risks to remove mining node signaling?
< echeveria> zndtoshi: this is more appropriate for #bitcoin, please ask it there.
< zndtoshi> Thought I would ask developers if there is contention about this. Sorry, will post there.
< fanquake> wumpus cool. Looks like yours match my in-progress 0.16.3. Just finishing the macOS build
< wumpus> now building 0.17.0rc4
< harding> wumpus: 0.16.3 release PR for BitcoinCore.org for when the binaries are uploaded: https://github.com/bitcoin-core/bitcoincore.org/pull/596
< wumpus> harding: thank you, that's quick !
< fanquake> wumpus 0.15 will need a build as well I guess, given it's maintenance period doesn't end until after 0.17 release?
< wumpus> fanquake: yes, probably would make sense to tag a 0.15.x release as well
< wumpus> though that is less urgent, today I'd ideally like ot upload binaries for 0.17.0rc4 and 0.16.3 at least
< achow101> 0.14 isn't EOL yet too
< wumpus> the patch has been backported to both 0.14 and 0.15
< wumpus> making a release on those branches is pretty much only a matter of writing (short) release notes, if anyone wants to speed it up and have a go at those, be my guest
< fanquake> wumpus np. I've just merged achow's sigs. So we've got 3 builders for 0.16.3 and 4 for 0.17.0rc4 so far.
< luke-jr> FWIW, I got CVE-2018-17144 assigned for this
< wumpus> (and bumping the version, and bumping the mangpages maybe)
< wumpus> luke-jr: thanks
< provoostenator> (building in progress for 0.17rc4, I'll do 0.16.3 too)
< luke-jr> trivial bug in release notes: wumpus didn't update translations :p
< provoostenator> I'll tackle the 0.15.2 release notes if nobody else is already doing it.
< provoostenator> Not that many commits so I can probably do it manually, but the release docs say "ping @wumpus on IRC, he has specific tooling to generate the list of merged pulls and sort them into categories based on labels"
< provoostenator> For backports, so I refer to the backport PR or to the original one?
< luke-jr> might be good to mention the CVE number in release notes yet-to-be-final
< provoostenator> luke-jr: I'll add that to #14262 now
< gribble> https://github.com/bitcoin/bitcoin/issues/14262 | 0.15.2 release notes by Sjors · Pull Request #14262 · bitcoin/bitcoin · GitHub
< luke-jr> * [new tag] v0.16.3.knots20180918 -> v0.16.3.knots20180918
< leishman> "If you are a channel operator and would like to download a copy of the logs for your channel, please send a PM to ipmb on Freenode for more details."
< leishman> I find the bitcoin-core-dev irc logs on botbot super useful for following development progress and learning. Are there channel logs anywhere else?
< sipa> see topic :)
< leishman> oh haha. I may try to run a version of the botbot logger since it's open source and has a much better UI than the others
< echeveria> it however, does seem to have a crazy amount of deps.
< echeveria> I guess not too many, I thought foreman was ruby (along with go, python).
< leishman> yeah. shouldn't be too difficult to write a simple logger and put a UI on top of it either.
< provoostenator> FWIW gen-manpages.sh doesn't work on macOS because of sed issues.
< wumpus> luke-jr: I explicitly didn't update translations, because translations can contain 'bugs' and we're not following an rc process
< wumpus> but yes, not mentioning it in release notes makes sense
< wumpus> removed mention of translations from #14251
< gribble> https://github.com/bitcoin/bitcoin/issues/14251 | doc: Add historical release notes for 0.16.3 by laanwj · Pull Request #14251 · bitcoin/bitcoin · GitHub
< wumpus> provoostenator: yeah, it's more trouble than it's worth using the tooling in this case
< provoostenator> I'll remove the translation mention as well.
< wumpus> I'll add in the CVE, good idea
< luke-jr> wumpus: sudo lxc-execute -n gitian -f var/lxc.config -- sudo -u root -i -- bash
< luke-jr> why is this line in your .assert? O.o
< provoostenator> I'm trying to build the man pages on a Gitian box, which doesn't have a display. Any idea how to get around "QXcbConnection: Could not connect to display" for "bitcoin-qt --help"?
< provoostenator> xvfb-run to the rescue
< cfields> gitian builders: v0.16.3 detached sigs are pushed
< gmaxwell> perhaps people that regularly build should get pinged directly?
< cfields> fanquake/achow101/jonasschnelli/provoostenator/luke-jr/wumpus/MarcoFalke/fivepiece: ^^
< achow101> ok
< cfields> reused from last time
< wumpus> luke-jr: no idea!
< wumpus> luke-jr: oh, apparently I added an 'echo' line once
< wumpus> must have been while debugging some issue with lxc, didn't expect it to end up anywhere else but on my own screen; hope it doesn't cause problems with validation
< luke-jr> XD
< luke-jr> pushed my signed gitian sigs (3rd one)
< luke-jr> wumpus: I doubt the line should cause problems; I only noticed it because I was comparing
< ossifrage_> gmaxwell, I was just building a fresh bitcoin and noticed I still had a madvise(MADV_RANDOM) when mmapping read only data in leveldb, Is this worth a PR? It seem to reduces the number of pages fetched, but I don't have a good way to show if it actually helps
< provoostenator> Updated man pages in #14263, anything else needed for a v0.15.2 tag?
< gribble> https://github.com/bitcoin/bitcoin/issues/14263 | Update manpages for 0.15.2 by Sjors · Pull Request #14263 · bitcoin/bitcoin · GitHub
< luke-jr> ossifrage: LevelDB changes should go upstream
< wumpus> ossifrage: I think doing optimization PRs only make sense if you can show it is a win
< ossifrage> wumpus, it does reduce the working set of pages pulled (at least initially) if people actually care about that (I don't)
< wumpus> ossifrage: I care about it if it helps performance!
< luke-jr> might be more of a system performance thing than bitcoind performance
< luke-jr> (which IMO is still worth getting it merged upstream)
< ossifrage> luke-jr, yeah it is a system level issue, which makes it much harder to test
< luke-jr> run Chromium on the test system :P
< luke-jr> on btrfs
< luke-jr> lol
< ossifrage> It depends heavily on how much system level memory pressure you have and how fast your IO is
< ossifrage> luke-jr, g++ seems triggers way more violent page eviction then chrome does. chrome is a slow burn, g++ is a punch in the face
< luke-jr> ossifrage: well, Chromium seems to rewrite its state text files every second or two, and does fsync on that
< provoostenator> Is there a way to curse blocks, i.e. the opposite of "preciousblock"?
< sipa> invalidateblock
< provoostenator> Thanks
< sipa> (which is more than cursing, it marks the block as unconditionally invalid)
< sipa> the oppposite of invalidateblock is reconsiderblock
< midnightmagic> and of course there's the ancillary haveteawithblock
< jamesob> any idea when bitcoincore.org is going to be updated with 0.16.3's release notes?
< theymos> How upgraded are miners right now?
< wumpus> you people really don't have a second of patience do you
< midnightmagic> I do!
< midnightmagic> \o/
< luke-jr> lol
< jamesob> wumpus: sorry
< wumpus> theymos: some miners have already upgraded, don't know the % though
< theymos> Do you think that I mention in my bitcointalk.org announcement that a chain split is possible?
< provoostenator> theymos: I don't think that's possible
< achow101> theymos: a chain split is not possible
< provoostenator> An invalid block could crash a node, but no node, patched or unpatched would accept such a block
< theymos> ok, thanks
< achow101> however, if you remove the assert that causes the crash, then you would accept an invalid block. but no release has that
< wumpus> bitcoincore.org and bitcoin.org PRs have both been merged, should be a matter of times before the sites update...
< gmaxwell> ossifrage: I should benchmark a reindex I guess.
< wumpus> harding: for some reason, bitcoincore.org is not updating, travis shows build passing etc, any idea what coudl be wrong?
< wumpus> did anyone urge people to upgrade in #bitcoin yet?
< luke-jr> I announced Knots there, at least. echeveria changed the topic. don't see an actual Core ann tho
< wumpus> ok
< TD-Linux> gmaxwell, are there "standard" reindex benchmark settings?
< gmaxwell> TD-Linux: defaults, and dbcache=10000 (e.g. big enough that it never flushes) are the two cases that are most interesting. It's useful to -connect=0 to stay offline while benchmarking.
< molz> wumpus, i got my nodes updated hours ago, now i'm announcing this on several forums, thanks for all your work and don't let it stress you out
< TD-Linux> how does bitcoin decide how many threads to use? it seems to only be using 16 on my 32 core machine
< fanquake> To set the number of script verification threads, we ultimately call std::thread::hardware_concurrency()
< luke-jr> TD-Linux: boost::thread::physical_concurrency()
< luke-jr> fanquake: only when compiling with an obsolete boost
< luke-jr> TD-Linux: are you sure it has 32 cores? not 16 + HT?
< TD-Linux> 64 counting HT
< * luke-jr> wonders what it uses on POWER9
< fanquake> luke-jr not since #10271 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/10271 | Use std::thread::hardware_concurrency, instead of Boost, to determine available cores by fanquake · Pull Request #10271 · bitcoin/bitcoin · GitHub
< luke-jr> oh, didn't realise it changed recently; in any case, nobody should be running that yet
< luke-jr> TD-Linux: might be good to check if that PR fixes it for you
< TD-Linux> indeed boost's cpuinfo parsing won't work on my /proc/cpuinfo
< TD-Linux> it looks for the number of unique (physical id, core id) pairs but that is not a unique identifier on my machine
< luke-jr> I don't even have physical/core ids in mine XD
< TD-Linux> yeah so I'm running master for my benchmark
< TD-Linux> boost would actually say I only have 8 cores with its logic
< TD-Linux> I'll file a boost bug but I guess I also need a libstdc++ bug
< luke-jr> >_<
< luke-jr> does get_nprocs() work?
< luke-jr> I guess that doesn't try to de-HT
< TD-Linux> yes it does (returns 64)
< luke-jr> looks like boost's cpuinfo parsing would fallback to get_nprocs on POWER9
< * TD-Linux> kind of doubts that trying to not count HT cores is worth the pain
< luke-jr> std::thread::hardware_concurrency seems to just wrap get_nprocs on GCC 7.3
< gmaxwell> TD-Linux: bitcoin caps at 16 because we measured previously and found that performance stops improving there and gets worse.