< 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
< 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.
< 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.
< 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
< 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