< bitcoin-git> [bitcoin] fanquake pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/50e019a97a5b...ea7926527ce3
< bitcoin-git> bitcoin/master faaee81 MarcoFalke: build: Require C++17 compiler
< bitcoin-git> bitcoin/master fac7198 MarcoFalke: Use std::make_unique
< bitcoin-git> bitcoin/master ea79265 fanquake: Merge #20413: build: Require C++17 compiler
< bitcoin-git> [bitcoin] fanquake merged pull request #20413: build: Require C++17 compiler (master...2011-buildCxx17) https://github.com/bitcoin/bitcoin/pull/20413
< bitcoin-git> [bitcoin] fanquake opened pull request #20421: build: miniupnpc 2.2.0 (master...miniupnpc_220) https://github.com/bitcoin/bitcoin/pull/20421
< bitcoin-git> [bitcoin] fanquake opened pull request #20422: build: mac deployment unification (master...macdeploy_unify) https://github.com/bitcoin/bitcoin/pull/20422
< * fanquake> shouts at the whitespace linter
< sipa> a worthy shouting partner, that is
< miketwen_> don't forget your \u180E - Mongolian Vowel Separator
< sipa> 😱
< wumpus2> i didn't actually label rc1 yet
< bitcoin-git> [bitcoin] laanwj pushed 1 commit to 0.21: https://github.com/bitcoin/bitcoin/compare/6cde7bb9b26c...80496f9e8116
< bitcoin-git> bitcoin/0.21 80496f9 Wladimir J. van der Laan: build: Set msvc builds's CLIENT_VERSION_IS_RELEASE
< wumpus> the make-tag script can now check all you favorite extra msvc build version strings too https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/66/files
< MarcoFalke> #proposedmeetingtopic 0.20.2
< wumpus> sure can we first do 0.21.0rc1
< MarcoFalke> I'd guess it makes sense to do them at approximately the same time, so that gitian builders can run both in a row
< wumpus> sure
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/ea7926527ce3...cddcd22ab326
< bitcoin-git> bitcoin/master dd7b5f4 Jon Atack: script: fix deprecation warning in makeseeds.py
< bitcoin-git> bitcoin/master 961f148 Jon Atack: doc: update contrib/seeds/README dnspython installation info
< bitcoin-git> bitcoin/master cddcd22 Wladimir J. van der Laan: Merge #20288: script, doc: contrib/seeds updates
< bitcoin-git> [bitcoin] laanwj merged pull request #20288: script, doc: contrib/seeds updates (master...contrib-seeds-fixups) https://github.com/bitcoin/bitcoin/pull/20288
< bitcoin-git> [bitcoin] laanwj pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/cddcd22ab326...888c22e0dd35
< bitcoin-git> bitcoin/master 6c7e8f0 Carl Dong: depends: Allow relative CONFIG_SITE path env var
< bitcoin-git> bitcoin/master 618cbd2 Carl Dong: lint: Also lint files with shellcheck directive
< bitcoin-git> bitcoin/master 46756a6 Carl Dong: depends: Fix PYTHONPATH setting in config.site.in
< bitcoin-git> [bitcoin] laanwj merged pull request #20359: depends: Various config.site.in improvements and linting (master...2020-11-config-site-cleanup) https://github.com/bitcoin/bitcoin/pull/20359
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/888c22e0dd35...47b6ad837c07
< bitcoin-git> bitcoin/master 7087440 fanquake: depends: native_ds_store 1.3.0
< bitcoin-git> bitcoin/master 47b6ad8 Wladimir J. van der Laan: Merge #20333: build: remove native_biplist dependency
< bitcoin-git> [bitcoin] laanwj merged pull request #20333: build: remove native_biplist dependency (master...no_more_biplist) https://github.com/bitcoin/bitcoin/pull/20333
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/47b6ad837c07...e12ad7f38346
< bitcoin-git> bitcoin/master d9141a0 Anthony Towns: doc: clarify CRollingBloomFilter size estimate
< bitcoin-git> bitcoin/master e12ad7f Wladimir J. van der Laan: Merge #19968: doc: clarify CRollingBloomFilter size estimate
< bitcoin-git> [bitcoin] laanwj merged pull request #19968: doc: clarify CRollingBloomFilter size estimate (master...bloom-doc) https://github.com/bitcoin/bitcoin/pull/19968
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e12ad7f38346...fbb2bee82d83
< bitcoin-git> bitcoin/master 6f4e393 Sebastian Falbesoner: refactor: remove use of boost::algorithm::replace_first
< bitcoin-git> bitcoin/master fbb2bee Wladimir J. van der Laan: Merge #20067: refactor: remove use of boost::algorithm::replace_first
< bitcoin-git> [bitcoin] laanwj merged pull request #20067: refactor: remove use of boost::algorithm::replace_first (master...20201003-get-rid-of-boost-replace_first) https://github.com/bitcoin/bitcoin/pull/20067
< bitcoin-git> [bitcoin] vasild closed pull request #20000: test: fix creation of "std::string"s with \0s (master...fix_base32_tests) https://github.com/bitcoin/bitcoin/pull/20000
< bitcoin-git> [bitcoin] vasild reopened pull request #20000: test: fix creation of "std::string"s with \0s (master...fix_base32_tests) https://github.com/bitcoin/bitcoin/pull/20000
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/fbb2bee82d83...1cc5e693c186
< bitcoin-git> bitcoin/master 330cb33 Fabrice Fontaine: src/randomenv.cpp: fix build on uclibc
< bitcoin-git> bitcoin/master 1cc5e69 Wladimir J. van der Laan: Merge #20358: src/randomenv.cpp: fix build on uclibc
< bitcoin-git> [bitcoin] laanwj merged pull request #20358: src/randomenv.cpp: fix build on uclibc (master...master) https://github.com/bitcoin/bitcoin/pull/20358
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/1cc5e693c186...d9180c50b689
< bitcoin-git> bitcoin/master 355d0c4 Karl-Johan Alm: contrib: add getcoins.py script to get coins from (signet) faucet
< bitcoin-git> bitcoin/master e9c8e6e Karl-Johan Alm: doc: add contrib/signet readme
< bitcoin-git> bitcoin/master d9180c5 Wladimir J. van der Laan: Merge #20145: contrib: add getcoins.py script to get coins from (signet) f...
< bitcoin-git> [bitcoin] laanwj merged pull request #20145: contrib: add getcoins.py script to get coins from (signet) faucet (master...202010-signet-getcoins) https://github.com/bitcoin/bitcoin/pull/20145
< Kiminuo> MarcoFalke, Hi Marco, could you say whether it's worth working on std::fs at this time? You have, I think, mentioned that `std::fs` is not supported by some OSs. So I just want to know whether it makes sense to work on this or let it wait a few months or a few years for next upgrade (https://github.com/bitcoin/bitcoin/pull/19245#issuecomment-730291399)
< MarcoFalke> It would mean that compilation on Ubuntu 18.04 no longer works, I think
< MarcoFalke> I might have to check again
< Kiminuo> Thanks for info
< wumpus> no opinion on timespan but one thing to be really careful with when transitioning to std::fs is that the unicode character subtleties still work, across OSes
< wumpus> including interaction between Qt and it, especially on windows there has been a history of issues there
< wumpus> unfortunately, locale stuff tends to be really awful in C standard libraries
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/d9180c50b689...9ab9665c74dd
< bitcoin-git> bitcoin/master 32def8d Peter Bushnell: Catch ios_base::failure specifically
< bitcoin-git> bitcoin/master 7486e27 Bushstar: Tests: Unit test related to WalletDB ReadKeyValue
< bitcoin-git> bitcoin/master 9ab9665 Wladimir J. van der Laan: Merge #15710: wallet: Catch ios_base::failure specifically
< bitcoin-git> [bitcoin] laanwj merged pull request #15710: wallet: Catch ios_base::failure specifically (master...walletdb-readthrow) https://github.com/bitcoin/bitcoin/pull/15710
< Kiminuo> wumpus, Yes, I have tried to collect PRs for "fs" to see what the issues were. I can only say that it *tentatively seems* that std::fs behaves nicer wrt unicode than Boost. But it will be a long ride and maybe I'm wrong. It's hard to guess at this point.
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/9ab9665c74dd...71d068db4058
< bitcoin-git> bitcoin/master fa19bb2 MarcoFalke: remove dead rpc code
< bitcoin-git> bitcoin/master faaf9c5 MarcoFalke: remove CRPCCommand constructor that takes rpcfn_type function pointer
< bitcoin-git> bitcoin/master 71d068d MarcoFalke: Merge #18531: rpc: remove deprecated CRPCCommand constructor
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #18531: rpc: remove deprecated CRPCCommand constructor (master...2004-rpcMan) https://github.com/bitcoin/bitcoin/pull/18531
< Kiminuo> https://stackoverflow.com/a/53531186 - It seems, you can compile Bitcoin codebase on Ubuntu 18.04 with std::filesystem only with GCC 8.
< Kiminuo> https://github.com/bitcoin/bitcoin/blob/master/doc/dependencies.md - mentions that the lowest supported GCC version is 7.
< Kiminuo> So this is a problem.
< Kiminuo> MarcoFalke, I have verified that vanilla Ubuntu 18.04 reports: filesystem: No such file or directory
< Kiminuo> #include <filesystem>
< Kiminuo> So I guess. That's game over :)
< MarcoFalke> At some point we'll drop compile support for 18.04
< MarcoFalke> Maybe 23.0?
< Kiminuo> Yeah, that's what I mean. Game over until then.
< MarcoFalke> Can bionic clang compile it?
< Kiminuo> That's beyond my capability to try.
< MarcoFalke> apt install clang-10 llvm-10 && ./configure CC=clang-10 CXX=clang-10++ && make
< Kiminuo> thanks
< MarcoFalke> std::fs is in clang-7, I think. So it should work
< Kiminuo> https://pastebin.com/hMM1DbrV I'm getting this with " ./configure CC=clang-10 CXX=clang-10++"
< Kiminuo> https://pastebin.com/HLHmF5Me config.log
< hebasto> bionic has g++-8 package in its repo https://packages.ubuntu.com/bionic/devel/g++-8
< MarcoFalke> hebasto: Good point
< hebasto> and version 8.4 should be enough for std::filesystem as it was introduced in 8.1
< MarcoFalke> oh, it is called clang++-10
< Kiminuo> hebasto, https://github.com/kiminuo/bitcoin/tree/feature/2020-11-19-replace-boost-filesystem-with-cpp17-filesystem could you possibly try that on Ubuntu 18.04, if you have one?
< Kiminuo> I'm trying but I can't get rid of the C++ compiler cannot create executables
< Kiminuo> error
< Kiminuo> It looks like I have broken my Ubuntu 18.04 :)
< Kiminuo> Still trying though
< MarcoFalke> will try. One sec
< Kiminuo> thank you
< Kiminuo> ./configure CC=clang-10 CXX=clang++-10 BDB_LIBS="-L${BDB_PREFIX}/lib -ldb_cxx-4.8" BDB_CFLAGS="-I${BDB_PREFIX}/include" reports now:
< Kiminuo> ./logging.h:108:38: error: expected expression
< Kiminuo> std::list<std::function<void(const std::string&)>>::iterator PushBackCallback(std::function<void(const std::string&)> fun)
< Kiminuo> ^
< MarcoFalke> Checked "g++ (Ubuntu 7.5.0-3ubuntu1~18.04)" fails as expected. Checked g++-8 works.
< MarcoFalke> Kiminuo: You are missing an #include functional
< Kiminuo> ok, interesting
< wumpus> Kiminuo: glad to hear that it doesn't seem worse at first glance :)
< wumpus> I guess supporting two file system backends is a bit too much or we could have a period in which it's possible to choose
< Kiminuo> wumpus, supporting two file system libraries is difficult and probably a little bit dangerous (due to small differences)
< Kiminuo> well, it's hard to let users to choose. There's no selling point for that.
< Kiminuo> Either Boost filesystem is better or std::filesystem is better.
< wumpus> it was the original idea behind fs.h, and we need to be aware of the differences anyhow, but yea
< wumpus> it's not as much of a drop-in replacement as thought at the time
< Kiminuo> right, but it brings more complexity and I'm not sure if there is any benefit. I don't see any
< wumpus> well one is that the std::fs using code would already be tested at the time it becomes mandatory, less of a 'flag day'
< MarcoFalke> Anyone mind to ACK https://github.com/bitcoin-core/univalue/pull/24 ?
< Kiminuo> wumpus, for that to work, you would need to wrap more functions in fs.h, then it would work as you say. If that's what you mean.
< wumpus> MarcoFalke:done
< Kiminuo> And that would be probably useful
< MarcoFalke> thx
< Kiminuo> because it would also nicely show what the differences between those fs implementations are
< wumpus> Kiminuo: yes, the idea would be for fs.h to encapsulate the differences as much of possible
< Kiminuo> right, I finally understand. Sorry.
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/71d068db4058...7aa94569ce1a
< bitcoin-git> bitcoin/master ea93bbe practicalswift: init: Fix incorrect warning "Reducing -maxconnections from N to N-1, becau...
< bitcoin-git> bitcoin/master 7aa9456 Wladimir J. van der Laan: Merge #20024: init: Fix incorrect warning "Reducing -maxconnections from N...
< bitcoin-git> [bitcoin] laanwj merged pull request #20024: init: Fix incorrect warning "Reducing -maxconnections from N to N-1, because of system limitations" (master...fix-incorrect-warning) https://github.com/bitcoin/bitcoin/pull/20024
< bitcoin-git> [bitcoin] laanwj pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/7aa94569ce1a...c4d1e24f5480
< bitcoin-git> bitcoin/master 136d96b Sebastian Falbesoner: test: use wait_for_{block,header} helpers in p2p_fingerprint.py
< bitcoin-git> bitcoin/master 6b56c1f Sebastian Falbesoner: test: remove last_{block,header}_equals() in p2p_fingerprint.py
< bitcoin-git> bitcoin/master c4d1e24 Wladimir J. van der Laan: Merge #20047: test: use wait_for_{block,header} helpers in p2p_fingerprint...
< bitcoin-git> [bitcoin] laanwj merged pull request #20047: test: use wait_for_{block,header} helpers in p2p_fingerprint.py (master...20200930-test-use-wait-for-block-header-in-fingerprint-py) https://github.com/bitcoin/bitcoin/pull/20047
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20424: build: Update univalue subtree (master...2011-subtreeUnivalue) https://github.com/bitcoin/bitcoin/pull/20424
< bitcoin-git> [bitcoin] glozow closed pull request #20025: validation/util: add GetTransactionFee (master...2020-09-getfee) https://github.com/bitcoin/bitcoin/pull/20025
< bitcoin-git> [bitcoin] MarcoFalke pushed 3 commits to master: https://github.com/bitcoin/bitcoin/compare/c4d1e24f5480...884bde510e2d
< bitcoin-git> bitcoin/master eefe194 John Newbery: [net] Consolidate logic around calling CAddrMan::Connected()
< bitcoin-git> bitcoin/master 0bfce9d John Newbery: [addrman] Fix Connected() comment
< bitcoin-git> bitcoin/master 884bde5 MarcoFalke: Merge #20291: [net] Consolidate logic around calling CAddrMan::Connected()...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20291: [net] Consolidate logic around calling CAddrMan::Connected() (master...2020-11-consolidate-addrman-connect) https://github.com/bitcoin/bitcoin/pull/20291
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/884bde510e2d...848d66519c39
< bitcoin-git> bitcoin/master 0000a0c MarcoFalke: Remove confusing and almost useless "unexpected version" warning
< bitcoin-git> bitcoin/master 848d665 Wladimir J. van der Laan: Merge #20054: Remove confusing and useless "unexpected version" warning
< bitcoin-git> [bitcoin] laanwj merged pull request #20054: Remove confusing and useless "unexpected version" warning (master...2010-valRemVerWarn) https://github.com/bitcoin/bitcoin/pull/20054
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/848d66519c39...04670ef81ea2
< bitcoin-git> bitcoin/master 21f2433 Michael Dietz: test: run mempool_spend_coinbase.py even with wallet disabled
< bitcoin-git> bitcoin/master 04670ef Wladimir J. van der Laan: Merge #20385: test: run mempool_spend_coinbase.py even with wallet disable...
< bitcoin-git> [bitcoin] laanwj merged pull request #20385: test: run mempool_spend_coinbase.py even with wallet disabled (master...mempool-tests-to-miniwallet) https://github.com/bitcoin/bitcoin/pull/20385
< wumpus> can someone please check if this minor documentation change is correct: #20329
< gribble> https://github.com/bitcoin/bitcoin/issues/20329 | docs/descriptors.md: Remove hardened marker in the path after xpub by dgpv · Pull Request #20329 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/04670ef81ea2...db58b857f77a
< bitcoin-git> bitcoin/master dc80a7d Dmitry Petukhov: docs/descriptors.md: Remove hardened marker in the path after xpub
< bitcoin-git> bitcoin/master db58b85 MarcoFalke: Merge #20329: docs/descriptors.md: Remove hardened marker in the path afte...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20329: docs/descriptors.md: Remove hardened marker in the path after xpub (master...fix-descriptors-md-hardened-after-xpub) https://github.com/bitcoin/bitcoin/pull/20329
< bitcoin-git> [bitcoin] practicalswift opened pull request #20425: fuzz: Make addrman fuzzing harness deterministic (master...fuzzers-make-addrman-harness-deterministic) https://github.com/bitcoin/bitcoin/pull/20425
< hebasto> jonasschnelli: MarcoFalke: could https://github.com/bitcoin-core/gui/pull/46 be considered early for 0.22 to make compiling on macos more pleasant?
< bitcoin-git> [gui] MarcoFalke merged pull request #46: refactor: Fix deprecation warnings when building against Qt 5.15 (master...200809-depr) https://github.com/bitcoin-core/gui/pull/46
< bitcoin-git> [bitcoin] MarcoFalke pushed 6 commits to master: https://github.com/bitcoin/bitcoin/compare/db58b857f77a...0a267f4eb885
< bitcoin-git> bitcoin/master b02264c Hennadii Stepanov: qt, refactor: Fix 'QDateTime is deprecated' warnings
< bitcoin-git> bitcoin/master fa5749c Hennadii Stepanov: qt, refactor: Fix 'pixmap is deprecated' warnings
< bitcoin-git> bitcoin/master 8e12d69 Hennadii Stepanov: qt, refactor: Fix 'QFlags is deprecated' warnings
< hebasto> MarcoFalke: thanks!
< bitcoin-git> [bitcoin] jonatack opened pull request #20426: wallet: allow zero-fee fundrawtransaction/walletcreatefundedpsbt and other fixes (master...fee_rate_followups) https://github.com/bitcoin/bitcoin/pull/20426
< MarcoFalke> hi
< fjahr> hi
< hebasto> hi
< wumpus> #startmeeting
< core-meetingbot> Meeting started Thu Nov 19 19:00:41 2020 UTC. The chair is wumpus. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< kanzure> hi
< jonasschnelli> hi
< wumpus> #bitcoin-core-dev Meeting: achow101 aj amiti ariard bluematt cfields Chris_Stewart_5 digi_james dongcarl elichai2 emilengler fanquake fjahr gleb gmaxwell gwillen hebasto instagibbs jamesob jb55 jeremyrubin jl2012 jnewbery jonasschnelli jonatack jtimon kallewoof kanzure kvaciral lightlike luke-jr maaku marcofalke meshcollider michagogo moneyball morcos nehan NicolasDorier paveljanik
< wumpus> petertodd phantomcircuit promag provoostenator ryanofsky sdaftuar sipa vasild wumpus
< jonatack> hi
< luke-jr> hi
< achow101> hi
< sipa> hi
< wumpus> there is one proposed meeting topic for this week: 0.20.2 (MarcoFalke)
< miketwenty1> hi
< murch> hi
< wumpus> I wanted to tag rc1 today but apparently some things have been tagge 0.21 since: https://github.com/bitcoin/bitcoin/pulls?q=is%3Aopen+is%3Apr+milestone%3A0.21.0
< wumpus> I guess if these are really urgent, please help reviewing them
< MarcoFalke> wumpus: Don't worry abou those. They are minor RPC inconsistencies
< hebasto> the tagged for backporting, no?
< wumpus> if not, let's move them to the 0.21.1 milestone instead
< luke-jr> wumpus: feature_segwit test is failing too
< MarcoFalke> I am sure we will find more issus for rc2
< sipa> inconsistencies in newly introduced stuff?
< jnewbery> hi
< MarcoFalke> sipa: The feerate things ...
< luke-jr> sipa: what we discussed the other night
< sipa> sounds like it - if so i think we'll want those in 0.21 anyway i guess
< murch> Sending feerates were restricted to >0 instead of >=0
< murch> mea culpa, I missed it in the review
< MarcoFalke> Also, "" == null 0==null
< MarcoFalke> and the third one a minor issue with upgradewallet
< sipa> no objection to doing rc1 without them in that case, but if it means there'll be an rc2 anyway.... up to wumpus i guess
< wumpus> anyhow right now they're holding up the release
< luke-jr> more of a beta1 than a rc1 in that case :P
< MarcoFalke> I'd be highly surprised if this was the first major release with just one rc
< sipa> ha, fair
< MarcoFalke> we'll find more bugs, don't worry
< wumpus> anyhow merging the feerate last minute was probaly ill advised so I understand if last minute issues came up
< sipa> luke-jr: i wonder why you're the only one hitting this
< MarcoFalke> wumpus: It had to be merged (or everything reverted)
< sipa> luke-jr: is signing or hashing particularly slow on your system?
< luke-jr> wumpus: well, it was really a bugfix for the explicit fee rate mess merged months ago
< wumpus> MarcoFalke: yes, but it should have been merged sooner in the release cycle
< luke-jr> sipa: I saw it on CI too?
< sipa> oh, ok
< MarcoFalke> wumpus: Agree
< jonatack> I think they've been addressed and those PRs are close to RFM. There is a lot of test coverage in place now, which helps.
< MarcoFalke> luke-jr: feature_taproot?
< luke-jr> sipa: no reason it would be - I have 16 SMT4 cores
< sipa> MarcoFalke: there is a simple fix; aj posted one the other day, i think an even simpler one is possible
< sipa> i'll PR soon
< MarcoFalke> wumpus: This release is the heavies ever in features merged per time, I think
< MarcoFalke> sipa: Thx, I'll ack
< luke-jr> MarcoFalke: yes, sorry
< MarcoFalke> so the delay was expected
< wumpus> MarcoFalke: yes, seems like it :)
< luke-jr> MarcoFalke: looks like it simply builds a huge wallet and then times out in coin selection
< sipa> yeah, or quadratic hashing of legacy spends
< MarcoFalke> luke-jr: No coin selection. It is signrawtxwithwallet
< MarcoFalke> (or a bug in the wallet)
< luke-jr> I thoguht it was the create
< wumpus> it fails on 0.21 branch but not on master?
< aj> sipa, luke-jr: want me to PR that patch?
< luke-jr> aj: sgtm
< MarcoFalke> wumpus: It fails on slow CPUs ;)
< luke-jr> MarcoFalke: my CPU is nothing close to slow..
< MarcoFalke> CI should be unaffected, because it has the timeouts cranked up to max
< wumpus> I haven't noticed any tests failing on master but haven't locally run the tests for the 0.21 branch yet
< wumpus> (because there is no divergence yet)
< achow101> I've had feature_taproot fail occasionally, but only with the test runner
< MarcoFalke> luke-jr: Its not intel, so it doesn't have the speedup-backdoors
< sipa> that could be it
< MarcoFalke> And running test_runner with high --jobs might also cause it
< sipa> SHA-NI hashing is a lot faster
< achow101> MarcoFalke: that's what I ran into
< jonatack> achow101: same here
< wumpus> it would definitely be good to not have the tests dependent on specific intel optimizations :)
< sipa> it's just silly
< luke-jr> aj's optimisation seems like a good idea even with longer timeouts
< sipa> we could also split the test in two, and run it once for post-activation and once for pre-activation
< michaelfolkson> sipa said he runs -j60. I'm assuming that is too high. Something like -j5 better?
< luke-jr> lol?
< wumpus> disable-all-timeouts mode would be useful in that case xD
< michaelfolkson> Or that's what I remembered. Am I remembering incorrectly...?
< sipa> -j60 works fine here
< MarcoFalke> wumpus: The ci runs it, but we can't enable that locally
< sipa> and seems around the fastest in overall clock time
< luke-jr> michaelfolkson: as long as -j is set sensibly, the number itself shouldn't make problems
< MarcoFalke> I guess we can scale the timeout with --jobs
< jonatack> michaelfolkson: i've adopted -j60 since sipa mentioned it, and added the suggestion as an option to try in the compile guide
< luke-jr> I was getting it 100% of the time, with just the one test
< wumpus> I'm not sure that needs to be done automatically, but instructions on how to do it for people running into timeouts would be useful
< sipa> luke-jr: i think it's fair to say the test is just broken, and it's masked by the fact that almost everyone runs it on hardware where SHA256 is sufficiently optimized to mask the issue
< jonatack> michaelfolkson: (not for make, just for running the functional suite)
< wumpus> hehe
< MarcoFalke> Jup, each raise of a timeout error could mention "You can use --timeout_factor to scale the timeouts"
< luke-jr> MarcoFalke: but it shouldn't be necessary
< wumpus> MarcoFalke: good idea!
< aj> sipa: seems like there's something wrong with signrawtx in that it's taking 20s (for me) or 30s+ (for luke) as well though
< luke-jr> if a test hits it normally, that means the timeout is too low
< michaelfolkson> jonatack: Let me try make with -j60... :)
< miketwenty1> does -j1 or no -j flag fail?
< MarcoFalke> with enough ram you can do -j 999
< sipa> miketwenty1: -j1 is just painfully slow
< luke-jr> miketwenty1: I was running the test by itself, nothing else
< sipa> aj: quadratic hashing of enormous (non-standard!) transactions is a known issue
< miketwenty1> i know it's slow i've compiled bitcoin like 5 times today with no -j flag
< wumpus> the thing with test timeouts (especially for CPU intensive ones) is that it's kind of a random barrel shoot, you can always have a slower machine where it fails
< MarcoFalke> sipa: That patch would still fail intermittently
< sipa> MarcoFalke: how so?
< luke-jr> miketwenty1: alias make='make -j60'
< MarcoFalke> sec ...
< jonatack> miketwenty1: use ccache? see doc/productivity.md
< jonatack> miketwenty1: also build only what you need
< miketwenty1> the hardware that's compiling is purposely small
< wumpus> alias invokeoomkiller='make -j60'
< luke-jr> wumpus: unless the timeout is set high enough it only fails when there's hanging
< luke-jr> wumpus: lol
< luke-jr> ok, I really do make -j32
< MarcoFalke> sipa: Maybe coin selection picking only the small coins?
< luke-jr> (but having it aliased really helps me use it)
< sipa> MarcoFalke: how would it fail?
< miketwenty1> what is the logical way to calculate how many threads or the -j<n> count you can use for a machine?
< MarcoFalke> sipa: It picks a lot of small coins, which takes long to sign?
< MarcoFalke> coin selection isn't deterministic and the amounts in the test aren't either
< sipa> MarcoFalke: with just 70% of the balance there should be no need for many tiny coins
< luke-jr> miketwenty1: start with number of cores + 1
< luke-jr> miketwenty1: possibly including SMT in core count
< sipa> miketwenty1: for building, not more than your number of threads + 1, and assume around 1 GB of memory per -j
< wumpus> miketwenty1: in my experience it's about 1.5GB memory per -j, for the C++ build, for running the functional tests it's different though
< sipa> miketwenty1: for functional tests, you can go way higher than what your thread count permits
< MarcoFalke> sipa: I guess we could try
< sipa> MarcoFalke: afaik the pessimal behavior of coin selections only occurs when you're really close to the balance
< sipa> luke-jr: does my patch fix things for you? (aj's may work too, i think in general mine may be even faster)
< MarcoFalke> Anyway back to the 0.21 topic, I suggest to ship rc1 soon, so that testing can start
< wumpus> heh that's like with place and route on FPGAs
< luke-jr> sipa: too many worktrees open to test right now, maybe after meeting
< sipa> luke-jr: sure
< MarcoFalke> If we are lucky and no issues are found we can ship 0.21 early-mid december
< wumpus> MarcoFalke: so maybe do a rc1 without merging anything more?
< MarcoFalke> I'd say so
< wumpus> okay, going to tag it after the meeting
< sipa> wumpus: with the plan of doing an rc2 anyway?
< luke-jr> I'd call it beta1, but dunno how easy that is
< MarcoFalke> sipa: I'd say so too
< MarcoFalke> The fixups are just for edge-cases in the rpc
< sipa> indeed
< MarcoFalke> (and they have tests)
< wumpus> right, major versions tend to have 3-5 rcs anyway
< sipa> wumpus: if doing rc1 now is fine by you, it's fine by me
< wumpus> sure
< luke-jr> might want to add a "Known issues" to the announce
< luke-jr> so people don't report them
< wumpus> I intended to do the rc1 tag right after the branch but was distracted by some msvc version stuff xD
< sipa> MarcoFalke: did 17 runs with my patch, no failures
< MarcoFalke> sipa: It passed for you before, too
< MarcoFalke> luke-jr should test maybe overnight in a loop or so
< jonatack> a propos editing the release notes in the wiki, istm that is still feasible until -final, right?
< MarcoFalke> jonatack: Jup
< wumpus> jonatack: yep
< MarcoFalke> About 0.20.2, we should ship that soon as well
< luke-jr> MarcoFalke: bonus: I have Chromium building now :P
< wumpus> #topic 0.20.2
< core-meetingbot> topic: 0.20.2
< MarcoFalke> ^ Though, those need review
< MarcoFalke> One is a trivial revert (empty diff can be reviewed by anyone)
< MarcoFalke> The other is a wallet fix, so needs the wallet people to take a look
< MarcoFalke> wrong milestone link (sry)
< wumpus> going back and forth on the wtxid relay is a bit ugly, but if there is no confidence in it anymore then it's good to revert it
< wumpus> I remember it was quite a difficult merge in the first place, maybe we shouldn't have done it, but I remember some were saying it was really important to get it in at the time
< achow101> the wallet fix just does what we do in master. it's not quite a backport because we kind of got to this result in master by accident through 3 or so prs
< aj> wumpus: i think there's reasonable confidence, but there's no need for it anymore either
< wumpus> aj: what removed the need for it?
< MarcoFalke> achow101: Have the "3 or so prs" touched other parts than just this single function?
< achow101> MarcoFalke: yes
< aj> wumpus: #19620 which got backported to 0.19 and 0.20 after the wtxid backport PR was already open
< gribble> https://github.com/bitcoin/bitcoin/issues/19620 | Add txids with non-standard inputs to reject filter by sdaftuar · Pull Request #19620 · bitcoin/bitcoin · GitHub
< MarcoFalke> achow101: That might make it harder to review
< aj> wumpus: (19680 and 19681 were the backports)
< wumpus> sipa: thanks
< jnewbery> wumpus: should be trivial to back it out. It wasn't actually too difficult to backapply, and as Marco says, if the diff after the revert is empty then it's a trivial ACK
< wumpus> jnewbery: yes, it's easy to revert (not much happend on the 0.20 branch since), I was just confused about the change in priorities suddenly
< jnewbery> wumpus: me too :)
< MarcoFalke> wumpus: I think there was confusion generally, and probably an assumption that no 0.20 release was planned any time soon
< wumpus> MarcoFalke: yes, I do remember that we wanted to do the next 0.20 release after 0.21.0
< luke-jr> not so sure about the latter
< MarcoFalke> wumpus: Jup, that was under the assumption that wtxid relay was going to be backported
< wumpus> in any case please review the revert and other PRs for 0.20.2
< wumpus> when they're merged we can tag 0.20.2rc1 as well
< wumpus> any other topics?
< wumpus> I guess we can pick up high priority for review again
< wumpus> #topic High priority for review
< core-meetingbot> topic: High priority for review
< wumpus> is the current list still relevant?
< MarcoFalke> Can I add #19893 ?
< gribble> https://github.com/bitcoin/bitcoin/issues/19893 | test: Remove or explain syncwithvalidationinterfacequeue by MarcoFalke · Pull Request #19893 · bitcoin/bitcoin · GitHub
< wumpus> sure
< jonasschnelli> I just removed #18242 (until the AEAD overhaul has been finalized)
< gribble> https://github.com/bitcoin/bitcoin/issues/18242 | Add BIP324 encrypted p2p transport de-/serializer (only used in tests) by jonasschnelli · Pull Request #18242 · bitcoin/bitcoin · GitHub
< achow101> #20040 pls
< gribble> https://github.com/bitcoin/bitcoin/issues/20040 | wallet: Refactor OutputGroups to handle fees and spending eligibility on grouping by achow101 · Pull Request #20040 · bitcoin/bitcoin · GitHub
< wumpus> achow101: jonasschnelli added
< jnewbery> I'd like to add #19910, which is next in the #19398 sequence
< gribble> https://github.com/bitcoin/bitcoin/issues/19910 | net processing: Move peer_map to PeerManager by jnewbery · Pull Request #19910 · bitcoin/bitcoin · GitHub
< gribble> https://github.com/bitcoin/bitcoin/issues/19398 | Move remaining application layer data to net processing · Issue #19398 · bitcoin/bitcoin · GitHub
< wumpus> jnewbery: added too
< jnewbery> thanks wumpus!
< wumpus> I think that concludes the meeting, thanks everyone
< wumpus> #endmeeting
< core-meetingbot> topic: Bitcoin Core development discussion and commit log | Feel free to watch, but please take commentary and usage questions to #bitcoin | Channel logs: http://www.erisian.com.au/bitcoin-core-dev/, http://gnusha.org/bitcoin-core-dev/ | Meeting topics http://gnusha.org/bitcoin-core-dev/proposedmeetingtopics.txt / http://gnusha.org/bitcoin-core-dev/proposedwalletmeetingtopics.txt
< core-meetingbot> Meeting ended Thu Nov 19 19:47:46 2020 UTC.
< jonatack> o/
< nehan> 8
< luke-jr> 9
< nehan> oops.
< sipa> a
< achow101> rc1 soon?
< luke-jr> ♥ sipa
< aj> sipa: your fundrawtx patch seems to take 0.2s rather than 19.8s for me
< luke-jr> btw, 0bin is a nuisance for patches… :p
< sipa> luke-jr: use "copy to clipboard"; that avoids some formatting/indenting
< sipa> i want to try the patch on my odroid (as it also has unoptimized SHA256)... but it's been over a year since i logged into it and i have no idea what its password is
< sipa> i'm even more surprised it's still running
< luke-jr> sipa: yes, and then move the clipboard to my dev side, and can no longer see the patch URL in my BASH history. :/
< bitcoin-git> [bitcoin] laanwj pushed tag v0.21.0rc1: https://github.com/bitcoin/bitcoin/compare/v0.21.0rc1
< wumpus> ^^
< achow101> \o/
< MarcoFalke> \o/
< hebasto> \o/
< sipa> \o/
< luke-jr> oh no
< luke-jr> jk
< emzy> YES!!!
< meshcollider> \o/
< emzy> powering up my build machine :)
< emzy> And searching my physical PGP-key.
< aj> sipa: if i change it from 70% to 99% it takes 1.5s instead
< aj> sipa: but hmm, if i set it to 100% with subtraceFeeFromOutputs I get a "Transaction too large" error, so doesn't this just give the same behaviour as when sendtoaddress was used?
< sipa> aj: oh, hmm.
< sipa> your approach may be better then
< bitcoin-git> [bitcoin] luke-jr closed pull request #20121: configure: Allow users to explicitly enable libsecp256k1's GMP bignum support (master...secp256k1_allow_bignum) https://github.com/bitcoin/bitcoin/pull/20121
< bitcoin-git> [bitcoin] ajtowns opened pull request #20428: tests: split feature_taproot transfer of funds into smaller txs (master...202011-test-taproot-signmany) https://github.com/bitcoin/bitcoin/pull/20428
< luke-jr> sipa: aj: so what do I test now? or all done?
< aj> luke-jr: my patch is up at 20428 (above), re-test if you'd like but should be fine
< luke-jr> tACK'd
< luke-jr> aj: it'd be a clean merge to both branches if you rebase it onto fac865b72d5c0e01fce74b84ab21e5ebbf069327
< aj> sipa: hmmmm.... if i sort the unspends by amount first, i only need the top 500 of them to hit 70% (with ~4200 utxos remaining)
< sipa> aj: heh
< aj> sipa: top 500 seems to be about 90% of the value
< sipa> i think your first "top 500" is a typo
< aj> sipa: i was doing them in batches of 500, expecting i'd need more than one batch
< aj> luke-jr: rebased on top of the merge commit
< sipa> aj: you stated that the top 500 is both 70% and 90%... so i assume one of the two at least is wrong
< aj> sipa: it's just under 90%, but the first statement was nevertheless not a typo :)
< sipa> ok, not a typo, but still wrong?
< * sipa> very confused
< aj> sipa: i was rounding up to the nearest 500
< aj> sipa: (i'd tell you how many outputs were need for 70%, but i haven't worked it out yet. presumably it's 390ish?)
< sipa> <ultranitmode> rounding up, or rounding the nearest? </ultranitmode>
< aj> up, but i wanted to be clear i'm not skipping the next 500!
< aj> in case you thought the real answer was -300 coins were needed, i guess
< aj> sipa: 270 coins got me to 70%
< aj> sipa: so, sort lisunspent, take the 500 with highest amount, and be done with it maybe? or have a check that the top 500 are at least 70% of the total as well?
< sipa> aj: pretty sure you can take the top 10 outputs too, and be done with it :)
< sipa> only 10 transactions are performed with that amount
< miketwenty1> would this typically be the time people built, verified v0.21.0rc1 ? I would like to be signer going forward.
< sipa> miketwenty1: if you want to be a gitian signer for rc1, now is the time
< miketwenty1> sipa: hold on.. let me put my cape on..
< miketwenty1> k ready
< achow101> miketwenty1: yes
< miketwenty1> so.. i have gitian builds with 1 click.. only thing you need to specify is the tag.. and it builds with terraform module
< miketwenty1> im guessing this would belong in bitcoin-core or maybe personal repo
< luke-jr> aj: does your simplification break if unrelated parts of the test change in the futrue?
< sipa> luke-jr: very unlikely
< emzy> where do I get the Xcode-11.3.1-11C505-extracted-SDK-with-libcxx-headers.tar.gz for the gitian build?
< luke-jr> emzy: contrib/macdeploy/README.md
< luke-jr> emzy: be prepared for Apple "KYC"
< emzy> I have that :)
< achow101> emzy: yes
< miketwenty1> this is my first time doing a complete terraform from scratch build of a bitcoin with gitian process.. can someone tell me if they also got 073aaacb86e8898c4806ed10cd14d54869f31e353f86b60bb83f93ae89a3591d for bitcoin-0.21.0rc1-x86_64-linux-gnu.tar.gz
< achow101> miketwenty1: you can check against https://github.com/bitcoin-core/gitian.sigs
< miketwenty1> aww didn't know people were already sending them up
< miketwenty1> achow101: nice looks like we got the same result.. gives me confidence in this process i made
< emzy> 073aaacb86e8898c4806ed10cd14d54869f31e353f86b60bb83f93ae89a3591d bitcoin-0.21.0rc1-x86_64-linux-gnu.tar.gz
< emzy> match
< achow101> there's also a verify command you can run
< miketwenty1> verify against people who have already uploaded right?
< achow101> yes
< miketwenty1> didn't know you already updated lol
< miketwenty1> along with 1 other, hebasto
< emzy> I'm still on the macos build.
< achow101> my build runs pretty quickly :)
< emzy> Now that I have the right xcode version it will be ready soon :)
< miketwenty1> yeah i see we both have PR's open
< miketwenty1> why does win have the postfix "unsigned" ? even though we are signing it
< luke-jr> miketwenty1: it's referring to the OS vendor signature
< luke-jr> that's a 2nd step
< sipa> yeah, there'll be a -signed version later, once the signature (of the unsigned one) is posted
< miketwenty1> im confused.. like microsoft needs to create public signature for their OS that gitian process is using to create build?]
< sipa> miketwenty1: no, cory (who has the codesigning key) creates the signature
< sipa> unfortunately there isn't really a distributed way to do OS codesigning
< miketwenty1> who does it for linux?
< sipa> linux doesn't have codesigning
< miketwenty1> is that due to it being oss?
< miketwenty1> im not really following this
< luke-jr> sipa: well, it does, but the distros do it normally
< luke-jr> and it isn't using gitian
< sipa> right, and it's done at the package manager leve
< sipa> not at the binary level
< luke-jr> miketwenty1: basically the Windows/macOS signing is to get around [soft] DRM
< luke-jr> miketwenty1: without it, the OS will give users an ugly warning
< emzy> is there a doku how to produce the -signed versions?
< luke-jr> emzy: there's another gitian .yml
< luke-jr> that injects the signature
< miketwenty1> i see so this is when users run the .exe they will get a warning if it's "not verified" kinda thing?
< luke-jr> also, I don't think Cory has the key anymore… but I'm not sure how public it is who does
< sipa> miketwenty1: yes, that's its only purpose
< luke-jr> the principle is 3 gitian signers before the signature is produced
< miketwenty1> well we have 2 in bitcoin-core and emzy and i have PR's :)
< fanquake> achow has it #18425
< gribble> https://github.com/bitcoin/bitcoin/issues/18425 | releases: Update with new Windows code signing certificate by achow101 · Pull Request #18425 · bitcoin/bitcoin · GitHub
< sipa> ah oops
< emzy> luke-jr: tnx. I will take a look tomorrow.