< CubicEarths> Will BIP 174 make it easier for different brands of wallets to do multi-sig together?
< sipa> hopefully
< CubicEarths> I've been waiting for that day since multi-sig became a thing
< GitHub150> [bitcoin-detached-sigs] jonasschnelli opened pull request #6: 0.16.1: osx signatures for 0.16.1rc (0.16...0.16) https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/6
< GitHub159> [bitcoin-detached-sigs] theuni closed pull request #6: 0.16.1: osx signatures for 0.16.1rc (0.16...0.16) https://github.com/bitcoin-core/bitcoin-detached-sigs/pull/6
< cfields> gitian builders: detached sigs for v0.16.1rc1 are pushed
< fanquake> cfields pushed some signed sigs up https://github.com/bitcoin-core/gitian.sigs/pull/712
< jonasschnelli> fanquake: cfields sigs matches with mine (https://bitcoin.jonasschnelli.ch/build/634).. will push asap
< fanquake> jonasschnelli: What are your thoughts on moving to macOS 10.10 as a minimum required version for 0.17.0 ?
< fanquake> qt5.9.x supports > 10.10
< jonasschnelli> fanquake: 10.10 is pretty "newish"... not sure.
< jonasschnelli> That is a point.
< jonasschnelli> qt5.9 is LTR (long term release), right?
< fanquake> Correct, which is also why I thought a macOS bump might be ok
< jonasschnelli> We use 10.8 as min right now, right?
< fanquake> Qt seems to be getting more aggressive with dropping macOS support as well.
< fanquake> Yep, 10.8 is the current minimum
< fanquake> qt 5.10, 5.11 is macOS 10.11 +
< jonasschnelli> I think it would be worth to do sooner then later – IF – there are clear gains (features, stability, etc.)
< jonasschnelli> If not, we should probably wait ~1yr before upgrading to Qt5.9
< fanquake> There is some code for supporting 10.8, fonts stuff I think, that might be able to be dropped.
< fanquake> So for 0.17 we should just bump the 5.7.x, if there is an upgrade available?
< fanquake> I'm going to put something together about a bump, might wrap it up in an issue for discussion.
< jonasschnelli> We could bump to 5.7.x (if one is willing to work on that PR).
< fanquake> Layout any benefits/downsides etc.
< jonasschnelli> Upgrading Qt via depends was always pretty painful.
< jonasschnelli> Yes. I think minimal system requirements are important (to keep as low as possible). Only increase if necessary
< jonasschnelli> necessary == clear gains in UX or other area
< fanquake> We are currently using 5.7.1, and there doesn't seem to be any more point releases for the 5.7 branch. So if we stuck to 5.7 we wouldn't need any changes for 0.17
< fanquake> It's only compatibility patches, such as for Xcode etc
< jonasschnelli> Okay. That makes sense... should also be not to complicated.
< jonasschnelli> Did someone mention in the Qt5.9 PR that this will increase minimal system requieremnts for OSX?
< fanquake> Here are the qt5.9 "features". Anything stick out to you that would be nice to have? https://wiki.qt.io/New_Features_in_Qt_5.9
< jonasschnelli> And I know of a lot of OSX users stuck below 10.10
< fanquake> I don't think anyone has mentioned yet, I'll make a comment now.
< jonasschnelli> Thanks! I think this is a show stopper for that Qt5.9 PR
< jonasschnelli> I looked through the RN of QT5.9,... nothing that we really would need.
< jonasschnelli> We use only the very basics of QT
< jonasschnelli> AFAIK the biggest problem we should make progress is HiDPI on Win/Linux. I'm not sure if this is a Qt upstream issue or something we can do better
< jonasschnelli> Last time I checked, Bitcoin-Core looks pretty bad on Linux/Win HIDPI
< jonasschnelli> And I have not read anything about HiDPI improvements in the last RNs,... so very likely something we can do better.
< fanquake> mmm. Single mention of High-DPI on Windows in the Qt5.11 Release notes
< fanquake> Will have to investigate if we can do better with 5.7
< jonasschnelli> fanquake: That would be great. Maybe – if you can – test on HiDPI on Linux (Ubuntu?) and Windows... see if there is something we do wrong in our application that prevents those platforms from correctly rendering on HiDPI
< jonasschnelli> It works flawless on macOS
< jonasschnelli> (that is what me make think it is an upstream issue)
< fanquake> jonasschnelli Yea I'll have a look.
< fanquake> Merged all the sigs as well.
< wumpus> jonasschnelli: I think qt5 was supposed to have better support for HiDPI, but not sure whether that's only on macosx
< wumpus> maybe there's something that has to be enabled, it's always tricky
< jonasschnelli> wumpus: Yes. it's on my list since month (figure out the reasons why HiDPI looks bad on Win/Linux).
< jonasschnelli> *months
< wumpus> jonasschnelli: FWIW on linux I always have DPI issues and have to tune things (such as display DPI) manually, and some programs ignore it, it's not very well coordinated. Wouldn't surprise me if windows is similar.
< wumpus> jonasschnelli: then again, if other qt5 applications work and bitcoin core doesn't, yes it's something we forget to do
< fanquake> The debug console on Windows looks particularly bad
< wumpus> that's terrible, looks like a bitmap font that was zoomed out?!
< fanquake> wumpus Yea I'm not sure, none of the other fonts in the client look that bad, basically just the debug console.
< jonasschnelli> I just fail to understand why the HiDPI concept (which practically is a x2 scale) works flawless on OSX and looks so bad on Win
< jonasschnelli> which leads me to thinks, Qt needs to fix some things internally
< jonasschnelli> but would be great to know how other Qt5 apps behave
< wumpus> OSX has a neat and well-organized graphics layer, all things considered, compared to the other OSes
< fanquake> Couple other trivial issues on Windows as well, like this box https://0bin.net/paste/6nRFsooj5Y3ludG7#DrYmyEK86QNzE240PzcKhwOlrFWYuid9iPdQRb3Sr+d
< wumpus> screen dpi and scaling is simply handled. On Linux/X11 it's also reported to the application / widget toolkit but in a few conflicting ways, which they usually tend to ignore...
< fanquake> Things just seem to "break" slightly on Windows.
< wumpus> fanquake: probably just a matter of the wrong font
< wumpus> I vaguely remember that Wayland, the new Linux graphics stack, improved/standardized handling for screens with different DPI and such, but that's not of much use yet to most users
< wumpus> didnt' know 0bin handled images, by the way :o
< wumpus> arowser_: looks like you have connection issues
< wumpus> arowser_: please fix your connection, or I'll have to ban you
< fanquake> What are any changes in master that might stop you opening a wallet with 0.16.1?
< fanquake> Managed to generate a wallet that wont open with 0.16.1rc1, but opens with master fine. Can't seen to recreate going either way if I nuke the data dir.
< provoostenator> fanquake not an incompatible-bdb issue?
<@wumpus> creating a wallet with master that can't be opened in 0.16.1 is ok, we don't generally support opening wallets created with newer versions in older ones
< fanquake> provoostenator Shouldn't be. Using 0.16.rc1 binary, and WSL depends build with master. Both report 4.8.30 in debug log.
<@wumpus> (the other way around would be bad, or if you open it with master once and then can't use it with 0.16.1 anymore)
<@wumpus> but wallets *created* with master, well they are at the newest version, which might not be supported with older versions
< provoostenator> Would this version change be the reason? https://github.com/bitcoin/bitcoin/commit/a8da482a8bc87ff26194612727d4a7b86b2fb60d
<@wumpus> provoostenator: yes I think so
< fanquake> wumpus can you block Michelle155 from GH
< Arvidt> The release notes for 0.16.1rc1 linked in the announcement email is pretty empty / in draft state (e.g. "0.16.x Example item"). I think it would be interesting for someone considering running RC version to have an overview what's new. https://github.com/bitcoin/bitcoin/blob/0.16/doc/release-notes.md
< fanquake> Arvidt Looks like a bit of an oversight, will get some release notes PR'd shortly.
<@wumpus> I don't think any work has been done on the release notes yet, I considered not mentioning them at all, a list of commits would have been more useful
<@wumpus> I'll add that to the branch today
< fanquake> wumpus ^ see above re spammer
<@wumpus> fanquake: ah overlooked that, yes
<@wumpus> blocked from bitcoin and bitcoin-core orgs
< bitcoin-git> [bitcoin] laanwj pushed 1 new commit to 0.16: https://github.com/bitcoin/bitcoin/commit/afc115d7535986f6c2bec3c3ad4ed0fe90d31f01
< bitcoin-git> bitcoin/0.16 afc115d Wladimir J. van der Laan: doc: Add commits and authors to release notes for rc1...
< bitcoin-git> [bitcoin] fanquake opened pull request #13346: doc: update bitcoin-dot-org links in release-process.md (master...release-process-links) https://github.com/bitcoin/bitcoin/pull/13346
< fanquake> Be good to get some more macOS testers for https://github.com/bitcoin/bitcoin/pull/12783
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/f8a29ca823fb...60f0358b4a1e
< bitcoin-git> bitcoin/master 8310238 fanquake: doc: update bitcoin-dot-org links in release-process.md
< bitcoin-git> bitcoin/master 60f0358 MarcoFalke: Merge #13346: doc: update bitcoin-dot-org links in release-process.md...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13346: doc: update bitcoin-dot-org links in release-process.md (master...release-process-links) https://github.com/bitcoin/bitcoin/pull/13346
<@wumpus> should we put the 0.16.1 release notes in the wiki? or is that not useful for aminor release, I don't expect much editing to be necessary
< fanquake> wumpus As in have the WIP notes in the wiki? I don't think it'd be necessary
<@wumpus> yes--
<@wumpus> I don't think so either, but just asking
<@wumpus> I see some minor fixups are needed such as the version numbers, but not sure if anyone wants to add any more "notable changes"
< fanquake> The only one might be for the Windows assert? But the release-notes can be edited as part of that PR if it happens
<@wumpus> re: macOS testing for 12783, jonasschnelli can you do a build please?
<@wumpus> (hopes he fixed his connection by now...)
< fanquake> wumpus Maybe not heh
<@wumpus> (apparently not)
< provoostenator> Maybe edit the 0.16 release notes to reflect 0.16.1 rather than 0.16.0?
< fanquake> provoostenator Yes, that is left to do. See above ^
<@wumpus> provoostenator: they do, though the version numbers need bumping in some places
<@wumpus> but the content of the release notes is for 0.16.1
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13347: travis: Skip cache for lint stage (master...Mf1806-travisLintNoCache) https://github.com/bitcoin/bitcoin/pull/13347
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/60f0358b4a1e...25d2df2aa988
< bitcoin-git> bitcoin/master 3d4fa83 Wladimir J. van der Laan: Stop translating command line options...
< bitcoin-git> bitcoin/master 25d2df2 MarcoFalke: Merge #13341: Stop translating command line options...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13341: Stop translating command line options (master...2018_05_notranslate_options) https://github.com/bitcoin/bitcoin/pull/13341
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/25d2df2aa988...fd96d54f39cf
< bitcoin-git> bitcoin/master c814e2e Pieter Wuille: Remove template matching and pseudo opcodes...
< bitcoin-git> bitcoin/master fd96d54 Wladimir J. van der Laan: Merge #13194: Remove template matching and pseudo opcodes...
< bitcoin-git> [bitcoin] laanwj closed pull request #13194: Remove template matching and pseudo opcodes (master...201805_noscriptpattern) https://github.com/bitcoin/bitcoin/pull/13194
< kallewoof> I've addressed jimpo's concerns in #12634 and would like to re-add it to high pri list. If you don't wanna do that outside of meetings, consider this my spiritual presence at next meeting asking to have it added as I usually can't make it for 4 am. Btw why isn't #12136 on there?
< gribble> https://github.com/bitcoin/bitcoin/issues/12634 | [refactor] Make TransactionWithinChainLimit more flexible by kallewoof · Pull Request #12634 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/12136 | Implement BIP 174 Partially Signed Bitcoin Transactions by achow101 · Pull Request #12136 · bitcoin/bitcoin · GitHub
< instagibbs> the author was busy with other stuff until recently i presume
< kallewoof> instagibbs: Since wumpus promoted it on twitter I flat out presumed it was on that list tbh.
< instagibbs> high priority... in our hearts
< achow101> I asked wumpus to add it to the list a week or two ago but I didn't actually check if it got added
< gmaxwell> The specification still probably needs work, since it unfortunately hasn't had a lot of attention since it was written.
< gmaxwell> One of the challenges for high priority is .. like does it mean the feature is high priority or the implementation of it.
< achow101> gmaxwell: a few people have been looking at it and have sent me comments. I have made some changes to the spec since the original was added to the bips repo
< gmaxwell> oh good.
<@wumpus> it's high priority to me personally
<@wumpus> the meaning of the "high priority for review" project is to get people to look at it, it does not necessarily imply the change itself has high priority, although it does mean at least the author would like to see it merged (because it blocks further work, for example)
<@wumpus> anyhow -- added them both to the project
< ken2812221> Is it a good idea to clear the caches for all PR?
< ken2812221> on travis
<@wumpus> ken2812221: you mean after the 18.04 change?
<@wumpus> cfields ^^
< ken2812221> Yes, it seems there are a lot of PR tests timed out.
<@wumpus> I don't think cleaning the caches will help for timeouts
< mryandao> what C++ version is core currently on? do we only support C++17 and beyond?
< Varunram> the code is on C++11 afaik
< gmaxwell> mryandao: C++17 is a couple months old and isn't completely supported by any compiler...
< ken2812221> wunpus: Travis will fetch caches from master if there is no cache linked to the PR.
< cfields> wumpus: I don't think clearing caches would help at all. Each PR is going to rebuild all depends the next time it's pushed-to no matter what
< cfields> ken2812221: ah, that's a good point though
< sipa> mryandao: we were on c++03 until 2016, when we switched to c++11
< sipa> as gmaxwell says, c++17 is super new, and even c++14 support is pretty novel in compilers
< sipa> i guess gcc 5 (first with full support for c++14) is 3 years old now
< mryandao> gcc support still experimental for 17 :/
< sipa> mryandao: yes, it'll be years before we can adopt c++17
< gmaxwell> mryandao: even once there is support we can't use it until distributions pick it up.
< sipa> any reason why we can't adopt c++14 in the near future? gcc5 is in ubuntu 16.04 lts and up
< mryandao> C++14 enables the removal of boost::chrono
< bitcoin-git> [bitcoin] jl2012 opened pull request #13348: Standard template for CHECKMULTISIG with 17~20 keys (master...20multisig) https://github.com/bitcoin/bitcoin/pull/13348
< goatpig> std::chrono is in c++11, unless it's doing something different than boost's
<@wumpus> yes, std::chrono is c++11
< sipa> what is the blocker to doing an s/boost::/std::/ for all of chrono and thread?
<@wumpus> just work
<@wumpus> though I wouldn't be surprised if cfields already has all of that somewhere
< sipa> i remember something with interruption points
<@wumpus> cfields: so clear all PR caches but not the branches?
<@wumpus> sipa: yes, interruption points are one thing that would have to be implemented on our side
< sipa> i thought we had done so though, or at least partially
<@wumpus> I think for chrono there were no issues at all, our use of time could even easily be implemented using the C API
<@wumpus> there's DecodeDumpTime in src/wallet/rpcdump which does some boost-related time parsing, but that's not chrono
< cfields> wumpus: i'm not sure what 'the branches' are in that context?
<@wumpus> cfields: 0.16, master
< cfields> wumpus: ah yes, leave those
< cfields> as ken2812221 mentioned, it first tries to find the per-pr cache, and resorts to the generic master cache if that one can't be found...
< cfields> I'm not 100% if it will try to re-pull from master on a non-new PR, but the cache is useless in that case anyway, so I don't think it could hurt
<@wumpus> thought so, all PR caches are gone now
<@wumpus> apparently still hasn't fixed their connection
<@wumpus> might be more than just a cache issue
< bitcoin-git> [bitcoin] laanwj pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/fd96d54f39cf...c4cc8d9930ec
< bitcoin-git> bitcoin/master 4b62bdf Ben Woosley: Wallet: Refactor ReserveKeyFromKeyPool for safety...
< bitcoin-git> bitcoin/master c4cc8d9 Wladimir J. van der Laan: Merge #13252: Wallet: Refactor ReserveKeyFromKeyPool for safety...
< bitcoin-git> [bitcoin] laanwj closed pull request #13252: Wallet: Refactor ReserveKeyFromKeyPool for safety (master...refactor_wallet_RKFKP) https://github.com/bitcoin/bitcoin/pull/13252
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 new commits to master: https://github.com/bitcoin/bitcoin/compare/c4cc8d9930ec...61fcef0f89c4
< bitcoin-git> bitcoin/master 174f7c8 Andrew Chow: Use a struct for arguments and nested map for categories...
< bitcoin-git> bitcoin/master 4f8704d Andrew Chow: Give an error and exit if there are unknown parameters...
< bitcoin-git> bitcoin/master 9030557 Andrew Chow: Test gArgs erroring on unknown args
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13112: Throw an error for unknown args (master...gargs-know-args) https://github.com/bitcoin/bitcoin/pull/13112
< jonasschnelli> My testnet seed – after a report from an lnd dev – does report a high amount of ABC and BCash and classic peers.
< jonasschnelli> They all have protocol number 80002 and may disconnect on requesting a block
< jonasschnelli> Not sure if they are on a different chain or it they are just dishonest, spy-peers.
< jonasschnelli> It is maybe a cat and mouse game, but eventually we should add more checks to sipa seeds, Like requesting a block around the current best known tip (would require a bitcoind on the seeder)
< jonasschnelli> *sipas seed software
<@wumpus> jonasschnelli: yes...
< jonasschnelli> Maybe the only solutions are enough honest peers that will reduce the amount of served dishnoest peers
< bitcoin-git> [bitcoin] laanwj opened pull request #13349: bench: Don't return a bool from main (master...2017_05_bench_warning) https://github.com/bitcoin/bitcoin/pull/13349
< sipa> TIL C++11 contains regex matching, and we're even using it in bench_bitcoin
< sipa> wumpus: are we moving away from trusty in gitian as well?
< bitcoin-git> [bitcoin] lmanners opened pull request #13350: [tests] Add logging to provide anchor points when debugging failures. (master...testlogging) https://github.com/bitcoin/bitcoin/pull/13350
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13351: wallet: Prevent segfault when sending to unspendable witness (master...Mf1806-walletUnspendableWitnessIsMine) https://github.com/bitcoin/bitcoin/pull/13351
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 new commits to master: https://github.com/bitcoin/bitcoin/compare/61fcef0f89c4...472fe8a2ce9f
< bitcoin-git> bitcoin/master d8c4998 practicalswift: Fix typos
< bitcoin-git> bitcoin/master 472fe8a MarcoFalke: Merge #13069: docs: Fix typos...
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #13069: docs: Fix typos (master...typos-201804) https://github.com/bitcoin/bitcoin/pull/13069
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13352: qa: Avoid checking reject code for now (master...Mf1806-qaRejectCode) https://github.com/bitcoin/bitcoin/pull/13352
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #13353: qa: Fixup setting of PATH env var (master...Mf1806-qaPathBitcoind) https://github.com/bitcoin/bitcoin/pull/13353