< bitcoin-git> [bitcoin] Rspigler opened pull request #21828: doc: Add historical release notes for 0.21.1 (master...0.21.1-release_notes) https://github.com/bitcoin/bitcoin/pull/21828
< gmaxwell> SLUSH POOL
< gmaxwell> SLUSH POOL
< gmaxwell> SLUSH POOL
< achow101> \o/
< bitcoin-git> [bitcoin] fanquake pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/d22e7ee93313...f2865b739417
< bitcoin-git> bitcoin/master 0a33145 Aaron Clauson: Remove Visual Studio 2017 reference from readme
< bitcoin-git> bitcoin/master f2865b7 fanquake: Merge bitcoin/bitcoin#21811: doc: Remove Visual Studio 2017 reference from...
< bitcoin-git> [bitcoin] fanquake merged pull request #21811: doc: Remove Visual Studio 2017 reference from readme (master...remove_vs2017) https://github.com/bitcoin/bitcoin/pull/21811
< bitcoin-git> [bitcoin] prayank23 closed pull request #21819: doc: Add info about supported format for URI (master...doc-uri) https://github.com/bitcoin/bitcoin/pull/21819
< bitcoin-git> [bitcoin] fanquake pushed 4 commits to master: https://github.com/bitcoin/bitcoin/compare/f2865b739417...59869704c0fe
< bitcoin-git> bitcoin/master e041ee0 Jon Atack: doc: add coinstatsindex to bitcoin.conf
< bitcoin-git> bitcoin/master 5d1050f Jon Atack: doc: fix -coinstatsindex help, and test/rpc touchups
< bitcoin-git> bitcoin/master 54133c5 Jon Atack: doc: add indexes/coinstats/db/ to files.md
< bitcoin-git> [bitcoin] fanquake merged pull request #21818: doc: fixup -coinstatsindex help, update bitcoin.conf and files.md (master...add-coinstatsindex-to-bitcoin-conf) https://github.com/bitcoin/bitcoin/pull/21818
< wumpus> provoostenator: fyi magnet:?xt=urn:btih:205b0189271c50a02fe966491e15737a01f94e08
< rebroad> gmaxwell what
< rebroad> gmaxwell, what's wrong with slush pool?
< rebroad> gmaxwell ah, thanks for the update on bitcoin-dev
< sipa> rebroad: he is expressing joy that slushpool mined a taproot-signalling block
< bitcoin-git> [bitcoin] MarcoFalke opened pull request #21830: doc: Add doc/release-notes/release-notes-0.21.1.md (master...2105-docRel) https://github.com/bitcoin/bitcoin/pull/21830
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #21828: doc: Add historical release notes for 0.21.1 (master...0.21.1-release_notes) https://github.com/bitcoin/bitcoin/pull/21828
< wumpus> can someone that knows Japanese review this (one line) change please: https://github.com/bitcoin-core/bitcoincore.org/pull/768
< sipa> wumpus: my knowledge of japanese is minimal, but afaict, it is just removing an 'r'
< wumpus> sipa: the 'r' does seem out of place
< sipa> yes
< gmaxwell> https://bitcoin-takeover.com/why-the-taproot-activation-proves-bitcoins-decentralization/ "However, the beginning appears to be pretty rocky: at block height 681487, only one block (mined by Slush Pool) out of 80 has signalled the activation. If 201 blocks don’t include the Taproot activation data, then the miner activation gets suspended and the community is going to look for another way to
< gmaxwell> get Taproot"
< bitcoin-git> [bitcoin] laanwj pushed 2 commits to master: https://github.com/bitcoin/bitcoin/compare/59869704c0fe...2448457cca18
< bitcoin-git> bitcoin/master fab53ea MarcoFalke: doc: Add doc/release-notes/release-notes-0.21.1.md
< bitcoin-git> bitcoin/master 2448457 W. J. van der Laan: Merge #21830: doc: Add doc/release-notes/release-notes-0.21.1.md
< bitcoin-git> [bitcoin] laanwj merged pull request #21830: doc: Add doc/release-notes/release-notes-0.21.1.md (master...2105-docRel) https://github.com/bitcoin/bitcoin/pull/21830
< provoostenator> wumpus: thanks, hash is now whitelisted
< provoostenator> wumpus: the "--verbose" argument in gitian-verify.py is unused...
< provoostenator> It's not outputting anything for me for several minutes, which is why I tried :-)
< bitcoin-git> [bitcoin] klementtan opened pull request #21832: cli: Improve -getinfo return format (master...master) https://github.com/bitcoin/bitcoin/pull/21832
< prusnak> if taproot signaling does not have enough blocks this difficulty period, how many difficulty periods tries are there left to try?
< prusnak> are there 7 diff periods altogether? so 6 more?
< aj> whichever period includes 00:00 11th August will be the last one; so probably 6 or 7 more after this one
< wumpus> provoostenator: it's quite slow if there are a lot of signatures, https://github.com/bitcoin-core/bitcoin-maintainer-tools/pull/90 speeds it up somewhat
< wumpus> provoostenator: that said, actually adding verbosity when using verbose makes sense
< prusnak> aj: thanks
< aj> harding: would have had to start signalling prior to MTP reaching starttime for warnings to trigger in current software, i think (uses the same 95%/90% threshold); starting to signal a few days early would have been fine
< rebroad> sipa ah!
< rebroad> is anyone here compiling for Windows 10? What debugger do you use please?
< hsjoberg_> The current signalling period is probably doomed, but let's hope for the next. As noted above, the miners have pledged to support Taproot, and according to https://taprootactivation.com they're 89.07% of the hashrate.
< murch> hsjoberg_: The release announcement came yesterday afternoon ET, I would assume that Asia was mostly asleep already, and today is Sunday. Maybe I'm projecting, but I would expect that most mining pools don't do non-emergency configuration changes on the weekend. And preferably they'd actually run a Taproot-enforcing version before signaling readiness.
< hsjoberg_> Sure yes, I agree. I don't expect them to hastily deploy the 0.21.1. But it's not like this has been well known for months now.
< hsjoberg_> Also if they not in the weekend, then this period is wasted. Only 129 non-signalling blocks left until this period cannot possibly lock in.
< murch> Also, miners should get a sense whether the network has adopted Taproot enforcing nodes before signaling. And my node so far has only a single peer that is 0.21.1.
< murch> Mh, I thought it's only 75 more.
< hsjoberg_> Indeed, but was also accounted for by the softfork itself. We moved the activation to november for this reason.
< murch> I don't expect the first period to lock in
< hsjoberg_> Yeah me neither
< hsjoberg_> But I'm still a bit irritated :P
< murch> 1814 out of 2016 need to signal, 129 have not signaled already, if 205 don't signal it won't lock in… correction, 76 more.
< hsjoberg_> You're right, I misread on my own site hehe
< murch> Bitnodes only shows 137 out of 9625 public nodes having upgraded to 0.21.1.
< bitcoin-git> [gui] hebasto closed pull request #86: Add Tor icon (master...200902-tor) https://github.com/bitcoin-core/gui/pull/86
< Talkless> If I don't use connect_nodes() in setup_network() in functional test, connecting nodes later does not make second node to sync: "Ignoring getheaders from peer=1 because node is in initial block download"
< Talkless> what am I missing?
< Talkless> two nodes, setup_clean_chain = True
< Talkless> in example_test.py they connect third node later, and it works, but there node 0 and node 1 are connected from the beginning
< Talkless> whatever, seems like add_p2p_connection() BEFORE sync interfared
< jonatack> Talkless: if the issue is one of being still in IBD, generate a block; if it's one of sync, perhaps call self.sync_all() or sync_blocks() or sync_mempools()
< murch> hsjoberg_: 90% of 2016 is 1814.4, so 1815 blocks have to signal to achieve lock-in. I.e. 202 blocks not signaling is enough to fail a period. :facepalm:
< aj> murch: (1815 is the figure that matters, not 90% -- consensus.nRuleChangeActivationThreshold = 1815; // 90% of 2016)
< hsjoberg_> murch: Ah yes correct! The code on the site is checking the other way around -- if there are enough blocks left to reach 1815 signalling blocks in the current period
< hsjoberg_> And yes as aj noted, the number 1815 is hardcoded.
< murch> aj: Yeah thanks, I should have been precise and noted that this was how 1815 was calculated not how it was defined in the code.
< provoostenator> Should we just start adding the GPG public keys themselves to https://github.com/bitcoin/bitcoin/tree/master/contrib/gitian-keys ?
< provoostenator> It can be a pain to find them sometimes. Though I can imagine it's also a pain to merged them.
< sipsorcery> provoostenator: in the past some people have also expressed a desire not to trust GitHub as the source for the public keys.
< luke-jr> no one source alone will ever be good; more potential sources is better
< luke-jr> but iirc we stopped keeping keys in the repo so that we wouldn't need to update them?
< luke-jr> PSA: the user 'theymos' right now, is an impersonator scammer; do NOT send it any bitcoins for any reason!
< gmaxwell> murch: bitnodes sees 162 0.21.1 and 157 21.99
< bitcoin-git> [bitcoin] Gapcoin1 opened pull request #21835: Update hmac_sha512.cpp (master...patch-2) https://github.com/bitcoin/bitcoin/pull/21835
< bitcoin-git> [bitcoin] MarcoFalke closed pull request #21835: Update hmac_sha512.cpp (master...patch-2) https://github.com/bitcoin/bitcoin/pull/21835
< gmaxwell> that user should probably be banned, they've opened the same junk PR before: https://github.com/bitcoin/bitcoin/pull/21383
< murch> gmaxwell: 21.99 is just an install from master some point after 0.21.0 was branched off, right?
< provoostenator> murch: normally yes
< gmaxwell> murch: yes well the numbering changed during master, so post the numbering change.
< murch> But that preceded 0.21.1 IIRC
< sipa> murch: the renumbering is in the master branch only
< sipa> the 0.21 branch obviously doesn't have it
< gmaxwell> murch: So yes, indeed it isn't necessarily the case that all things claiming to be 21.99 have the activation enabled, though I would expect many of them too (and parties running off master are presumably more likely to upgrade :P)-- but fine point.
< gmaxwell> (there are lots of limitations looking at bitnodes -- e.g. anything that uses my published banlists won't be listed there, which probably eliminates a fair number of more technical enthusasts)
< bitcoin-git> [bitcoin] hebasto opened pull request #21836: scripted-diff: Replace three dots with ellipsis in the UI strings (master...210502-ellipsis) https://github.com/bitcoin/bitcoin/pull/21836
< bitcoin-git> [bitcoin] hebasto closed pull request #21463: doc: Address feedback from Transifex translator community (master...210317-transifex) https://github.com/bitcoin/bitcoin/pull/21463
< robert_spigler> Saw twitter, reddit, and ML announcement. Torrent is up as well. I think all that is left is https://github.com/bitcoin/bitcoin/releases
< robert_spigler> Cobra might not put up the release on Bitcoin.org https://github.com/bitcoin-dot-org/Bitcoin.org/pull/3667
< harding> robert_spigler: left a comment to remind Cøbra of the consequences of not updating promptly. Maybe it'll get him to update, maybe it won't. *shrug*
< robert_spigler> harding: thanks!
< gmaxwell> Am I mistaken in my belief that the last release also throws warnings due to the retroactive revocation? e.g. not upgrading doesn't avoid the warning.
< luke-jr> I think it actually throws scarier warnings
< luke-jr> (cert revoked vs unsigned)
< robert_spigler> I believe so