< bitcoin-git>
[bitcoin] troygiorshev opened pull request #20411: Fix Version Message Deserialization Discrepancy (master...2020-11-test-framework-version-msg-fix) https://github.com/bitcoin/bitcoin/pull/20411
< luke-jr>
feature_taproot is failing 100% of the time for me on master - anyone else?
< luke-jr>
line 1454 test_framework.authproxy.JSONRPCException: 'signrawtransactionwithwallet' RPC took longer than 30.000000 seconds. Consider using larger timeout for calls that take longer to return. (-344)
< aj>
luke-jr: finishes successfully in 3minutes total here
< aj>
jnewbery: thinking about it slightly more, calling Init() with parts of Options filled out with fuzzed data might be easy and better than the current test
< jnewbery>
aj: I don't think fuzz testers should be able to change internal state without using public interface methods. If the only use of that method is the fuzz tester, then it can be removed.
< jnewbery>
I don't like the way that Init() is called internally in the ctor and start. It obscures how members are initialized
< jnewbery>
I agree that the fuzzer should construct CConnmans with different connOptions
< aj>
jnewbery: yeah, on third thoughts i don't think the fuzz tester currently exercises any code that's dependent on those values anyway
< aj>
jnewbery: CConnman having an `Options m_options;` variable instead of all the different ones might simplify things
< jnewbery>
aj: I think eventually the ctor should be passed a connOptions object and all of the member initialization be done in the ctor. That requires moving a lot of code around in init.cpp
< jnewbery>
but it makes the construction of CConnman a lot clearer, and would make constructing CConnmans in the production code and test code follow the same code paths
< bitcoin-git>
bitcoin/master d020e88 MarcoFalke: Merge #20418: doc: clean out release notes post branch-off
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20418: doc: clean out release notes post branch-off (master...clean_out_rel_notes) https://github.com/bitcoin/bitcoin/pull/20418
< bitcoin-git>
[bitcoin] fanquake closed pull request #11082: Add new bitcoin_rw.conf file that is used for settings modified by this software itself (master...rwconf) https://github.com/bitcoin/bitcoin/pull/11082
< bitcoin-git>
[bitcoin] fanquake opened pull request #20419: build: set minimum supported macOS to 10.14 (master...macos_minimum_10_14) https://github.com/bitcoin/bitcoin/pull/20419
< provoostenator>
If you have a Mac and want to waste an enormous amount of time, upgrade to Big Sure, delete Python and try to reinstall it via PyEnv
< wumpus>
i could try this on my ex-gfs mac and have some fun :')
< luke-jr>
aj: sipa: that works… so this is just the wallet being stupid slow when big?
< achow101>
yay branching
< luke-jr>
* [new tag] branch-0.21 -> branch-0.21
< hebasto>
wondering how long it could take for Tor connected 0.21 nodes to propagate their new v3 onion addresses (without -addnode)?
< jnewbery>
achow101: is btcinformation.org still maintained?
< achow101>
jnewbery: not currently
< bitcoin-git>
[bitcoin] achow101 opened pull request #20420: wallet: Don't upgrade to HD split if it is already supported (master...upgradewallet-fix-split) https://github.com/bitcoin/bitcoin/pull/20420
< luke-jr>
MarcoFalke: afaik we have no data on what OSs are used for nodes?
< MarcoFalke>
Ubuntu's snap is basically spyware
< luke-jr>
:o
< MarcoFalke>
So at least for Ubuntu OSs we can get the distribution quite well
< luke-jr>
MarcoFalke: but snap users are also getting the gitian binary anyway, so not the target supported for building :P
< MarcoFalke>
Absent any other information, I assume that the snap users distribution is identical to the self-building distribution
< achow101>
we don't have download numbers for bitcoincore.org?
< luke-jr>
that seems unlikely, but I don't really mind supporting older Ubuntu at this point anyway
< MarcoFalke>
achow101: What happend with your survey thingy?
< sipa>
i think macOS users are in general more upgrade-happy than other OS'es
< achow101>
MarcoFalke: it's happening soon(tm)
< MarcoFalke>
Upgrade preference about OS/Core would be a good q to ask
< sipa>
(but that's just a general impression i have)
< achow101>
still working on it
< luke-jr>
sipa: otoh, there's like 5 years of hardware that casn't upgrade IIRC
< luke-jr>
2009-2015
< sipa>
macos 10.13 will be unsupported next month
< luke-jr>
sipa: good to know
< promag>
anyone recommends ODROID-HC4 or ODROID-C4? or other?
< hebasto>
using odroid-hc1 with armbian
< hebasto>
choose good sd-card, it is important
< promag>
do you use as full node?
< hebasto>
yes
< promag>
what disk?
< hebasto>
hdd from old laptop :)
< promag>
ah :)
< hebasto>
from my experience armbian is better than stock ubuntu
< promag>
you use as headless right?
< hebasto>
yes
< achow101>
jonatack: I've just realized that #20403 is already marked for backport. Do you want to just pull in the fix in #20420 into that?
< jonasschnelli>
promag: I used HC2 and XU4. The HC4 looks nice. Im still a big fan of the Rock64pro. Has an mSATA slot.
< jonatack>
achow101: either way sgtm. i'll test tomorrow am first thing
< jonatack>
achow101: happy to pull it in
< achow101>
jonatack: in that case, I'll close my pr so we don't have more conflicts
< jonatack>
achow101: okey dokey, thanks for looking into it
< bitcoin-git>
[bitcoin] achow101 closed pull request #20420: wallet: Don't upgrade to HD split if it is already supported (master...upgradewallet-fix-split) https://github.com/bitcoin/bitcoin/pull/20420
< luke-jr>
ugh, why is NetPermissionFlags out of order
< luke-jr>
why does accessing m_blockman require cs_main?