< bitcoin-git> [bitcoin] BlockMechanic opened pull request #20565: Android : Ensure pic build for bdb (master...fix-bdb-android) https://github.com/bitcoin/bitcoin/pull/20565
< andytoshi> how does travis know the subtree remotes? if i try to run the ci/test/06_script.sh script locally i get a bunch of errors like
< andytoshi> subtree commit 3967d96bf184519eb98b766af665b4d4b072563e unavailable: cannot compare. Did you add and fetch the remote?
< andytoshi> and i see some manual instructions in the README for how to add these remotes
< andytoshi> but i don't understand how travis is doing it
< fanquake> some sort of black magic
< fanquake> unclear to me as well after a quick look in ci/
< fanquake> MarcoFalke can probably enlighten us
< sipa> does travis even check the remotes?
< fanquake> it's running the subtree checker against all the subtrees, which should require fetching the remotes
< sipa> sure, but if it doesn"t have the remotes it succeeds with a warning
< achow101> travis doesn't seem to have those remotes
< achow101> the most recent job has the same error, but the script doesn't fail so the job doesn't fail
< sipa> yes, it only does the local check iirc
< andytoshi> ah cool, i am no longer confused then :)
< sipa> that script should probablybtake a cmdline argument to decide whether to do the remote check
< fanquake> could be done while it's ported to cirrus
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/a0489f3472f3...e2ae6a2befad
< bitcoin-git> bitcoin/master 2f6fe4e Hennadii Stepanov: ci: Build with --enable-werror by default, and document exceptions
< bitcoin-git> bitcoin/master e2ae6a2 MarcoFalke: Merge #20182: ci: Build with --enable-werror by default, and document exce...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20182: ci: Build with --enable-werror by default, and document exceptions (master...201018-error) https://github.com/bitcoin/bitcoin/pull/20182
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20566: refactor: Use C++17 std::array where possible (master...2012-array) https://github.com/bitcoin/bitcoin/pull/20566
< wumpus> andytoshi: it doesn't really know, there's a manual fetch of all the repositories in there IIRC< it spooked me too once
< wumpus> or no there isn't, I don't really know
< wumpus> but I ran into some issues when I had to use a non-standard subtree for some temporary patches / experimentation in a PR (for a leveldb update)
< wumpus> on one hand I'm happy no longer being the only person running into this, on the other it would be good if it had better documentation
< wumpus> err wait the 'error' exit has a positive exit status, riight
< wumpus> I'll add an argument to the script instead
< wumpus> and help
< sipa> great
< bitcoin-git> [bitcoin] laanwj opened pull request #20567: test: Add option to git-subtree-check to do full check, add help (master...2020_12_subtree_check) https://github.com/bitcoin/bitcoin/pull/20567
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20568: rpc: Use FeeModes doc helper in estimatesmartfee (master...2012-rpcDocFee) https://github.com/bitcoin/bitcoin/pull/20568
< promag> MarcoFalke: why just those 2 cases in #20566?
< gribble> https://github.com/bitcoin/bitcoin/issues/20566 | refactor: Use C++17 std::array where possible by MarcoFalke · Pull Request #20566 · bitcoin/bitcoin · GitHub
< bitcoin-git> [bitcoin] jonasschnelli pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/e2ae6a2befad...257cf05f9b84
< bitcoin-git> bitcoin/master d3ef947 Hennadii Stepanov: build: Check that Homebrew's berkeley-db4 package is actually installed
< bitcoin-git> bitcoin/master 257cf05 Jonas Schnelli: Merge #20563: build: Check that Homebrew's berkeley-db4 package is actuall...
< bitcoin-git> [bitcoin] jonasschnelli merged pull request #20563: build: Check that Homebrew's berkeley-db4 package is actually installed (master...201203-bdb) https://github.com/bitcoin/bitcoin/pull/20563
< wumpus> oh no did we break appveyor
< fanquake> 😿
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #20569: test: Fix intermittent wallet_multiwallet issue with got_loading_error (master...2012-testWalletInt) https://github.com/bitcoin/bitcoin/pull/20569
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/257cf05f9b84...ca759bc743c9
< bitcoin-git> bitcoin/master 86e6add Adam Jonas: doc: rename CODEOWNERS to REVIEWERS
< bitcoin-git> bitcoin/master ca759bc Wladimir J. van der Laan: Merge #20200: doc: rename CODEOWNERS to REVIEWERS
< bitcoin-git> [bitcoin] laanwj merged pull request #20200: doc: rename CODEOWNERS to REVIEWERS (master...102020-fix-codeowners) https://github.com/bitcoin/bitcoin/pull/20200
< MarcoFalke> promag: Only const arrays can make use of C++17 std::array
< promag> MarcoFalke: I've added a comment there
< MarcoFalke> is appveyor broken again? Can't be
< wumpus> but it fails on #20567, which makes no sense as that script isn't run by appveyor
< gribble> https://github.com/bitcoin/bitcoin/issues/20567 | test: Add option to git-subtree-check to do full check, add help by laanwj · Pull Request #20567 · bitcoin/bitcoin · GitHub
< MarcoFalke> how is it possible that appveryor breaks our config every 12 days
< hebasto> could 20567 appveyor failure be spontaneous? re-run?
< MarcoFalke> hebasto: happening on all other builds as well, starting from now
< hebasto> ^ exactly
< jonasschnelli> fanquake: I think you can un-draft https://github.com/bitcoin/bitcoin/pull/19817
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/ca759bc743c9...dca80ffb45fc
< bitcoin-git> bitcoin/master fa86156 practicalswift: util: Allow Assert(...) to be used in all contexts
< bitcoin-git> bitcoin/master fac5efe MarcoFalke: util: Add Assume() identity function
< bitcoin-git> bitcoin/master faa0585 MarcoFalke: util: Remove probably misleading TODO
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20255: util: Add Assume() identity function (master...2010-assume) https://github.com/bitcoin/bitcoin/pull/20255
< wumpus> why is all the addrv2 discussion happening last minute between rcs
< jnewbery> there were lots of very large features merged just before feature freeze, so it's maybe not surprising that issues are being found now
< wumpus> my first public draft was apparently june 1, 2018, I posted it to the mailing list feb 18, 2019 (there we no replies at all), I created the PR for the BIPs repository on feb 27, 2019, it was merged jul 23, 2019. Vasild picked up the implementation april this year, and quite quickly had a working implementation (though some other detailed were still ironed out). It was discussed in
< wumpus> meetings multiple times.
< wumpus> does any of this feel rushed to you
< wumpus> I am still struggling to find out what I did wrong for even such a relatively straightforward proposal
< wumpus> I don't think people are exagerrating when they claim it has become almost imposible to make changes to bitcoin, even non-consensus, maybe this is a good thing! I don't know
< wumpus> but it's too frustrating for me personally and I don't think I'll be working on BIPs again
< wumpus> it wasn't even controversial in any way
< vasild> indeed, why was this brought up now? the btcd issue for disconnecting was opened in btcd's repo 20+ days ago
< wumpus> nor even a new idea! people had been talking about a new address mechanism for years before that, I mainly collected some ideas people already had
< wumpus> and wrote them down
< vasild> what about releasing 0.21 as is and _considering_ #20564 for 0.21.1 based on reception of 0.21?
< gribble> https://github.com/bitcoin/bitcoin/issues/20564 | Dont send sendaddrv2 to pre-70016 software by sipa · Pull Request #20564 · bitcoin/bitcoin · GitHub
< vasild> wumpus: ^
< wumpus> vasild: well, it being a temporary workaround it should probably be merged quickly
< wumpus> sipa's change is very low risk in itself
< vasild> I agree it is low risk and can be merged quickly, but I dont see it being temporary.
< wumpus> what people are (rightly) being worried about is the implications of this behavior
< wumpus> yes
< vasild> so we have team1 insisting that new messages should come with a protocol bump and impl1 should disconnect when it sees unknown message, team2 thinks it is ok to just ignore unknown messages.
< vasild> if team1 still insists and team2 follows suit, I don't see team1 changing their mind...
< wumpus> I don't agree at all that ignoring unknown messages is a DoS vector, if you want to DoS it's better to use a known message type that consumes resources
< vasild> right
< wumpus> or that has a large response for a small message
< wumpus> just flooding a host is uninteresting and possible in so many ways
< vasild> That is kind of obvious, but apparently not for everybody. My worry with 20564 is that it is going to reaffirm "new messages come with protocol bump"
< wumpus> and while I do agree the P2P code could use some more anti-DoS measures this is not one
< wumpus> right
< wumpus> vasild: maybe, though at least everyone in the PR agrees that it's a one time thing -- this says nothign about signaling to other implementations of course
< vasild> :)
< jonasschnelli> <wumpus> my first public draft was apparently june 1, 2018, I posted it to the mailing list feb 18, 2019 (there we no replies at all), I created the PR for the BIPs repository on feb 27, 2019, it was merged jul 23, 2019. Vasild picked up the implementation april this year, and quite quickly had a working implementation (though some other detailed were still ironed out). [...]
< jonasschnelli> This is my main concern... fixing this quietly.
< jonasschnelli> It might lead to more reluctant testing and lesser interest to read BIPs more carefully
< wumpus> ... even less interest and we might as well puglish BIPs directly into the arctic code vault
< wumpus> but I agree, the whole BIP process is there to standardize the bitcoin protocols, to coordinate between implementations, that's the point
< wumpus> well, it also helps coordinate between bitcoin core developers on a more conceptual level than implementation details, but that discussion happened on the BIP repo PRs, not on the mailing list
< wumpus> e.g. https://github.com/bitcoin/bips/pull/766 had some of the most fruitful discussion
< wumpus> maybe it should have been on the mailing list but I'm not sure most of the people commenting there are even subscribed there, not least because a lot of people consider mailing lists an awful communication medium
< wumpus> it's also perfectly normal to find and fix issues in rcs at the implementation level, what is weird here is that BIP-level conceptual issues are raised now
< harding> FWIW, addrv2 was covered by the Optech newsletter six times total, three times this year. https://bitcoinops.org/en/topics/addr-v2/ We also directly covered sdaftuar's March 2020 mailing list post about using new messages for feature negotiation with the call to action, "Daftuar is seeking feedback from maintainers of full nodes about whether the insertion of negotiation messages would cause any problems. If you’re aware of any
< harding> problems, please reply to the thread." http://bitcoinops.org/en/newsletters/2020/03/04/#improving-feature-negotiation-between-full-nodes-at-startup Later (August), about the new wtxidrelay message, we wrote, "This behavior is already implemented in an unreleased development version of Bitcoin Core. If the maintainers of other implementations, or anyone else, opposes this change, please respond to the mailing list thread."
< wumpus> harding: oh wow thanks for weighing in, I even forgot about that
< jonatack> Yes, it's not like we weren't publishing repeatedly about BIP 155 addrv2 arriving and testing, tweeting about it numerous times, people responding enthusiastically, etc.
< jonatack> also 2 review club sessions about it, one of which was covered with a monthly Optech feature writeup and quiz
< jonatack> I guess it's human nature to wait until things are really impending though
< jonatack> https://bitcoincore.reviews/19031 on 2020-07-15
< wumpus> it became a little more pressing with the Tor announcement that v2 was deprecated, but even then it was never hurried or rushed imo
< jonatack> https://bitcoincore.reviews/19845 on 2020-09-16 (the day after tor deprecated v2)
< jonatack> https://bitcoinops.org/en/topics/addr-v2 -> 3 posts in 2019, 3 posts in 2020 as harding wrote
< vasild> I opened https://github.com/btcsuite/btcd/pull/1671 to ignore unknown p2p messages in btcd
< jonatack> vasild: good idea
< wumpus> yes, good idea
< vasild> they can probably rewrite the patch in a better way technically, but the point is how it will be received
< wumpus> right
< vasild> btw, the freebsd port upgrade from 0.20.1 to 0.21.0rc2 was rejected by its maintainer, who does not want to track RCs: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251453
< jonasschnelli> I don't get this... configure.ac sets AC_SUBST(HAVE_WEAK_GETAUXVAL), this means it will not get evaluated in #if defined(HAVE_STRONG_GETAUXVAL) || defined(HAVE_WEAK_GETAUXVAL), right?
< jonasschnelli> (without setting CPPFLAGS to -DHAVE_WEAK_GETAUXVAL=@HAVE_WEAK_GETAUXVAL@)
< jonasschnelli> There is no AC_DEFINE for HAVE_WEAK_GETAUXVAL but randomenv.cpp is evaluating it. My guess is that getauxval will never be used in randomenv.cpp.
< sdaftuar> wumpus: just to share my opinion -- the issue in my mind is that this is a surprise to anyone that we implemented a feature that will cause existing software to disconnect us. i think it shouldn't have been a surprise to us, because every time this topic comes up on the mailing list, there is opposition to the idea of sending unknown messages without a protocol bump (as i rediscovered in august)
< sdaftuar> i know this BIP was advertised in several places, but the updated draft of it was never sent to the -dev list after the negotiation changed; so i think that's something that would have brought this to light to everyone sooner
< sdaftuar> at any rate, i'm not trying to advocate that we necessarily change our feature negotiation. i know lots of other people ahve strong views on it, and i don't myself
< sdaftuar> i just think that we should all be aware that this is an area where people disagree, and our communication should reflect that by making it clear what our software will do
< sdaftuar> (anyway, i also did basically zero work to help addrv2 make it this far, so thank you to everyone who has worked on it! i hope my words don't come across as criticism of the overall effort)
< wumpus> I didn't bother with them ailing list anymore because the first time it got exactly zero engagement
< sdaftuar> wumpus: yeah i have encountered that myself in the past too :(
< wumpus> I don't personally expecti t would have been different when sending it a second time but feel free to disagree
< wumpus> okay :/ yes I can only imagine how difficult it is to make say, consensus changes
< wumpus> if even seomthing like this...
< sdaftuar> my thought is that even if people don't engage, by sending it to the mailing list (which has historically been our place of publication of protocol changes) it shifts the burden to others to read, respond, or object
< MarcoFalke> it is impossible to know how much reading engagement a post has received if the majority of subscribers are readers
< MarcoFalke> s/if/because/
< wumpus> sure...
< wumpus> it was kind of demotivating for a while in itself though
< kanzure> what is the mechanism by which ignoring an unknown message causes a DoS problem?
< sdaftuar> the great question :)
< wumpus> disconnecting literally generates more traffic than ignoring the message
< kanzure> MarcoFalke: readers also can't be determined on a github pull request or issue comment.
< MarcoFalke> wumpus: I think it was an oversight of the btcd devs
< MarcoFalke> The first comment says "Thanks for reporting this! The easiest way to resolve this is to permit unknown messages rather than disconnecting as we do now"
< MarcoFalke> Maybe the btcd devs wouldn't have noticed even if the bip was sent to the mailing list
< MarcoFalke> it is easy to forget details of how the p2p protocol is implemented (or even how it changed in the past)
< MarcoFalke> code/bip review can never catch all issues upfront. They come up when implementing or running tests on real networks
< MarcoFalke> we are the first ones to implement the bip, so no one else had the chance to spot bugs while implementing
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/dca80ffb45fc...9601c0d7aab7
< bitcoin-git> bitcoin/master e373959 Block Mechanic: Android : Ensure pic build for bdb
< bitcoin-git> bitcoin/master 9601c0d fanquake: Merge #20565: Android : Ensure pic build for bdb
< bitcoin-git> [bitcoin] fanquake merged pull request #20565: Android : Ensure pic build for bdb (master...fix-bdb-android) https://github.com/bitcoin/bitcoin/pull/20565
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/9601c0d7aab7...c1604483d34f
< bitcoin-git> bitcoin/master fac7ab1 MarcoFalke: refactor: Use C++17 std::array where possible
< bitcoin-git> bitcoin/master c160448 MarcoFalke: Merge #20566: refactor: Use C++17 std::array where possible
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20566: refactor: Use C++17 std::array where possible (master...2012-array) https://github.com/bitcoin/bitcoin/pull/20566
< bitcoin-git> [bitcoin] MarcoFalke pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/c1604483d34f...751ffaabad82
< bitcoin-git> bitcoin/master 773c42b Andrew Chow: tests: Test that a fully signed tx given to signrawtx is unchanged
< bitcoin-git> bitcoin/master 751ffaa MarcoFalke: Merge #20562: tests: Test that a fully signed tx given to signrawtx is unc...
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20562: tests: Test that a fully signed tx given to signrawtx is unchanged (master...test-signraw-fullysigned) https://github.com/bitcoin/bitcoin/pull/20562
< Provostro> Hi I asked about LedgerX and they told me to come here and speak with Kanzure
< Provostro> I was checking it out, but it seems like a scam.
< Provostro> the order books are scammy
< Provostro> kanzure, are you running a scam?
< Provostro> !tlast
< gribble> 18856.24
< luke-jr> Provostro: this channel is for Bitcoin Core development, not for speaking with specific people about other topics
< Provostro> I'd like to settle matter amicably, thats why i came to you to ask.
< Provostro> TO please stop running your scam, or pay me 100 btc.
< luke-jr> Provostro: /query kanzure
< Provostro> luke-jr, ok i typed that, now what?
< luke-jr> use that tab to talk privately with him
< Provostro> i like to do it publicly so the whole world knows who's a scammer
< luke-jr> well it's not welcome here
< Provostro> do you hagve an issue with that?
< Provostro> luke-jr, perhaps you too are a scammer in on the scam?
< bitcoin-git> [bitcoin] MarcoFalke pushed 4 commits to 0.21: https://github.com/bitcoin/bitcoin/compare/68bd88597a79...aa4b8ebfecdd
< bitcoin-git> bitcoin/0.21 54e1edc Jon Atack: Allow zero-fee fundrawtxn and walletcreatefundedpsbt calls
< bitcoin-git> bitcoin/0.21 6e4969f Jon Atack: Update feeRate (BTC/kvB) to fee_rate (sat/vB) in wallet_bumpfee
< bitcoin-git> bitcoin/0.21 6313362 Jon Atack: Use the correct incremental fee constant in bumpfee help
< bitcoin-git> [bitcoin] MarcoFalke merged pull request #20510: [backport] wallet: allow zero-fee fundrawtransaction/walletcreatefundedpsbt and other fixes (0.21...backport-fee_rate-follow-ups) https://github.com/bitcoin/bitcoin/pull/20510
< andytoshi> i have another CI question .. if i do bash -c 'set -e; source ./ci/lint/06_script.sh ' locally it bombs out with
< andytoshi> test/functional/test_runner.py:42: error: Module has no attribute "getwindowsversion"
< andytoshi> presumably because i am not on windows
< andytoshi> is there a good way to deal with this
< sipa> ci/test_run_all.sh:set -o errexit; source ./ci/test/06_script_a.sh
< sipa> is that it?
< sipa> set -o errexit?
< sipa> oh, nvm, this is python
< andytoshi> yeah it's running the python linter
< andytoshi> the line i got is `set -o errexit; source ./ci/lint/06_script.sh` which is directly in .travis.yml
< MarcoFalke> andytoshi: You'll need to run the scripts in order, as they "pollute" the environment with variables
< MarcoFalke> s/in order/in the same bash/
< MarcoFalke> cp ./ci/test_run_all.sh ./ci/lint_run_all.sh && vim ./ci/lint_run_all.sh
< MarcoFalke> and then edit the file to run the same stuff that travis.yml runs
< andytoshi> i don't have apt and stuff
< andytoshi> i can't run the install scripts
< MarcoFalke> oh, the linters only run on ubuntu. I don't think they are tested on other operating systems
< andytoshi> as it happens, they pass on arch with very little modification
< andytoshi> just that it doesn't really check submodules (this is still a pass :)) and the one python issue which I'll try to PR to add a mypy whitelist to
< andytoshi> about sys.getwindowsversion not existing
< wumpus> i don't get it, sys.getwindowsversion doesn't exist on ubuntu either
< MarcoFalke> that part of the code is only executed when "os.name == 'nt'"
< wumpus> that makes sense
< andytoshi> yeah, it's just mypy that's complaining
< andytoshi> it's not an actual problem
< andytoshi> there are already mypy whitelists near that line related to windows stuff, i think this might've just been overlooked...but i'm surprissed that travis is ok with it
< jonatack> andytoshi: possibly fixed by #20240?
< gribble> https://github.com/bitcoin/bitcoin/issues/20240 | script: fix linter error in test runner by jonatack · Pull Request #20240 · bitcoin/bitcoin · GitHub
< andytoshi> jonatack: yeah i think so, though i don't really understand why your fix works
< jonatack> it fixes error: Module has no attribute "getwindowsversion" for me since several months
< andytoshi> what is mypy looking at that it thinks getwindowsversion is used by the original code, but not your new code?
< andytoshi> is it just smart enough to understand `sys.platform` check but not smart enough to understand the `os.name` check?
< jonatack> idk, i've been waiting for someone else to hit the same issue
< jonatack> but it works :shrugs:
< andytoshi> heh, well, here i am, and my solution was to just add a `# type: ignore` on the offending line
< sipa> using sys.platform is understood by mypy
< jonatack> andytoshi: yup, that works too: if os.name != 'nt' or sys.getwindowsversion() >= (10, 0, 14393): # type: ignore
< andytoshi> nice sipa
< andytoshi> so jonatack as i commented on your PR, there are a bunch of existing #type : ignore that you can probably drop
< andytoshi> though we'd need a windows tester to be sure
< jonatack> thanks sipa and andytoshi for the info. if no one looks at it before tomorrow i'll look into it.
< bitcoin-git> [bitcoin] OliverPetrovic opened pull request #20570: Logo added to the readme file. (master...master) https://github.com/bitcoin/bitcoin/pull/20570
< achow101> wallet meeting?
< achow101> #startmeeting
< core-meetingbot> Meeting started Fri Dec 4 19:01:29 2020 UTC. The chair is achow101. Information about MeetBot at https://bitcoin.jonasschnelli.ch/ircmeetings.
< core-meetingbot> Available commands: action commands idea info link nick
< emzy> hi
< fjahr> hi
< jonatack> hi
< achow101> #bitcoin-core-dev Wallet Meeting: wumpus sipa gmaxwell jonasschnelli morcos luke-jr sdaftuar jtimon cfields petertodd kanzure bluematt instagibbs phantomcircuit codeshark michagogo marcofalke paveljanik NicolasDorier jl2012 achow101 meshcollider jnewbery maaku fanquake promag provoostenator aj Chris_Stewart_5 dongcarl gwillen jamesob ken281221 ryanofsky gleb moneyball ariard digi_james amiti fjahr jeremyrubin emilengler jonatack hebasto
< achow101> jb55 kvaciral ariard digi_james amiti fjahr jeremyrubin lightlike emilengler jonatack hebasto jb55 elichai
< achow101> any topics?
< achow101> #topic wallet high priority for review
< core-meetingbot> topic: wallet high priority for review
< achow101> any wallet prs for high priority to add/remove/discuss?
< jonatack> pls review minor bugfix #20546
< gribble> https://github.com/bitcoin/bitcoin/issues/20546 | wallet: check for non-representable CFeeRates (0-0.0009 sat/vB) by jonatack · Pull Request #20546 · bitcoin/bitcoin · GitHub
< achow101> jonatack: is that for 0.21?
< jonatack> also found another bug in the send rpc; unlike the other rpcs, the fee rate cannot be passed as a string, only a number. Opening a fix today.
< jonatack> achow101: idk if it's a backport-worthy bug, up to others i guess
< provoostenator> (hi)
< provoostenator> It's marked experimental
< provoostenator> So I guess it depends on how annoyhing it is in practice
< jonatack> achow101: the fix in both cases is simple, the work is mostly writing good test coverage
< achow101> doesn't seem backport worthy, but no strong opinion on that
< jonatack> provoostenator: the help says it's an amount (string or number), and the fix is one line, but not up to me
< achow101> not the first time we've had a known issues section in the release notes
< kanzure> andytoshi: you can use import importlib; importlib.find_spec("somethingwindowsonly") and another function i forget.
< provoostenator> Well we probalby get another RC regardless because of a sendaddrv2 compatiblity issue with btcd
< jonatack> yess i'll just PR it and let ppl decide
< luke-jr> need another RC for the already merged stuff anyway
< jonatack> fjahr: i plan to review #19055 when i'm done with all the fee rate things
< gribble> https://github.com/bitcoin/bitcoin/issues/19055 | Add MuHash3072 implementation by fjahr · Pull Request #19055 · bitcoin/bitcoin · GitHub
< jonatack> as you've updated it
< fjahr> thanks
< provoostenator> I'm currently writing a PR for Specter to use descriptor wallets, so hopefully I don't encounter anything shocking on the core side.
< provoostenator> So far it works really well
< Murch> Hi
< provoostenator> It's annoying that getwalletinfo returns 3000 for keypool size
< achow101> it's not wrong though
< provoostenator> Although it's true,
< provoostenator> No, but it would be nice get 1000 somewhere as well
< provoostenator> Because I don't want to rely on having 3 types of addresses
< provoostenator> Need that number in order to pick a sane "range" param for importdescriptors
< provoostenator> Which doesn't have a default afaik
< achow101> just only support one address type then
< luke-jr> yeah, descriptor wallets don't need to have all the other types do they?
< provoostenator> That's not the issue. It's just that you can't know -keypoolsize
< provoostenator> Unless you parse bitcoin.conf
< achow101> since each spkm reports its own keypoolsize, getwalletinfo could be more granular there
< provoostenator> The range param for importdescriptors isn't super useful anyway
< achow101> just some output stuff, not particularly hard
< provoostenator> Would be nice if the range param defaulted to -keypoolsize so you can omit it.
< achow101> i think it does?
< achow101> anything else?
< achow101> #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 Fri Dec 4 19:23:24 2020 UTC.
< * luke-jr> peers at topic being in there
< jonatack> provoostenator: they should call it spectre like in the old bond films
< luke-jr> reminder that "Spectre" is a current-day series of vulnerabilities..
< achow101> depends on whether you're british or american
< fjahr> the latest one was also also called spectre and it wasn't that great sooo... :)
< provoostenator> achow101: ah you're right, range can be ommited.
< sipa> phantomcircuit or anyone else: you still have a large number of testnet coins?
< luke-jr> sipa: hi
< luke-jr> i herd u want TNBTC?
< luke-jr> how many & address?
< sipa> someone from bitgo is asking for some amount to test with
< sipa> ok, getting address
< phantomcircuit> sipa, i gave mine to matt
< phantomcircuit> either he gave them away or he's the testnet king
< sipa> ha
< gwillen> last christmas, I gave you my testnet coins, but the very next day, you gave them away
< luke-jr> hmm, testnet isn't letting me run it :x
< sipa> well, if anyone has some: 2N9KJZrryXJh26jqpX7cxHM7facYcSZrEFp
< achow101> sipa: how many?
< luke-jr> gwillen: are you implying bluematt isn't special?
< sipa> achow101: how many you have? :)
< achow101> several thousand
< gwillen> luke-jr: I would never
< sipa> gwillen: ok, you get a pass, it's december alright
< achow101> sipa: 6eb56f123eb1753fe6d74f5ce177c51eb99687afb34d70f72f598a1c85835bec
< sipa> achow101: thanks!
< gwillen> sipa: christmas music is allowed at any point after American Thanksgiving, I didn't make the rules
< sipa> gwillen: and i haven't heard any christmas songs yet this year for some reason
< luke-jr> gwillen: that's not the rules
< luke-jr> gwillen: Christmas music may begin on Christmas Day
< gwillen> you've failed to account for the effects of Christmas Creep, at this point you're lucky if it doesn't start right after Halloween
< achow101> luke-jr: begin or only on?
< luke-jr> achow101: well, Christmas is 40 days so
< luke-jr> Dec 25-Feb 2
< gwillen> actually I'm surprised you wouldn't allow for Christmas music starting during Advent
< luke-jr> Advent is supposed to be penetential
< gwillen> exactly, that's when the suffering should begin
< luke-jr> lol
< bitcoin-git> [bitcoin] hebasto opened pull request #20571: refactor: Use deduction guide for std::array<uint8_t, N> (master...201204-u8) https://github.com/bitcoin/bitcoin/pull/20571
< bitcoin-git> [bitcoin] hebasto opened pull request #20572: ci: Adjust Cirrus CI task names (follow up) (master...201204-cirrus) https://github.com/bitcoin/bitcoin/pull/20572
< bitcoin-git> [bitcoin] jonatack opened pull request #20573: wallet, bugfix: allow send with string fee_rate amounts (master...send-allow-feerates-as-strings) https://github.com/bitcoin/bitcoin/pull/20573