< bitcoin-git>
[bitcoin] sh-abhi opened pull request #20678: Add on autoconf as a dependency when building on macOS (master...autoconf-dependency) https://github.com/bitcoin/bitcoin/pull/20678
< jeremyrubin>
sipa: andytoshi: I think it was just something about having templates declared in the header, and defined in the .cpp and not explicitly specialized was making this specific clang unhappy. Other versions seem to resolve it ok... so not sure what's up w/ that.
< bitcoin-git>
[bitcoin] fanquake closed pull request #20504: build: use more legible (q)make commands in qt package (master...legible_qt_config_cmds) https://github.com/bitcoin/bitcoin/pull/20504
< fanquake>
It's strange how people fight against dropping support for versions of macOS (at the potential detriment of the rest of the project), while at the same time seemingly have no issue with dropping support for versions of operating systems that are almost certainly used by more Bitcoin Core users, and/or are supported for far longer into the future.
< gwillen>
I assume people mostly fight in favor of supporting OSes they use themselves
< gwillen>
I don't know how far back with go with macOS, but e.g. I'm on 10.14.6, so if that got dropped I basically couldn't use or work on the project anymore
< sipa>
fanquake: which one are people discussing dropping?
< sipa>
fanquake: i thought it was just a suggested or build dependency
< sipa>
if it breaks window 8 / ubuntu 18.04 that seems like a no go
< sipa>
could we use qt6 for osx, and qt5 for the rest?
< sipa>
*macos
< gwillen>
it seems that dongcarl doesn't think it would break those platforms, judging from his comment -- it seems like there is some question as to what exactly Qt6 claims to support / actually supports
< fanquake>
sipa: as far as I know those are runtime requirements
< sipa>
well we'd need to know
< fanquake>
Me and Carl also discussed in the builds channel this morning
< sipa>
if it's easy for source to be compatible with both it may make sense to use qt6 on macos depends builds, and qt5 for others
< luke-jr>
well we need to support building with Qt5 anyway
< luke-jr>
it'll be a while before distros deploy Qt6
< jonasschnelli>
sipa: ChaCha20::Crypt is the same if I do ChaCha20::Keystream and then manually xor the message with the keystream? I somehow are confused about x0 ^= ReadLE32(m + 0); (since this writes back to the state?)
< jonasschnelli>
I debugged it and it is indeed the same just the x0 ^= confuses me
< sipa>
yes
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20680: ci: Only use credits for pull requests to the main repo (master...2012-ciCredits) https://github.com/bitcoin/bitcoin/pull/20680
< bitcoin-git>
bitcoin/master facf5e3 MarcoFalke: ci: Only use credits for pull requests to the main repo
< bitcoin-git>
bitcoin/master 83abd6b MarcoFalke: Merge #20680: ci: Only use credits for pull requests to the main repo
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20680: ci: Only use credits for pull requests to the main repo (master...2012-ciCredits) https://github.com/bitcoin/bitcoin/pull/20680
< bitcoin-git>
[gui] MarcoFalke merged pull request #153: Define MAX_DIGITS_BTC for magic number in BitcoinUnits::format (master...const_max_digits) https://github.com/bitcoin-core/gui/pull/153
< bitcoin-git>
bitcoin/master 198fff8 Luke Dashjr: GUI: Define MAX_DIGITS_BTC for magic number in BitcoinUnits::format
< bitcoin-git>
bitcoin/master d0e76b5 MarcoFalke: Merge bitcoin-core/gui#153: Define MAX_DIGITS_BTC for magic number in Bitc...
< wumpus>
MarcoFalke: i think we should leave it for 0.21.1
< wumpus>
MarcoFalke: focus on what is really critical for 0.21.0 and just get it out of the door
< wumpus>
if it's a regression it needs to be fixed in a rc, otherwise let's make it wait for 0.21.1
< wumpus>
regarding Qt5 and Qt6 i think we should aim to be compatible with both in the forseeable future
< hebasto>
as Qt4 and Qt5 were?
< wumpus>
the transition period for Qt4/Qt5 was pretty long as well and I don't expect it to be different this time. I don't know how difficult this is in practice though.
< wumpus>
correct!
< wumpus>
please, if you write md documents (especially install instructions) keep them readable in the terminal; preferably don't use HTML, "Dependency Options" in depends/README.md is hard to read when viewing it in "less" or "vim"
< bitcoin-git>
[bitcoin] laanwj opened pull request #20681: doc: Convert depends options list from html to markdown (master...2020_12_dependdoc) https://github.com/bitcoin/bitcoin/pull/20681
< bitcoin-git>
bitcoin/master 010eed3 Adam Jonas: doc: warn that incoming conns are unlikely when not using default ports
< bitcoin-git>
bitcoin/master cfbfd38 Wladimir J. van der Laan: Merge #20668: doc: warn that incoming conns are unlikely when not using de...
< bitcoin-git>
[bitcoin] laanwj merged pull request #20668: doc: warn that incoming conns are unlikely when not using default ports (master...121520-non-standard-port-doc) https://github.com/bitcoin/bitcoin/pull/20668
< wumpus>
my policy allows mapping high ports 1024-65535, denies the rest, but this should be enough for bitcoin
< wumpus>
Turris Omnia
< wumpus>
openWRT-ish
< hebasto>
what in openwrt log?
< wumpus>
I don't see anything related in the log, will try if I can enable verbose logging somehow
< wumpus>
OOHH never mind I think I have it
< hebasto>
natpmp connection?
< jonasschnelli>
Review bag for https://github.com/bitcoin/bitcoin/pull/20273 (concept ACK/NACK). Helps me to decide if I should drag that PR along. I really like the functionality of nested commands in CLI.
< wumpus>
unfortunately still not, but found one setting that was blocking it from working
< bitcoin-git>
[gui] goums opened pull request #154: qt: Colorize icons on macOS for Dark mode support (master...macos_color_icons) https://github.com/bitcoin-core/gui/pull/154
< wumpus>
in any case it's probably not a problem with your code; i don't see anything upnp related in the log, for some reason it doesn't seem to be launching
< dhruvm>
I am trying to run a full node with everything else blocked using iptables: https://pastebin.com/rre3eQQR With that setup, bitcoind is not able to establish any peers (10k+ in peers.dat). What am I missing?
< wumpus>
vasild: is that my calender? will take a look
< vasild>
wumpus: I don't know, it is linked from here: https://bitcoincore.org/en/meetings/ "Meeting times are also listed on this Google calendar"
< wumpus>
vasild: i've deleted it
< vasild>
Thanks!
< wumpus>
there's still a bitcoin core wallet meeting on jan 1, probably also not going to be?
< bitcoin-git>
bitcoin/master 7b6887e Wladimir J. van der Laan: doc: Convert depends options list from html to markdown
< bitcoin-git>
bitcoin/master 190d3d8 Wladimir J. van der Laan: Merge #20681: doc: Convert depends options list from html to markdown
< bitcoin-git>
[bitcoin] laanwj merged pull request #20681: doc: Convert depends options list from html to markdown (master...2020_12_dependdoc) https://github.com/bitcoin/bitcoin/pull/20681
< bitcoin-git>
[bitcoin] mjdietzx opened pull request #20688: test: run mempool_compatibility.py even with wallet disabled (master...mempool-compatibility-to-miniwallet) https://github.com/bitcoin/bitcoin/pull/20688
< wumpus>
there's no discussion there by any actual contributors to the project
< sdaftuar>
it seems it had many concept acks early on (2 years ago)
< fjahr>
it has a lot of interest from the wider community
< jonatack>
iirc it's desired by the community but unsustainable long-term (haven't looked in a long time but we did a review club on it)
< wumpus>
I still think an address index over the entire block chain is bad idea and becomes a worse idea the more the thing grows, software that relies on that is broken
< sdaftuar>
i thought it was just an index on the utxo set. it's indexing the whole blockchain?
< sipa>
yes
< sdaftuar>
ohh i see
< wumpus>
it's the whole block chain I think? utxo index would make more sense to me
< fjahr>
If people are against it, they should NACK it
< jonasschnelli>
the eralier attemps where just for the utxo set, right?
< wumpus>
fjahr: I have nacked similar things for years, if people keep digigng it up I lose the energy for that
< jonasschnelli>
a complete index seems out of scope IMO
< wumpus>
yes, there have been attemps for indexes over only the UTXO set, but they didn't make it in either for some reason (dunno why, maybe the author just gave up)
< sipa>
it's a difficult question... (IMO) people shouldn't be building infrastructure that relies on having such an index, but if they're going to do it anyway, it's perhaps not any worse to have in bitcoin core
< MarcoFalke>
It is no worse than -txindex
< sipa>
txindex is terrible too
< sipa>
but we can't just drop it
< wumpus>
yes, it's just as worse as txindex
< fjahr>
wumpus: understandable, maybe there should be some kind of "permanent concept NACK" if enough people agree so nobody puts effort into putting into core anymore, maybe there is a way there for a project that works closely with core
< aj>
isn't that just a good reason for both addrindex and txindex to be optional and default off?
< wumpus>
fjahr: I mean I have no interest in blocking something if people really want it, but I'm not going to be part of it
< wumpus>
fjahr: and apparently a lot of contributors think like that
< jonasschnelli>
#20664 is something that allows (very) slow address scanning at a fraction of disk space
< wumpus>
well then people could make a bitcoin core + electrs bundle, for example
< wumpus>
there's lots of systems like docker that allow shipping multiple software that works together in one box
< sipa>
my primary objection is "nobody should be using this"
< wumpus>
MarcoFalke: that's literally a separate repository though :)
< sipa>
but if people are going to use this anyway, and it can be added without being too invasive, and being optional... from a code maintenance perspective i don't have that much problems with it
< jonasschnelli>
I guess there are reasons to use it,... if your backend servers hundreds of wallets and if you want instance seed-backup restores
< MarcoFalke>
It is still a repo in our org ;)
< jonasschnelli>
*instant
< wumpus>
MarcoFalke: I don't have a problem with it being in the org
< jonasschnelli>
Yes.
< wumpus>
just not everything needs to be part of the bitcoin core repostiory
< jonasschnelli>
The address index could be outside our repo and I think it would be fine
< jonasschnelli>
Maybe similar like the guy... but ideally process separated from the beginning.
< jonasschnelli>
*GUI
< wumpus>
let's fork electrs into bitcoin-core then :)
< jonasschnelli>
:/
< aj>
txindex is slightly helpful for speeding up our own RPCs (getrawtransaction), i don't think there's a similar rationale for needing an integrated addrindex?
< sipa>
getrawtransactionsbyaddress, an RPC that very unhelpfully always reports the "RPC does not exist" error right now
< MarcoFalke>
how does txindex speed things up?
< jonasschnelli>
why is an index for the utxo set not enoght?
< jonasschnelli>
If you want the spent history, use blockfilters
< sipa>
i commented
< bitcoin-git>
[bitcoin] sdaftuar opened pull request #20690: Clean up logging of outbound connection type (master...2020-12-clean-up-outbound-logging) https://github.com/bitcoin/bitcoin/pull/20690
< aj>
MarcoFalke: compared to looping over every historical block and checking blockfilters, it's O(log(txs)) vs O(blocks)
< wumpus>
it will just be the same discussion again that's been done many times over the years i expect
< jamesob>
jonatack: thanks!
< jamesob>
I have some feedback from wumpus to address I think
< fjahr>
jonasschnelli: I think such a combo is worth exploring
< jonasschnelli>
fjahr: look at #20664 (for performance analysis)
< wumpus>
I saw there are two parellel workarounds for the rc3 macos signing issue
< sipa>
so we have two possible (temporary?) fixes for macos codesigning, #20638 and #20644
< gribble>
https://github.com/bitcoin/bitcoin/issues/20638 | build: Fix macOS code signing by pre-allocating space for the code signature during gitian build by achow101 · Pull Request #20638 · bitcoin/bitcoin · GitHub
< sipa>
and if achow101's python codesigner works, all of this will be obsolete
< sipa>
s/if/when/ - no pressure
< jonasschnelli>
heh
< wumpus>
but that's more of a long-run solution
< achow101>
it's coming along slowly
< jonasschnelli>
achow101: no pressure,.. but will it be ready for an rc4? :)
< achow101>
I might have a PoC tomorrow
< jonasschnelli>
Maybe for 0.21 we should use the existing solutions and use 0.22 (+backport) for achow101 signing tool
< wumpus>
I don't think it's a good idea to introduce something like that between rcs
< sipa>
yeah, not really relevant in this discussion; we can just pick one; my PR makes our codesign compatible with Apple's (to the extent that we know, but it can always change); achow's works around the issue (by predicting some things the Apple code will do)
< sipa>
jonasschnelli: seems reasonable
< wumpus>
unless there is no other workable option, of course
< jonasschnelli>
sipa's PR is an easier fix and maybe less risky?
< jonasschnelli>
(if we going to drop it anyways)
< achow101>
I think sipa's PR potentially has other side effects that we haven't discovered
< sipa>
well, the signature validates
< achow101>
since it modifies cctools and we use more than just codesign_allocate in it
< jonasschnelli>
sipa: it only needs to work for rc4 and final release
< sipa>
hmm, do we?
< jonasschnelli>
(oh... and maybe for 0.20.2)
< sipa>
what else from cctools do we use?
< achow101>
pagestuff, but it doesn't seem to be effected
< dongcarl>
I believe we use it as our binutils
< dongcarl>
For macOS targets
< sipa>
the changed function only affects codesign_allocate, lipo, bitcode_strip, and segedit
< achow101>
I thought we used some of the tools for building but I'm not sure
< sipa>
anyway, no strong feelings
< dongcarl>
I don't think we use any of the other ones sipa just listed, need to double check tho
< sipa>
and no point spending much time on this
< achow101>
well, at least during testing we didn't find any other problems, so it's probably fine
< wumpus>
ok
< jonasschnelli>
I propose to merge #20644 and do rc4 and 0.20.2rc1. Then wait for achow101 signing tool to have a stable long term fix
< sipa>
as pointed out, it makes little sense if it doesn't go in 0.21
< wumpus>
sipa: I don't think people even agree about doing it
< sipa>
yeah
< aj>
it has three acks and a +/- 0?
< wumpus>
my ACK is more of a 'I don't disagree with doing this and the code change looks correct'
< luke-jr>
.
< MarcoFalke>
...
< aj>
i don't think i have anything to add that's not already in the pr
< wumpus>
same
< MarcoFalke>
someone should flip a coin
< wumpus>
if we're not sure it's better to err on the side of not making a code change
< aj>
Jackielove4u spend 2h the other night debugging test failures because of it, likewise it broke syncing signet, i don't really see why this is a coin toss
< wumpus>
especially if it's a merge-and-rush-into-rc4-last-minute thing
< sipa>
aj: ah, other report of someone hit by it?
< aj>
sipa: had bitcoin-qt and bitcoind refusing to connect, didn't realise bitcoin-qt was still rc2
< jonatack>
i'm ambivalent, but it seems safer to ignore instead of disconnect if we're in doubt. the signet thing, and also a year ago we had to pull a release
< jonatack>
and anything else we haven't hit related to it
< wumpus>
0.21.0 has had many of those 'we need to decide this last minute' and it doesn't make me comfortable
< MarcoFalke>
The signet sync is already fixed, so merging the pull won't change that
< jonatack>
wumpus: i empathize
< aj>
wumpus: there were a lot of big merges just before freeze
< wumpus>
MarcoFalke: great!
< luke-jr>
maybe we need more time between freeze and rc1? (though I dislike the duration)
< luke-jr>
perhaps branch at freeze and tag rc1 weeks afterward?
< wumpus>
that's just more backporting work
< MarcoFalke>
luke-jr: That'd mean too much work backporting
< jonasschnelli>
luke-jr: most stuff appears in rcs.. :/
< MarcoFalke>
Also, most rc issues are build system issues
< wumpus>
jonasschnelli: bugs appearing and fixed in rcs is completely normal and expected, what bothers me is these kind of last minute protocol handling changes
< MarcoFalke>
So you won't find them before the tag
< jonasschnelli>
wumpus: indeed.
< jonasschnelli>
Although, ignoring them is also no option
< wumpus>
jonasschnelli: well if MarcoFalke says the signet sync issue is fixed
< jonasschnelli>
MarcoFalke: good point
< sipa>
well it's fixed for people who update
< sipa>
no?
< sipa>
that was already the case
< aj>
the original issue was people running rc3 couldn't sync from the non-tor seed node
< MarcoFalke>
sipa: The seed node was on rc2, so a user updating to rc3 *broke* it
< sipa>
ah i see
< sipa>
ok, fair point
< MarcoFalke>
*pre-rc2 (not sure if it was actually rc2)
< aj>
that node is now updated, so now anyone running rc2 and earlier can't sync from it instead
< MarcoFalke>
aj: Correct
< aj>
i think the seed node was a previous version of #19937
< sipa>
so it's not really signet-specific anymore... the question is just whether gratuitous disconnection of existing old nodes is worth slightly better observability of people implementing the protocol incorrectly
< MarcoFalke>
aj: Though, that seems like a feature (telling people to upgrade from non-supported versions)
< aj>
MarcoFalke: telling people to upgrade sure, but this is just "it fails for no apparent reason"
< wumpus>
there isn't any released node that will be disconnected right?
< sipa>
wumpus: correct
< wumpus>
I mean if you implement the ignoring someone might spent hours debugging why addrv2 doesn't work
< sipa>
it was affecting signet disproportionally because of course all signet nodes were running pre-release code
< wumpus>
sometimes I wish we still had the reject message
< MarcoFalke>
the reject message was replaced by -debug=net
< wumpus>
it could send an error to the peer before disconnecting, or in general when not accepting it
< sipa>
wumpus: maybe, but if they're trying to make it work is "why am i getting addr and not addrv2?" really that different from "why am i being disconnected?"
< aj>
it would have been nice if there was this much resistance to #20564 :-/
< sipa>
aj: later and later in the process, more and more resistance...
< wumpus>
aj: that was also a reluctant ACK for me
< luke-jr>
aj: test != mainnet
< wumpus>
but that was about mainnet software, and actual releases of alternative clients
< aj>
sipa: pretty easy to have a BCLog::NET debug message of either "Ignoring SENDADDRV2 received after VERACK" or "SENDADDRV2 received after VERACK; disconnecting" -- we have neither of those atm, also for WTXIRELAY
< sipa>
aj: yeah, that would be a good idea
< wumpus>
yes, would make sense to add that
< aj>
i have a patch to add it, but was waiting for the sendaddrv2 to get fixed (or, i guess, nacked)
< wumpus>
it's time to end the meeting
< jonatack>
disconnection was added pretty late in the 20564 review process
< aj>
luke-jr: i guess i don't really agree. the whole point of a test net is to catch breakage first; if you catch breakage on the testnet and then go "oh, it's just broken on the testnet, it'll be fine on mainnet" that kind of defeats the purpose imo
< jonatack>
(i didn't disagree with it, just observing)
< luke-jr>
aj: not when the breakage is triaged to not affect mainnet
< aj>
luke-jr: Jackiewhatever's problems were on mainnet, aiui
< sipa>
it affects mainnet in exactly the same way, just proportionally less badly
< wumpus>
i honestly don't know either but changing the behavior from disconnect to ignore for a temporary signet issue which is already fixed just feels redundant to me, I agree with jnewbery there
< wumpus>
it's not even a temporary workaround
< MarcoFalke>
jup, this would be permanent
< MarcoFalke>
[20:55] <sipa> so it's not really signet-specific anymore... the question is just whether gratuitous disconnection of existing old nodes is worth slightly better observability of people implementing the protocol incorrectly
< jonatack>
wumpus: right, it's not about fixing signet, nor temporary
< aj>
why would it be permanent?
< aj>
if disconnecting now is okay, ignoring now and disconnecting in the future is also okay
< wumpus>
so in the long term observability of implementing the protocol incorrectly is probably the more important concern
< bitcoin-git>
[bitcoin] hebasto opened pull request #20691: ci, doc: Travis CI features and mentions cleanup (master...201217-travis) https://github.com/bitcoin/bitcoin/pull/20691
< aj>
wumpus: logging that you're ignoring the message because it's out of order seems to capture that?
< jonatack>
aj: yes, i like that
< wumpus>
aj: yes, though less clearly, the peer being disconnected would prompt an investigation immediately
< wumpus>
I agree it needs to be logged whether disconnecting or not
< aj>
wumpus: i'm not sure that's true; there's plenty of old nodes on mainnet that the peer would connect to; if you're paying enough attention to realise you're not connected to any 0.21 nodes, you're probably also paying enough attention to realise you're not getting any addrv2 info
< wumpus>
there's also the consistency argument, why would wtxid disconnect you but not sendaddrv2
< wumpus>
the main reason that I was in favor of changing sendaddrv2 to be sent between version and verack in the first place is because it could be handled the same as other messages
< aj>
wumpus: because wtxid's spec didn't change the way sendaddrv2 did
< wumpus>
bitcoin core is clearly the only client implementing sendaddrv2
< aj>
wumpus: wtxid gets to do it because there was no cost and a slight benefit; sendaddrv2 has a slight cost so shouldn't
< wumpus>
for now at least
< sipa>
there is another difference: ignoring a sendaddrv2 doesn't violate the BIP; ignoring a wtxidrelay does
< aj>
wumpus: though i'd much rather wtxid not do it either if the alternative is "it's okay to break our own software if it didn't make it into a release"
< wumpus>
so there was no reason changing the spec was problematic, if it was, then we wouldn't haev done the last minute change in the first place, and heck may be that would have been better, I'm so tired ofthis
< wumpus>
sendaddrv2 was only (in the old version) in the master and a pre-release for a short time, if that means we need to support that implemenation forever that would be kind of bad
< aj>
the PR already isn't supporting it, it's just not disconnecting it either
< MarcoFalke>
aj: If it is not permanent, how would you decide when to revert it back to disconnect?
< aj>
you could add an `if (GetTime() > 1623961389) fDisconnect = true;` now if you wanted, or add it back later. but the benefit of disconnecting versus just putting a log message seems super trivial
< Jackielove4u>
aj: 21:03:56 <aj> luke-jr: Jackiewhatever's problems were on mainnet, aiui
< Jackielove4u>
my problems were on mainnet AND testnet
< Jackielove4u>
however we can drop that PR
< luke-jr>
we ignore other invalid messages, I'm not sure why it's preferable to disconnect this one
< aj>
MarcoFalke: i'd guess when 0.21.1 is out and there are almost no 0.20.99 and perhaps 21.99 nodes on the network for objective measures; 6-12 months after the last unreleased code that used it for hand-wavey
< Jackielove4u>
wumpus: 20:56:20 <wumpus> there isn't any released node that will be disconnected right?
< Jackielove4u>
this is correct
< aj>
MarcoFalke: if it was timebased you could make that decision today by sticking the GetTime() comparison in, but i don't see any reason why you'd need to make that decision now
< wumpus>
jonasschnelli: it looks like you added #15946 to high prio for review but didn't move it to any column, I guess it should be in "blockers"?
< aj>
jonatack: afaik, they have irc and access to github in siberia
< wumpus>
heh i feel the same way often
< jonatack>
heh, teheran then
< sipa>
joking aside, going on vacation to places without decent internet access has helped me relax...
< hebasto>
some places in Siberia were science centers...
< jonatack>
hebasto: i spent a winter in (near) siberia actually, the former prisoners were the intelligentsia of the day
< sipa>
jonatack: cool (literally and figuratively)
< jonatack>
was in the area between perm, magnitogorsk, yekaterinburg & irkutsk
< hebasto>
it's quite a big region
< jonatack>
yes
< jonatack>
(if we add aj's logging, 20646 isn't the last PR)
< sipa>
jonatack: i know some of those names from the boardgame "risk"!
< jonatack>
sipa: maybe next coredev?
< hebasto>
hehe
< sipa>
jonatack: ehm... perm <-> irkutsk is 3000 km
< sipa>
do i have that right?
< hebasto>
sipa: correct
< jonatack>
right, perm isn't siberia yet...yeah it's big, flying between the cities the tupolevs took off and landed in a foot of snow, the pilots flew wearing only socks, shoes off in the cockpit
< wumpus>
jonatack: fine with including that but in contrast to 20644, logging isn't urgent to get into a rc
< wumpus>
20646
< aj>
logging's useful for master, not rc
< sipa>
yeah, someone testing protocol support against bitcoin core will likely use master anyway
< sipa>
or the latest release at least; not random old nodes on the network
< bitcoin-git>
[bitcoin] mjdietzx opened pull request #20692: test: run mempool_resurrect.py even with wallet disabled (master...mempool-resurrect-to-miniwallet) https://github.com/bitcoin/bitcoin/pull/20692
< jonatack>
makes sense
< bitcoin-git>
[bitcoin] glowang closed pull request #19297: [test] WIP: rewrite generate() in test_node to gain determinism in test data (master...2020/05/21/rewrite_generate_in_testnode) https://github.com/bitcoin/bitcoin/pull/19297