< bitcoin-git>
bitcoin/master fac4e13 MarcoFalke: refactor: Change pointer to reference because it can not be null
< bitcoin-git>
bitcoin/master fa69c2c MarcoFalke: wallet: Do not treat default constructed types as None-type
< bitcoin-git>
bitcoin/master ca4a784 MarcoFalke: Merge #20410: wallet: Do not treat default constructed types as None-type
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20410: wallet: Do not treat default constructed types as None-type (master...2011-rpcWalletNoneType) https://github.com/bitcoin/bitcoin/pull/20410
< bitcoin-git>
[bitcoin] MarcoFalke opened pull request #20485: [backport] wallet: Do not treat default constructed types as None-type (0.21...2011-rpcWalletNoneType) https://github.com/bitcoin/bitcoin/pull/20485
< wumpus>
remove non-determinism in one place and ...
< wumpus>
the issue is the 'sed -i "s/\\\-${BTCVER[1]}//g" ${MANDIR}/${cmdname}.1', ${BTCVER[1]} evaluates to an empty string
< wumpus>
what triggered this is that I ran it after tagging, there is still some weirdness in the version script with tags, generating a different kind of version spec
< wumpus>
how easy commands like sed turn into run-away gremlins gives me shivers but at least this shouldn't normally happen
< bitcoin-git>
bitcoin/0.21 fac4e13 MarcoFalke: refactor: Change pointer to reference because it can not be null
< bitcoin-git>
bitcoin/0.21 fa69c2c MarcoFalke: wallet: Do not treat default constructed types as None-type
< bitcoin-git>
bitcoin/0.21 d47d160 MarcoFalke: Merge #20485: [backport] wallet: Do not treat default constructed types as...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20485: [backport] wallet: Do not treat default constructed types as None-type (0.21...2011-rpcWalletNoneType) https://github.com/bitcoin/bitcoin/pull/20485
< bitcoin-git>
[bitcoin] sipsorcery opened pull request #20489: CI msvc: only build vcpkg dependencies for release (not debug) to reduce build times (master...msvc_vcpkg_relonly) https://github.com/bitcoin/bitcoin/pull/20489
< gleb>
jnewbery: Thanks for catching what seems to be a mistake in asmap supplying implementation! We should make a fix, a couple more eyes would be useful as well, just to confirm our understanding.
< bitcoin-git>
bitcoin/master e3e7446 Cory Fields: Add lifetimebound to attributes for general-purpose usage
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #19387: span: update constructors to match c++20 draft spec and add lifetimebound attribute (master...lifetimebound2) https://github.com/bitcoin/bitcoin/pull/19387
< kanzure>
hi, when adding keys to a git repo, i think it would be good practice to also paste the armored key into the pull request text or comments because some folks follow by email and that's a good redundancy
< bitcoin-git>
[bitcoin] ryanofsky opened pull request #20494: refactor: Move node and wallet code out of src/interfaces (master...pr/ipc-mv) https://github.com/bitcoin/bitcoin/pull/20494
< wumpus>
kanzure: agree
< wumpus>
do we ever add actual keys to a repository these days though? I think we only have fingerprints
< wumpus>
the actual keys became both too big and too big a hassle to keep up to date
< bitcoin-git>
bitcoin/master fa18e7c Aaron Clauson: This change to the appveyor CI config for msvc builds reverses a change in...
< bitcoin-git>
bitcoin/master 19b8071 MarcoFalke: Merge #20489: CI msvc: only build vcpkg dependencies for release (not debu...
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20489: CI msvc: only build vcpkg dependencies for release (not debug) to reduce build times (master...msvc_vcpkg_relonly) https://github.com/bitcoin/bitcoin/pull/20489
< elichai2>
I'm looking at `IsInitialBlockDownload` and it's only does local checks on the state. do we anywhere check if another peer has a "better" chain and then start IBD from them?
< _Sam314-->
luke-jr, you are a despicable disgusting heap of rancid donkey shit.
< MarcoFalke>
elichai2: FindNextBlocksToDownload?
< sipa>
elichai2: IsIBD really has fairly little todo with the actual block download; it just informs a few heustistics
< elichai2>
sipa: so the "meat" of IBD is in `FindNextBlocksToDownload`? I see it is called under some condition for a `getdata` message, but I don't think I understand that condition. I thought it will be like "if my peer and I have more than X blocks apart, do headers first and then change state to IBD and start downloading the blocks"
< _Sam314-->
what does iritable bowl disease IBD has to do with bitcoin-core now?
< _Sam314-->
luke-jr is diarreah from my IBD
< _Sam314-->
btw there's a problem with IBD state in alpha bitcoin core
< _Sam314-->
when it checks the blocks after rolling them back
< _Sam314-->
you get a core dump and then have to restart
< _Sam314-->
at least as of the last git pull i did last week
< pinheadm_>
elichai2 findnextblocks... is the meat of all block downloading. At this point, the node has asked all peers for headers and it wants to check if any of those headers are valid and have more chainwork than our own current tip
< pinheadm_>
if so, we download those blocks and verify them
< pinheadm_>
and then in some cases a reorg is necessary to get our chain to the most work tip
< sipa>
elichai2: headers sync and blocks sync are not sequential processes that run as a separate thread or so; they both always work simultaneously, and are just defined by reactions to incoming messages
< sipa>
elichai2: FindNextBlock... is primarily called from SendMessages
< _Sam315-->
the fact that you turd lips harbor a lying a fuckface troll luke-jr who ruined the bitcoin ecosystem with lies is really sad to me.
< sipa>
elichai2: which just runs periodically for every peer
< sipa>
it decides based on the current state (which blocks we know the peer has, and which are already in flight) what to download
< bitcoin-git>
[bitcoin] dongcarl opened pull request #20495: sync: Use decltype(auto) return type for WITH_LOCK (master...2020-11-decltype-auto) https://github.com/bitcoin/bitcoin/pull/20495
< achow101>
gitian builders: 0.21.0rc2 detached sigs are pushed
< * hebasto>
signing
< * jonatack>
yoopi
< emzy>
I also did it for the first time. Now that I understand it.
< bitcoin-git>
[bitcoin] sanket1729 opened pull request #20497: [Refactor] Add MAX_STANDARD_SCRIPTSIG_SIZE to policy (master...policy) https://github.com/bitcoin/bitcoin/pull/20497
< sipa>
when building master, in a clean work dir, empty ccache, configured with "./configure --with-incompatible-bdb", I get:
< sipa>
/usr/bin/ld: cannot find -lQt5Core
< sipa>
while configure finds qt5 fine, and "pkg-config Qt5Core --libs" outputs the expected -lQt5Core
< sipa>
any ideas?
< sipa>
ubuntu 20.10
< sipa>
(i get the same with various other Qt libs)
< sipa>
same when building with clang
< bitcoin-git>
[bitcoin] practicalswift opened pull request #20499: Remove obsolete NODISCARD ifdef forest. Use [[nodiscard]] (C++17). (master...remove-nodiscard-cruft) https://github.com/bitcoin/bitcoin/pull/20499
< sipa>
vasild: uh, bizarre thing in addrv2 disk serialization... the decision whether to use compactsize nservices is based on the nVersion number stored in CAddress, but the decision whether to use addrv2 ip/network serialization is based on the context only
< sipa>
so you can construct a peers.dat file where some addresses use compactsize nServices, and others don't, independent from whether the file format is V3_BIP155 or not)
< * sipa>
suggests dropping support for that...
< fanquake>
sipa: did you resolve your linking issue?
< sipa>
fanquake: no
< sipa>
i just went back to building with --without-gui
< fanquake>
hmm ok. Unfortunately I have no answers for you. Other than maybe a missing package.