< ajonas>
luke-jr: To piggyback on sipa's comment re the release notes, maybe I'm being too sensitive, but why would telemetry be ever be included? The mere mention puts me on edge.
< ajonas>
Also, soliciting opposition on Taproot in the release notes seems somewhat out of place.
< fanquake>
I agree with sipa & ajonas. Really not sure about the addition of that paragraph
< luke-jr>
ajonas: I mentioned it because it wouldn't be good if users got the false impression we were using telemetry
< luke-jr>
contructive would be suggesting how to rephrase it better :P
< ajonas>
That’s fair.
< ajonas>
I think just dropping that part would be best.
< luke-jr>
ajonas: won't people assume there is telemetry then?
< sipa>
why would they?
< sipa>
you make it sound like there is a reason to :)
< sipa>
i don't think the adoption of 0.21.0 is any indication specifically about how safe a softfork _in another release_ is
< luke-jr>
it sets a minimum bound if we advise people treat it as one
< luke-jr>
normally if someone says they're measuring usage of software, it's via telemetry
< fanquake>
sets a minimum bound of what?
< luke-jr>
fanquake: if we say "treat 0.21 as Taproot" and 85% upgrade within a month, we can probably assume a month is a safe timeframe to begin signalling
< sipa>
i don't think saying that makes that true
< sipa>
most people don't read release notes
< luke-jr>
sipa: if they don't, then it's only likely to be a slower upgrade than 0.21.Taproot
< sipa>
so?
< luke-jr>
so then it's (eg) 2 months, and only 1 month is needed; that's a safe error
< sipa>
you seem to want to use adoption of bitcoin core as telemetry (even if not through an explicit call-home)
< sipa>
i don't think we can do that, at all
< luke-jr>
why not?
< sipa>
because putting something about taproot in the release notes doesn't make "upgrading to 0.21.0" equivalent to "taproot will be safe"
< sipa>
even if you hope it is
< luke-jr>
it's a reasonable basis for a guess
< luke-jr>
_nothing_ can provide a guarantee
< sipa>
i really don't like telling people that a completely unrelated software update will be used as a signal for something unrelated
< luke-jr>
we have nothing else to go on?
< luke-jr>
if not past upgrades, then what?
< sipa>
how has the ecosystem in the past decides that softforks are safe?
< luke-jr>
pure fiat
< sipa>
rough consensus
< luke-jr>
that's only been to determine if a softfork should happen or not
< luke-jr>
and "rough consensus" with no inputs would still be arbitrary fiat
< sipa>
that's fair
< sipa>
(that rough consensus is the standard for doing a softfork or not, not for determining a safe timeline)
< sipa>
but i think that a safe timeline should be based on historical data, not about upgrades to a specific software version
< luke-jr>
I don't have such historical data, but I suspect it isn't pretty :/
< sipa>
maybe
< sipa>
it's important that an economically relevant part of the ecosystem updates before activation
< sipa>
but it's hard to see how that translates to software upgrade (of an unrelated major release, of one implementation)
< luke-jr>
eg, today only 39% of the network seems to run a current version (including most recent 0.18 and 0.19)
< luke-jr>
almost 44% run 0.20.x
< luke-jr>
based on this data, it would suggest we may need a year or longer before signalling even starts
< sipa>
i don't have much of an opinion on that
< luke-jr>
my hope of adding to 0.21 relnotes, is to encourage users to upgrade faster and reveal that we can be less slow about it
< sipa>
that doesn't mean they'll also be faster when 0.21.taproot comes out
< luke-jr>
right, but I'd hope if people upgrade specifically because of that relnote, that they will follow through with 0.21.taproot as well
< sipa>
(or alternatively, people may in fact update to a minor release faster than a major one, because they want to wait for the first bugfixes)
< luke-jr>
it's okay if 0.21.taproot is faster than 0.21.0
< luke-jr>
the problem would only be if it was slower
< sipa>
i'm just saying it's a shitty way to measure regardless
< sipa>
and i'm not even sure that what we measure is relevant
< luke-jr>
perhaps, but I don't have anything better to form an informed opinion from
< sipa>
perhaps, but putting something in the release notes isn't going to change that
< luke-jr>
it will make 0.21.0's upgrade rate more positive and informative
< luke-jr>
a new data point to work with
< luke-jr>
(probably; at worst, no new data)
< sipa>
i still find it very strange to mention that in the release notes
< sipa>
it's so unrelated
< luke-jr>
how else would we encourage such an effect?
< sipa>
i'm not sure that we should
< sipa>
and mentioning it just sounds like a weirdly pushy way to upgrade; people should upgrade because they're comfortable with it, not because of what implications their observable node version will have on the network
< luke-jr>
hmm
< luke-jr>
maybe a link to a web poll would be better - but it's harder to anonymise that trustlessly
< luke-jr>
and we have no idea how many don't do the poll
< sipa>
indeed, it's an inherently hard problem
< queip>
sorry if bad idea, but, perhaps include specific option like --signal-taproot, that appends to user agent information visible in p2p (pro/against/ignore, defaulting to ignore) and mention *that* flag, along with info re taproot, in release notes?
< luke-jr>
queip: many people just use the GUI
< luke-jr>
and way too late to add such a thing anyway
< queip>
(and GUI checkbox in options?)
< sipa>
and this is _not_ about acceptance/objection to the idea
< sipa>
this is about whether upgrading is safe
< luke-jr>
sipa: well, we are about to release 0.20.2 also; we could mention that as an alternative way to show upgrade speed?
< sipa>
i'd prefer to not mention it
< sipa>
it's just confusing
< luke-jr>
then we have nothing :|
< sipa>
i don't see the problem
< sipa>
why is it so important?
< luke-jr>
most people don't want to wait until 2022-2023 for Taproot?
< sipa>
okay?
< luke-jr>
and that's the soonest our current data suggests would be safe
< sipa>
i don't see why
< sipa>
node count on the network is a very weak measurement of economically relevant upgrade activity at best
< luke-jr>
it's all we have
< sipa>
we have companies that are known to support it
< luke-jr>
so companies decide Bitcoin protocol rules now?
< sipa>
what? this isn't about deciding rules
< sipa>
this is about coordinating a safe upgrade
< luke-jr>
safety comes from rule enforcement though
< sipa>
yes, by econonically relevant nodes
< luke-jr>
but if companies are taken to be those, then companies could impose other rules on everyone else too
< sipa>
you're taking this way too far
< luke-jr>
…
< sipa>
someone should just propose a reasonable upgrade mechanism, ask for feedback, and do it
< sipa>
i have no opinion on what that should be, but i don't think upgrade rates of nodes matter much... and certainly not those of an unrelated software release
< sipa>
and making it sound like upgrade rates will even determine that sounds weird and bad; these things should be decided using a public discussion
< luke-jr>
there is no forum of discussion for all bitcoin users
< sipa>
i would just say "Bitcoin Core 0.21.0 includes an implementation of the proposed Taproot (BIP 341-342) consensus rules, without activation for mainnet. Experimenting with Taproot can be done on the new Signet network where it is already active. Activation parameters will likely be included in a future minor release, and the proposed rules will not be enforced without upgrading to it."
< sipa>
or something like
< sipa>
that
< sipa>
that shows how this release is relevant to taproot, without tying upgrade numbers to how activation will be decided (because, imho, it actually shouldn't)
< luke-jr>
trusting big business to enforce rules is no better than trusting miners to do it
< luke-jr>
even if not a perfect metric, node upgrades should be the primary thing to look at to decide when signalling starting is safe
< luke-jr>
at the end of the day, businesses need to use what their income/expenses want to pay/be paid with
< dhruvm>
Where can I learn more about how the hardcoded seeds in contrib/seeds/nodes_main.txt are chosen each release?
< jonasschnelli>
achow101: shall I use #20880 for 0.19.0? Or should I stick with my head at c09afdd748816e95843c93609d9e6671c8e92efd (Remove premature make_code_directory) that worked for 0.19.2rc1?
< jnewbery>
luke-jr sipa ajonas fanquake: for what it's worth, I agree with sipa/ajonas/fanquake about the v0.21 release notes. The taproot paragraph seems unsuitable for the release notes.
< michaelfolkson>
luke-jr: It would be nice to rely on nodes rather than companies. But nodes are trivially sybilled and companies aren't.
< michaelfolkson>
I guess involving smaller companies is a strategy if you are concerned about big businesses
< michaelfolkson>
But agree with general premise that interacting with big businesses when there is clear consensus for the soft fork change across the whole ecosystem is very different to interacting with big businesses when there isn't
< fanquake>
wumpus / sipa can you block kaycoinsUSA
< bitcoin-git>
bitcoin/master faecb74 Jon Atack: Expose integral m_conn_type in CNodeStats, remove m_conn_type_string
< bitcoin-git>
bitcoin/master 9158d6f MarcoFalke: Merge #20786: net: [refactor] Prefer integral types in CNodeStats
< bitcoin-git>
[bitcoin] MarcoFalke merged pull request #20786: net: [refactor] Prefer integral types in CNodeStats (master...2012-net) https://github.com/bitcoin/bitcoin/pull/20786
< bitcoin-git>
[bitcoin] hebasto opened pull request #20884: script: Improve robustness of bitcoind.service on startup (master...210108-systemd) https://github.com/bitcoin/bitcoin/pull/20884
< achow101>
jonasschnelli: until 20880 is merged, I think you should stick with the commit I tagged "with-codesign-allocate" which should be your current HEAD
< jonasschnelli>
achow101: okay
< jonasschnelli>
gitian builders: 0.19.2 detached signatures are pushed.
< sipa>
10:55:17 < wumpus> btw, is it time to tag 0.19.2? doesn't seem another rc is needed
< bitcoin-git>
[bitcoin] mjdietzx opened pull request #20889: test: ensure any failing method in MiniWallet leaves no side-effects (master...test-miniwallet-no-side-effects) https://github.com/bitcoin/bitcoin/pull/20889
< wumpus>
luke-jr: no idea, I wouldn't have chosen myself to do a release on an old branch like that, it's always the same story
< wumpus>
"oh did anyone test the rc at all", no idea, it's possible no one runs it at all and it's purely wasted time
< wumpus>
in any case if anyone tested it they didn't report any problems with it
< sipa>
i wonder how common extensive rc processes are for old bacport bugfix releases in other projects
< sipa>
it's not that they are untested; all our automated testing for them passes