< bitcoin-git>
bitcoin/master 67669ab Hennadii Stepanov: build: Fix Boost Process compatibility with mingw-w64 compiler
< bitcoin-git>
bitcoin/master 2749613 fanquake: Merge bitcoin/bitcoin#22348: build: Fix cross build for Windows with Boost...
< bitcoin-git>
[bitcoin] fanquake merged pull request #22348: build: Fix cross build for Windows with Boost Process (master...210627-boost) https://github.com/bitcoin/bitcoin/pull/22348
< bitcoin-git>
[bitcoin] fanquake merged pull request #22348: build: Fix cross build for Windows with Boost Process (master...210627-boost) https://github.com/bitcoin/bitcoin/pull/22348
< fanquake>
3/4 of the way through your Guix build is the wrong time to be trying to remember if you checked out the right branch before startitng
< fanquake>
3/4 of the way through your Guix build is the wrong time to be trying to remember if you checked out the right branch before startitng
< bitcoin-git>
[bitcoin] fanquake opened pull request #22381: guix: Test security-check sanity before performing them (with macOS) (master...20980_macOS_fixups) https://github.com/bitcoin/bitcoin/pull/22381
< bitcoin-git>
[bitcoin] fanquake opened pull request #22381: guix: Test security-check sanity before performing them (with macOS) (master...20980_macOS_fixups) https://github.com/bitcoin/bitcoin/pull/22381
< bitcoin-git>
[bitcoin] fanquake closed pull request #20980: guix: Test security-check sanity before performing them (master...2020-12-guix-mingw-extra-flags) https://github.com/bitcoin/bitcoin/pull/20980
< bitcoin-git>
[bitcoin] fanquake closed pull request #20980: guix: Test security-check sanity before performing them (master...2020-12-guix-mingw-extra-flags) https://github.com/bitcoin/bitcoin/pull/20980
< laanwj>
haha yes
< laanwj>
haha yes
< hebasto>
it seems #22381 cannot be fully tested and reviewed before #22365, at least to test the ELF functionality
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22381 | guix: Test security-check sanity before performing them (with macOS) by fanquake · Pull Request #22381 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
< hebasto>
it seems #22381 cannot be fully tested and reviewed before #22365, at least to test the ELF functionality
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22381 | guix: Test security-check sanity before performing them (with macOS) by fanquake · Pull Request #22381 · bitcoin/bitcoin · GitHub
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
< fanquake>
You can always just run the tests manually
< hebasto>
right
< fanquake>
You can always just run the tests manually
< hebasto>
right
< fanquake>
The important changes there are for Win and macOS
< fanquake>
Also, the other changes will mostly be dropped when we move to testing the ELF binaries with LIEF
< fanquake>
The important changes there are for Win and macOS
< fanquake>
Also, the other changes will mostly be dropped when we move to testing the ELF binaries with LIEF
< hebasto>
we won't move to LIEF for ELF binaries for 22.0 release, right?
< hebasto>
we won't move to LIEF for ELF binaries for 22.0 release, right?
< laanwj>
i don't think so
< fanquake>
It's not a requirement, but I could put the changes together tomorrow if you want to see them
< laanwj>
i don't think so
< fanquake>
It's not a requirement, but I could put the changes together tomorrow if you want to see them
< fanquake>
I wont be around for the meeting, but I assume branch off will discussed, and I think we are in pretty good shape.
< laanwj>
i'm not sure what would be the advantage of switching that last minute
< fanquake>
22365 + 22381 will just about round out the Guix changes. With some docs in #21711.
< laanwj>
hebasto: yes, it doesn't seem any new features have been added to the milestone for some time so I thought it was about time
< laanwj>
hebasto: yes, it doesn't seem any new features have been added to the milestone for some time so I thought it was about time
< bitcoin-git>
[bitcoin] jlopp opened pull request #22383: prefer to use txindex if available for GetTransaction (master...GetTransactionPerformance) https://github.com/bitcoin/bitcoin/pull/22383
< laanwj>
bugfixes can still go in, and besides, we're not ready to branch off yet as things are still tagged 22.0 that need to make it in
< bitcoin-git>
[bitcoin] jlopp opened pull request #22383: prefer to use txindex if available for GetTransaction (master...GetTransactionPerformance) https://github.com/bitcoin/bitcoin/pull/22383
< laanwj>
bugfixes can still go in, and besides, we're not ready to branch off yet as things are still tagged 22.0 that need to make it in
< jonatack>
laanwj: yes, vasild and i have been discussing the merits of each offline, 22112 seems best given that SAM 3.2 and up will default ports to 0 and begin portful routing in 3.3 iiuc, but it had some addrman and connection issues to sort out that may have been addressed today. will review again and retest
< laanwj>
jonatack: thanks, I'll start testing it too
< jonatack>
laanwj: yes, vasild and i have been discussing the merits of each offline, 22112 seems best given that SAM 3.2 and up will default ports to 0 and begin portful routing in 3.3 iiuc, but it had some addrman and connection issues to sort out that may have been addressed today. will review again and retest
< laanwj>
jonatack: thanks, I'll start testing it too
< vasild>
btw, to be clear - the last commit from 22112 is kind of optional - it is only to convert the addrmans of early users who run un-relased bitcoin core
< vasild>
btw, to be clear - the last commit from 22112 is kind of optional - it is only to convert the addrmans of early users who run un-relased bitcoin core
< vasild>
as such I think it can/should be reverted eventually at some time in the future, when people have stopped using post-i2p and pre-22112 code
< jonatack>
the two issues were that (a) I2P addrman entries were removed due to bucket repositioning with the resetting of those entries' ports to 0 (i went from 15 I2P in my addrman to 5) but the new version preserves them and removes the "other" entry instead
< vasild>
as such I think it can/should be reverted eventually at some time in the future, when people have stopped using post-i2p and pre-22112 code
< jonatack>
the two issues were that (a) I2P addrman entries were removed due to bucket repositioning with the resetting of those entries' ports to 0 (i went from 15 I2P in my addrman to 5) but the new version preserves them and removes the "other" entry instead
< jonatack>
and (b) we realized that addnode of I2P peers without a port specified would not establish an outbound connection. the latest push intends to fix that as well.
< jonatack>
so two things to test :)
< jonatack>
and (b) we realized that addnode of I2P peers without a port specified would not establish an outbound connection. the latest push intends to fix that as well.
< jonatack>
so two things to test :)
< sdaftuar>
vasild: thanks for thinking about this addr relay issue. i'm supportive of work towards documenting and coordinating how we want addr relay to work on the network, but i tend to think it's premature to add a new protocol message until we've done a bit more work on how we want addr relay to work for different kinds of network addresses and what kind of propagation model we want to aim for
< sdaftuar>
vasild: thanks for thinking about this addr relay issue. i'm supportive of work towards documenting and coordinating how we want addr relay to work on the network, but i tend to think it's premature to add a new protocol message until we've done a bit more work on how we want addr relay to work for different kinds of network addresses and what kind of propagation model we want to aim for
< sdaftuar>
with respect to your proposed "no-unsolicited-addrs" message, i think it would likely be deprecated in the future in favor of a message that negotiated which types of network addresses (ipv4, ipv6, tor, i2p, ...) a peer is interested in specifically?
< sdaftuar>
with respect to your proposed "no-unsolicited-addrs" message, i think it would likely be deprecated in the future in favor of a message that negotiated which types of network addresses (ipv4, ipv6, tor, i2p, ...) a peer is interested in specifically?
< sdaftuar>
but even now we don't have a good model, or agreed upon set of goals, for how we want addrs to propagate. for instance one question i have is to what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all.
< sdaftuar>
or, what fraction of the network should receive any given announced address, over some time period
< sdaftuar>
but even now we don't have a good model, or agreed upon set of goals, for how we want addrs to propagate. for instance one question i have is to what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all.
< sdaftuar>
or, what fraction of the network should receive any given announced address, over some time period
< vasild>
hmm
< jonatack>
interesting questions
< sdaftuar>
those kinds of questions make it hard in my mind to ask the network to adopt an addr relay protocol right now. if we're going to ask software to coordinate on this area, we should first have an idea of what we're aiming for
< vasild>
hmm
< jonatack>
interesting questions
< sdaftuar>
those kinds of questions make it hard in my mind to ask the network to adopt an addr relay protocol right now. if we're going to ask software to coordinate on this area, we should first have an idea of what we're aiming for
< vasild>
I agree
< vasild>
"be deprecated in the future in favor of a message that negotiated which types of network addresses (ipv4, ipv6, tor, i2p, ...) a peer is interested in specifically?" -- do you mean unsolicited or regardless?
< vasild>
I agree
< vasild>
"be deprecated in the future in favor of a message that negotiated which types of network addresses (ipv4, ipv6, tor, i2p, ...) a peer is interested in specifically?" -- do you mean unsolicited or regardless?
< sdaftuar>
could be either; i could imagine that we need to negotiate behavior both around getaddr/getaddr-responses as well as unsolicited relay
< sdaftuar>
could be either; i could imagine that we need to negotiate behavior both around getaddr/getaddr-responses as well as unsolicited relay
< jonatack>
it does seems that adding networks has introduced changes, effects and interactions that we're probably still mostly on the cusp of
< jonatack>
and addr relay was already fertile ground for more research
< jonatack>
it does seems that adding networks has introduced changes, effects and interactions that we're probably still mostly on the cusp of
< jonatack>
and addr relay was already fertile ground for more research
< vasild>
So would a message like the following deprecate "no-unsolicited-addrs": "I want only ipv6,tor addresses as a response to getaddr and/or unsolicited"...
< vasild>
So would a message like the following deprecate "no-unsolicited-addrs": "I want only ipv6,tor addresses as a response to getaddr and/or unsolicited"...
< earnestly>
(Can solicitation divulge information in such a way that is useful for attacking anonimity?)
< vasild>
I don't think the latter supersedes "no-unsolicited-addrs". solicited-or-not is one thing, the type of addresses is another, no?
< earnestly>
(Can solicitation divulge information in such a way that is useful for attacking anonimity?)
< vasild>
I don't think the latter supersedes "no-unsolicited-addrs". solicited-or-not is one thing, the type of addresses is another, no?
< sdaftuar>
vasild: i could imagine that we'd provide some kind of score for how we treat relay of different address types, akin to how we currently have different relay policies for networks we understand and networks we don't
< sdaftuar>
it's possible it own't evolve that way of course, i just htink we don't know yet
< sdaftuar>
vasild: i could imagine that we'd provide some kind of score for how we treat relay of different address types, akin to how we currently have different relay policies for networks we understand and networks we don't
< sdaftuar>
it's possible it own't evolve that way of course, i just htink we don't know yet
< vasild>
earnestly: I think, in theory mostly, one can observe that a given ipv4 node relays readily i2p addresses but does not relay tor addresses. So one may be able to deduct that that node has i2p connectivity and not tor connectivity...
< vasild>
earnestly: I think, in theory mostly, one can observe that a given ipv4 node relays readily i2p addresses but does not relay tor addresses. So one may be able to deduct that that node has i2p connectivity and not tor connectivity...
< vasild>
s/does not relay tor addresses/relays tor addresses less readily/
< vasild>
s/does not relay tor addresses/relays tor addresses less readily/
< vasild>
earnestly: even if I can tell your ipv4 node has i2p connectivity and does not have tor connectivity, what harm could I do?
< earnestly>
vasild: It only came to mind due to that old paper about vulnerabilities in using tor with that autoban system
< vasild>
earnestly: even if I can tell your ipv4 node has i2p connectivity and does not have tor connectivity, what harm could I do?
< earnestly>
vasild: It only came to mind due to that old paper about vulnerabilities in using tor with that autoban system
< vasild>
I have not read that one
< vasild>
it is cheap to generate tor addresses, I guess if one gets banned he can create a new address easily and persist misbehaving
< vasild>
I have not read that one
< vasild>
it is cheap to generate tor addresses, I guess if one gets banned he can create a new address easily and persist misbehaving
< vasild>
"A low-resource attacker can gain full control of information flows between all users who chose to use Bitcoin over Tor" :-O
< vasild>
"A low-resource attacker can gain full control of information flows between all users who chose to use Bitcoin over Tor" :-O
< vasild>
sdaftuar: "to what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all" -- https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki contains this sentence: "Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and
< vasild>
make it more difficult for an observer to tell which networks a node is connected to.", I think that makes sense.
< vasild>
sdaftuar: "to what extent it makes sense for nodes that don't understand, say, i2p addresses to be participating in i2p address relay at all" -- https://github.com/bitcoin/bips/blob/master/bip-0155.mediawiki contains this sentence: "Clients are RECOMMENDED to gossip addresses from all known networks even if they are currently not connected to some of them. That could help multi-homed nodes and
< vasild>
make it more difficult for an observer to tell which networks a node is connected to.", I think that makes sense.
< vasild>
Do we want as many as possible nodes to receive an announced address as soon as possible? (if we could do that without causing flood/excessive traffic)
< vasild>
Do we want as many as possible nodes to receive an announced address as soon as possible? (if we could do that without causing flood/excessive traffic)
< laanwj>
i'm thinking of removing #20234 from the milestone because there is some concept discussion/disagreement, it's a bit too late in the cycle for that and it's not critical to have in 22.0
< achow101>
should the guix stuff be kept? they're both still drafts
< laanwj>
the guix stuff is needed to do a release
< laanwj>
i'm thinking of removing #20234 from the milestone because there is some concept discussion/disagreement, it's a bit too late in the cycle for that and it's not critical to have in 22.0
< laanwj>
docs are very important because a lot of people are going to do guix builds for the first time
< laanwj>
docs are very important because a lot of people are going to do guix builds for the first time
< hebasto>
luke-jr: #22365 and guix, or multiple glibc symbol compatibility fixups and gitian
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
< laanwj>
luke-jr: if there is a problem with the guix build we can always fall back to gitian, but it is unlikely
< hebasto>
luke-jr: #22365 and guix, or multiple glibc symbol compatibility fixups and gitian
<@gribble>
https://github.com/bitcoin/bitcoin/issues/22365 | guix: Avoid relying on newer symbols by rebasing our cross toolchains on older glibcs by dongcarl · Pull Request #22365 · bitcoin/bitcoin · GitHub
< laanwj>
luke-jr: if there is a problem with the guix build we can always fall back to gitian, but it is unlikely
< luke-jr>
hebasto: gitian should be fixed even if we use guix
< laanwj>
it might be possible that bugfixes are still added for the 22.0 milestone but the feature freeze is active now
< dongcarl>
Hi
< dongcarl>
I’m working on the docs right now, updating for Guix 1.3.0
< luke-jr>
hebasto: gitian should be fixed even if we use guix
< laanwj>
it might be possible that bugfixes are still added for the 22.0 milestone but the feature freeze is active now
< dongcarl>
Hi
< dongcarl>
I’m working on the docs right now, updating for Guix 1.3.0
< dongcarl>
Are we talking about fixing the gitian build for the symbol problem?
< laanwj>
(and so is the translation string freeze, we've done the last update of the source translations pre-rc a few hours ago)
< laanwj>
dongcarl: achow101 just noted that your PRs on the 22.0 milestone are labeled as draft, which is somewhat confusing
< dongcarl>
Are we talking about fixing the gitian build for the symbol problem?
< laanwj>
(and so is the translation string freeze, we've done the last update of the source translations pre-rc a few hours ago)
< laanwj>
dongcarl: achow101 just noted that your PRs on the 22.0 milestone are labeled as draft, which is somewhat confusing
< dongcarl>
Yes I intend on adding more commentary to those PRs so that’s why they are still Draft
< dongcarl>
Can mark as ready if people want, no strong opinions
< dongcarl>
Yes I intend on adding more commentary to those PRs so that’s why they are still Draft
< dongcarl>
Can mark as ready if people want, no strong opinions
< laanwj>
it's fine imo
< laanwj>
it's fine imo
< dongcarl>
Happy to answer any more questions :-)
< laanwj>
#topic
< core-meetingbot>
topic:
< laanwj>
#topic When it's okay to auto-update across softfork enforcement (luke-jr)
< core-meetingbot>
topic: When it's okay to auto-update across softfork enforcement (luke-jr)
< dongcarl>
Happy to answer any more questions :-)
< laanwj>
#topic
< core-meetingbot>
topic:
< laanwj>
#topic When it's okay to auto-update across softfork enforcement (luke-jr)
< core-meetingbot>
topic: When it's okay to auto-update across softfork enforcement (luke-jr)
< luke-jr>
We obviously don't have any auto-updates in Core, but some things exist (Snap, PPAs, Gentoo pkg) which do allow for users to auto-upgrade
< luke-jr>
Softforks should be consensual, but when does it move on to the point where it's just assumed users want it?
< luke-jr>
We obviously don't have any auto-updates in Core, but some things exist (Snap, PPAs, Gentoo pkg) which do allow for users to auto-upgrade
< luke-jr>
Softforks should be consensual, but when does it move on to the point where it's just assumed users want it?
< luke-jr>
any thoughts?
< achow101>
presumably after lock in?
< luke-jr>
(my Core PPA is still at 0.21.0 pending some solution)
< luke-jr>
achow101: but lock-in is just miners, not the community
< luke-jr>
any thoughts?
< achow101>
presumably after lock in?
< luke-jr>
(my Core PPA is still at 0.21.0 pending some solution)
< luke-jr>
achow101: but lock-in is just miners, not the community
< ariard>
well we have buried deployment which are quite making assumptions on users w.r.t to softfork activation
< ariard>
bip90
< luke-jr>
do we then assume any opposed users would have forked off at this point?
< luke-jr>
ariard: but those are already active, which I think is a very clear safe time to do it
< sipa>
is it possible in snap etc to have a different channel or package name per release?
< luke-jr>
once activation, IMO it's pretty clearly fine
< ariard>
well we have buried deployment which are quite making assumptions on users w.r.t to softfork activation
< ariard>
bip90
< luke-jr>
do we then assume any opposed users would have forked off at this point?
< luke-jr>
ariard: but those are already active, which I think is a very clear safe time to do it
< sipa>
is it possible in snap etc to have a different channel or package name per release?
< luke-jr>
once activation, IMO it's pretty clearly fine
< luke-jr>
sipa: not sure about Snaps, but for the PPA, it seems to be possible to prompt the user to explicitly agree
< luke-jr>
there's some packages that added an EULA for a version bump prompting the user on upgrade, and that seems similar logically
< luke-jr>
sipa: not sure about Snaps, but for the PPA, it seems to be possible to prompt the user to explicitly agree
< luke-jr>
there's some packages that added an EULA for a version bump prompting the user on upgrade, and that seems similar logically
< luke-jr>
Gentoo packages have USE flags, and can be set to not install until one is set by the user
< ariard>
luke-jr: i might miss context there, but my reasoning by pointing to buried deployment is when we hardcode activation height we restrain user choice of opposing softforks
< luke-jr>
(which is what 0.21.1 is doing right now on the Gentoo overlay)
< luke-jr>
Gentoo packages have USE flags, and can be set to not install until one is set by the user
< ariard>
luke-jr: i might miss context there, but my reasoning by pointing to buried deployment is when we hardcode activation height we restrain user choice of opposing softforks
< luke-jr>
(which is what 0.21.1 is doing right now on the Gentoo overlay)
< sipa>
ariard: we can't wait for buried deployment here
< luke-jr>
ariard: by the time of activation, users need to either enforce, or reject the chain it activated on; the latter requires code changes regardless
< sipa>
ariard: we can't wait to release 0.21.1 packages until taproot is active, e.g.
< sipa>
(+ probably a few years)
< luke-jr>
yeah, simply not having packages is a problem too because most users *will* want to upgrade
< sipa>
ariard: we can't wait for buried deployment here
< luke-jr>
ariard: by the time of activation, users need to either enforce, or reject the chain it activated on; the latter requires code changes regardless
< sipa>
ariard: we can't wait to release 0.21.1 packages until taproot is active, e.g.
< sipa>
(+ probably a few years)
< luke-jr>
yeah, simply not having packages is a problem too because most users *will* want to upgrade
< luke-jr>
doing so should be easy
< sipa>
and i don't think opposition is the right criterion here; nothing is being forced
< sipa>
the question is about unaware upgrading
< ariard>
luke-jr: gotcha it's regard with increasing the number of users with softfork enforcement logic at time of taproot activation?
< sipa>
if people were aware of a softfork they'd active oppose, they'd stop using the snap/ppa/whatever
< luke-jr>
doing so should be easy
< sipa>
and i don't think opposition is the right criterion here; nothing is being forced
< sipa>
the question is about unaware upgrading
< ariard>
luke-jr: gotcha it's regard with increasing the number of users with softfork enforcement logic at time of taproot activation?
< sipa>
if people were aware of a softfork they'd active oppose, they'd stop using the snap/ppa/whatever
< sipa>
ariard: no, it's just that people shouldn't be opted into enforcing softfork rules without being aware of it
< luke-jr>
ariard: softforks without user enforcement are effectively failed softforks
< sipa>
ariard: no, it's just that people shouldn't be opted into enforcing softfork rules without being aware of it
< luke-jr>
ariard: softforks without user enforcement are effectively failed softforks
< sipa>
ariard: the concern is simply that whomever has the PPA/snap/... admin powers could push new consensus rule enforcement onto the network, without the node operators being aware
< sipa>
this is the reason why bitcoin core's own release mechanism explicitly does not have an auto-upgrade mechanism
< sipa>
but this is obviously bypassed by using distro-packaged versions that do automatically update
< sipa>
ariard: the concern is simply that whomever has the PPA/snap/... admin powers could push new consensus rule enforcement onto the network, without the node operators being aware
< sipa>
this is the reason why bitcoin core's own release mechanism explicitly does not have an auto-upgrade mechanism
< sipa>
but this is obviously bypassed by using distro-packaged versions that do automatically update
< luke-jr>
obviously not-pushing a good change doesn't stop someone from pushing a bad one, but there's an ethical and liability side as well
< ariard>
sipa: okay so it's about making showy the upgrade of PPA/snap/... etc in case of node operators disapprove the new consensus rules and want to switch vendors ?
< sipa>
ariard: i don't know what the solution is
< luke-jr>
ariard: the node owner should be the one to make the decision
< ariard>
luke-jr: fully agree on this!
< luke-jr>
obviously not-pushing a good change doesn't stop someone from pushing a bad one, but there's an ethical and liability side as well
< ariard>
sipa: okay so it's about making showy the upgrade of PPA/snap/... etc in case of node operators disapprove the new consensus rules and want to switch vendors ?
< sipa>
ariard: i don't know what the solution is
< luke-jr>
ariard: the node owner should be the one to make the decision
< ariard>
luke-jr: fully agree on this!
< ariard>
but a lot of folks might just fetch package without reading release notes
< sipa>
that's inevitable
< ariard>
i think so too
< luke-jr>
ariard: bitcoincore.org's blog post has the title specific to Taproot too for example
< laanwj>
yes the thing with linux distributions is that the user will get the update together with tons of other package updates, they might not even notice it
< ariard>
but a lot of folks might just fetch package without reading release notes
< sipa>
that's inevitable
< ariard>
i think so too
< luke-jr>
ariard: bitcoincore.org's blog post has the title specific to Taproot too for example
< laanwj>
yes the thing with linux distributions is that the user will get the update together with tons of other package updates, they might not even notice it
< luke-jr>
I *can* make the PPA and Gentoo stuff force user consent explicitly; the question is when it's okay to omit that ;)
< luke-jr>
(MarcoFalke would have to comment on his snap stuff)
< laanwj>
being at the least able to show release notes would be nice, freebsd has this for significant changes, but dunno about linux distros, never saw it in debian afaik
< luke-jr>
I *can* make the PPA and Gentoo stuff force user consent explicitly; the question is when it's okay to omit that ;)
< luke-jr>
(MarcoFalke would have to comment on his snap stuff)
< laanwj>
being at the least able to show release notes would be nice, freebsd has this for significant changes, but dunno about linux distros, never saw it in debian afaik
< ariard>
luke-jr: imho, i would say it's more a PPA/gentoo/snap admin policy there, hard to all agree on this?
< ariard>
luke-jr: imho, i would say it's more a PPA/gentoo/snap admin policy there, hard to all agree on this?
< harding>
debian has an opt-in setting for major release note stuff.
< laanwj>
(and for people doing background automatic updates that wouldn't work anyway)
< laanwj>
harding: oh good to know
< harding>
debian has an opt-in setting for major release note stuff.
< laanwj>
(and for people doing background automatic updates that wouldn't work anyway)
< laanwj>
harding: oh good to know
< sipa>
in a way this is a strange discussion, because i think we're effectively worrying about a rogue distribution maintainer
< harding>
For people with background updates, debian will main those notices to you, but only if you're like the 0.01% of people who still setup a MTA.
< sipa>
but if that's the case, they would obviously patch out whatever warning exists
< harding>
s/main/mail/
< luke-jr>
sipa: not necessarily rogue
< sipa>
in a way this is a strange discussion, because i think we're effectively worrying about a rogue distribution maintainer
< harding>
For people with background updates, debian will main those notices to you, but only if you're like the 0.01% of people who still setup a MTA.
< sipa>
but if that's the case, they would obviously patch out whatever warning exists
< harding>
s/main/mail/
< luke-jr>
sipa: not necessarily rogue
< sipa>
and taking this to its logical conclusion, i think it's just that centrally-controlled package repositories are a risk... which isn't surprising
< luke-jr>
sipa: this is a real-world issue for me right now, I need to bump the Core PPA at some point before November
< laanwj>
right, it's for good reason we resisted bitcoin being part of package repositories for a long time
< sipa>
and taking this to its logical conclusion, i think it's just that centrally-controlled package repositories are a risk... which isn't surprising
< luke-jr>
sipa: this is a real-world issue for me right now, I need to bump the Core PPA at some point before November
< laanwj>
right, it's for good reason we resisted bitcoin being part of package repositories for a long time
< laanwj>
it's extremly unsuited to automatic updates
< sipa>
luke-jr: right, i agree this should happen for information purposes, but the real reason why you'd want to show that warning is so that users know "be aware, the package maintainer is including a consensus change in this release, which you're automatically getting - if you don't want that, move away"
< sipa>
luke-jr: and clearly, we're of the opinion that this consensus change is going to happen
< sipa>
so what is the warning protecting against? if this information was intentionally false, you'd also remove the warning...
< laanwj>
it's extremly unsuited to automatic updates
< sipa>
luke-jr: right, i agree this should happen for information purposes, but the real reason why you'd want to show that warning is so that users know "be aware, the package maintainer is including a consensus change in this release, which you're automatically getting - if you don't want that, move away"
< sipa>
luke-jr: and clearly, we're of the opinion that this consensus change is going to happen
< sipa>
so what is the warning protecting against? if this information was intentionally false, you'd also remove the warning...
< luke-jr>
because even honest package maintainers shouldn't make the call for users ;)
< luke-jr>
because even honest package maintainers shouldn't make the call for users ;)
< ariard>
sipa: well you might be a really rogue distribution maintainer and luring the user that softfork A' shipped in the package is software A that user heard activated in the public space...
< sipa>
i'm not sure. by installing through a package manager, users have delegated most of their power in having control over what they run already, regardless of consensus changes even
< sipa>
that's a concern on itself
< ariard>
s/software/softfork/g
< sipa>
but i don't know what to do about it
< ariard>
sipa: well you might be a really rogue distribution maintainer and luring the user that softfork A' shipped in the package is software A that user heard activated in the public space...
< sipa>
i'm not sure. by installing through a package manager, users have delegated most of their power in having control over what they run already, regardless of consensus changes even
< sipa>
that's a concern on itself
< ariard>
s/software/softfork/g
< sipa>
but i don't know what to do about it
< ariard>
empower and educate users to have more of them building from the sources
< sipa>
yeah
< sipa>
also, good luck
< earnestly>
(Casestudy: debian would miscompile mpv against ffmpeg, mpv added warnings to avoid bug reports, debian patched the warning out rendering mpv's attempts ineffectual.)
< laanwj>
manually downloading binaries is fine too
< jonatack>
or download the binaries
< harding>
Some packages in debian come shipped in a not-completely-functional state; you have to flip some flag in /etc/defaults/package-name. You can have Bitcoin Core 0.21.1+ require you put "taproot = yes" in that file before it'll run.
< ariard>
empower and educate users to have more of them building from the sources
< sipa>
yeah
< sipa>
also, good luck
< earnestly>
(Casestudy: debian would miscompile mpv against ffmpeg, mpv added warnings to avoid bug reports, debian patched the warning out rendering mpv's attempts ineffectual.)
< laanwj>
manually downloading binaries is fine too
< jonatack>
or download the binaries
< harding>
Some packages in debian come shipped in a not-completely-functional state; you have to flip some flag in /etc/defaults/package-name. You can have Bitcoin Core 0.21.1+ require you put "taproot = yes" in that file before it'll run.
< laanwj>
just not anything that auto updates, it's also arisk if you're actually using bitcoind for anything; e.g. some software might not work with the new release yet, though that's mostly for major releases that deprecate or change RPC functionality
< earnestly>
You really have to leave these decisions to downstream
< harding>
(The debconf configuration wizard can prompt you to do that.)
< earnestly>
(I.e. not worry)
< luke-jr>
harding: but then we're patching the code
< laanwj>
just not anything that auto updates, it's also arisk if you're actually using bitcoind for anything; e.g. some software might not work with the new release yet, though that's mostly for major releases that deprecate or change RPC functionality
< earnestly>
You really have to leave these decisions to downstream
< harding>
(The debconf configuration wizard can prompt you to do that.)
< earnestly>
(I.e. not worry)
< luke-jr>
harding: but then we're patching the code
< luke-jr>
maybe we should add a softforks=<list> upstream for future stuff like that
< luke-jr>
earnestly: there is no downstream
< earnestly>
That would be the best option, probably
< earnestly>
downstream here is defined as package maintainers
< luke-jr>
maybe we should add a softforks=<list> upstream for future stuff like that
< luke-jr>
earnestly: there is no downstream
< earnestly>
That would be the best option, probably
< earnestly>
downstream here is defined as package maintainers
< harding>
luke-jr: eh, I guess. Maybe then you could rename /usr/bin/bitcoind to /usr/bin/bitcoind-taproot and then use the symlink alternatives mechanism to manage /usr/bin/bitcoind. That way users have to opt in to the "bitcoind-taproot" alternative.
< luke-jr>
earnestly: ie, me
< sipa>
and just have it not run if the flag isn't present? you'll risk maintainers patching it out, because it's too much of an annoyance to users
< luke-jr>
harding: won't it auto-switch?
< sipa>
and i think this also isn't the core of the issue
< earnestly>
luke-jr: That there is an overlap between upstream and downstream doesn't change the distinction
< laanwj>
yes , getting the update but ending up with a non-working binary that's pretty awful for users
< earnestly>
What you do for the distribution is related to upstream but not identical
< luke-jr>
sipa: right; we can't stop people from patchign things out, but this provides a good solution otherwise
< harding>
luke-jr: eh, I guess. Maybe then you could rename /usr/bin/bitcoind to /usr/bin/bitcoind-taproot and then use the symlink alternatives mechanism to manage /usr/bin/bitcoind. That way users have to opt in to the "bitcoind-taproot" alternative.
< luke-jr>
earnestly: ie, me
< sipa>
and just have it not run if the flag isn't present? you'll risk maintainers patching it out, because it's too much of an annoyance to users
< luke-jr>
harding: won't it auto-switch?
< sipa>
and i think this also isn't the core of the issue
< earnestly>
luke-jr: That there is an overlap between upstream and downstream doesn't change the distinction
< laanwj>
yes , getting the update but ending up with a non-working binary that's pretty awful for users
< earnestly>
What you do for the distribution is related to upstream but not identical
< luke-jr>
sipa: right; we can't stop people from patchign things out, but this provides a good solution otherwise
< sipa>
i'm not sure
< harding>
luke-jr: I'm pretty sure you can control auto-switching via the package install scripts, but my Debian packaging knowledge is like 15 years out of date.
< luke-jr>
laanwj: GUI can prompt too?
< luke-jr>
harding: even when the prior value is being removed? :p
< sipa>
i'm not sure
< harding>
luke-jr: I'm pretty sure you can control auto-switching via the package install scripts, but my Debian packaging knowledge is like 15 years out of date.
< luke-jr>
laanwj: GUI can prompt too?
< luke-jr>
harding: even when the prior value is being removed? :p
< earnestly>
sipa: Wouldn't bitcoin core ship with its own prefered defaults allowing users to override them?
< harding>
luke-jr: yeah, the different symlinks have priorities and you can set like -1 or something for never-auto-select.
< earnestly>
sipa: Wouldn't bitcoin core ship with its own prefered defaults allowing users to override them?
< harding>
luke-jr: yeah, the different symlinks have priorities and you can set like -1 or something for never-auto-select.
< harding>
luke-jr: also you could make the default /usr/bin/bitcoind a shell script that prompts you to opt-in to taproot.
< harding>
(Or whatever thing you as maintainer thinks needs opting in.)
< luke-jr>
anyway, there are multiple solutions; my question was mainly when we no longer should take extra steps like these
< harding>
luke-jr: also you could make the default /usr/bin/bitcoind a shell script that prompts you to opt-in to taproot.
< harding>
(Or whatever thing you as maintainer thinks needs opting in.)
< luke-jr>
anyway, there are multiple solutions; my question was mainly when we no longer should take extra steps like these
< laanwj>
harding: for user-facing tools that's fine, but that would go wrong if it's started from an (init) script
< laanwj>
you can usually assume bitcoind is used as part of some stack
< harding>
IMO, three months after we've honestly done our best to announce the change is enough time for people who want to know to learn about it.
< laanwj>
harding: for user-facing tools that's fine, but that would go wrong if it's started from an (init) script
< laanwj>
you can usually assume bitcoind is used as part of some stack
< harding>
IMO, three months after we've honestly done our best to announce the change is enough time for people who want to know to learn about it.
< sipa>
i think the message really isn't so much "warning, this has taproot, do you like that?", but it is "warning: the package maintainer you trust has power to make your system update to new consensus rules, you should be aware of that risk, and evaluate whether that's an acceptable way to use bitcoin"
< earnestly>
They can just remove that, there's no point playing this game
< sipa>
it can also say "in this case, it is following the bitcoin core upstream release which has the taproot update included"
< sipa>
but that's just the normal release notes/process
< sipa>
i think the message really isn't so much "warning, this has taproot, do you like that?", but it is "warning: the package maintainer you trust has power to make your system update to new consensus rules, you should be aware of that risk, and evaluate whether that's an acceptable way to use bitcoin"
< earnestly>
They can just remove that, there's no point playing this game
< sipa>
it can also say "in this case, it is following the bitcoin core upstream release which has the taproot update included"
< sipa>
but that's just the normal release notes/process
< harding>
laanwj: I think it would only go bad in the sense of the software not starting, and as long as it prints an informative error to the log, that's not too bad? If you're in a configuration where you're making major-version upgrades in an automated fashion, you have to be prepared for breakage no matter what (IMO).
< earnestly>
(I do like luke-jr's idea of having a softfork= option though, future?)
< harding>
laanwj: I think it would only go bad in the sense of the software not starting, and as long as it prints an informative error to the log, that's not too bad? If you're in a configuration where you're making major-version upgrades in an automated fashion, you have to be prepared for breakage no matter what (IMO).
< earnestly>
(I do like luke-jr's idea of having a softfork= option though, future?)
< ariard>
harding: if by "announce the change" you mean publicity around softfork locks in, 3 months sounds reasonable to me
< luke-jr>
the solutions I have right now just don't perform the update until the user explicitly agrees
< laanwj>
harding: this is not a major version update (0.21.0 to 0.21.1) ... but i agree all of this is manouvring around auto-updates just being a bad idea for bitcoin in the first place, and people who use it through a package manager sign up for that
< harding>
ariard: I was thinking 3 months from the BitcoinCore.org release announcement.
< ariard>
harding: if by "announce the change" you mean publicity around softfork locks in, 3 months sounds reasonable to me
< luke-jr>
the solutions I have right now just don't perform the update until the user explicitly agrees
< laanwj>
harding: this is not a major version update (0.21.0 to 0.21.1) ... but i agree all of this is manouvring around auto-updates just being a bad idea for bitcoin in the first place, and people who use it through a package manager sign up for that
< harding>
ariard: I was thinking 3 months from the BitcoinCore.org release announcement.
< luke-jr>
but people might never see that :/
< luke-jr>
but people might never see that :/
< laanwj>
we might want ot leave some time for the last topic
< harding>
luke-jr: yeah, it's not a perfect world, and I don't think we can fix that and still allow people to use the PPA.
< laanwj>
we might want ot leave some time for the last topic
< harding>
luke-jr: yeah, it's not a perfect world, and I don't think we can fix that and still allow people to use the PPA.
< luke-jr>
maybe I'll just leave the extra step installing in place until November
< luke-jr>
maybe I'll just leave the extra step installing in place until November
< luke-jr>
laanwj: I think the topic is done
< luke-jr>
laanwj: I think the topic is done
< laanwj>
#topic Training to rotate release responsibility (neha)
< core-meetingbot>
topic: Training to rotate release responsibility (neha)
< neha>
it would be good to train others to do releases. what do people think about laanwj mentoring people and eventually getting on a rotating schedule?
< laanwj>
#topic Training to rotate release responsibility (neha)
< core-meetingbot>
topic: Training to rotate release responsibility (neha)
< neha>
it would be good to train others to do releases. what do people think about laanwj mentoring people and eventually getting on a rotating schedule?
< michaelfolkson>
What are the responsibilities? Are there any that we wouldn't want to rotate?
< laanwj>
i think the best idea would be to have doc/release-process.md up to date so everything is in there, i've added some things already
< neha>
it could initially circulate among maintainers, for example. though it's not necessary to figure out a long-term plan right now. one short-term idea is for someone else to do the next minor release under laanwj's supervision
< laanwj>
but of course the best way to find out is to have someone else go through it
< luke-jr>
neha: it's not too hard tbh
< michaelfolkson>
What are the responsibilities? Are there any that we wouldn't want to rotate?
< laanwj>
i think the best idea would be to have doc/release-process.md up to date so everything is in there, i've added some things already
< neha>
it could initially circulate among maintainers, for example. though it's not necessary to figure out a long-term plan right now. one short-term idea is for someone else to do the next minor release under laanwj's supervision
< laanwj>
but of course the best way to find out is to have someone else go through it
< luke-jr>
neha: it's not too hard tbh
< luke-jr>
we have good docs
< neha>
fanquake has already volunteered, i believe
< laanwj>
yes, unfortunately he's couldn't be at this meeting
< amiti>
I think it's a great idea!
< luke-jr>
we have good docs
< neha>
fanquake has already volunteered, i believe
< laanwj>
yes, unfortunately he's couldn't be at this meeting
< amiti>
I think it's a great idea!
< michaelfolkson>
Any downsides? Presumably it would only rotate around maintainers?
< achow101>
wouldn't this require giving more people write access and upload access to bitcoincore.org?
< jonatack>
^ i would have thought that was a maintainer role (more or less by definition)
< laanwj>
probably makes sense to do it for a minor release first, 22.0 is going to be different in some ways so it will take some extra attention (also updating the release process where needed)
< michaelfolkson>
Any downsides? Presumably it would only rotate around maintainers?
< achow101>
wouldn't this require giving more people write access and upload access to bitcoincore.org?
< jonatack>
^ i would have thought that was a maintainer role (more or less by definition)
< laanwj>
probably makes sense to do it for a minor release first, 22.0 is going to be different in some ways so it will take some extra attention (also updating the release process where needed)
< sipa>
laanwj: agree, but also feel free to ask if you see places where help is useful
< luke-jr>
there's going to be one more 0.20.x before 22.0, right?
< achow101>
we could trial with 0.20.2
< laanwj>
achow101: sure, or they could do everything except the upload
< ariard>
maybe we could have more distribution mirrors instead of one big official one like bitcoincore.org
< sipa>
laanwj: agree, but also feel free to ask if you see places where help is useful
< luke-jr>
there's going to be one more 0.20.x before 22.0, right?
< achow101>
we could trial with 0.20.2
< laanwj>
achow101: sure, or they could do everything except the upload
< ariard>
maybe we could have more distribution mirrors instead of one big official one like bitcoincore.org
< luke-jr>
michaelfolkson: NACK treating maintainers special
< laanwj>
there was another idea for the longer run to have bitcoincore.org build the binaries itself (it's deterministic after all)
< luke-jr>
laanwj: not sure we gain anything from that?
< laanwj>
then the maintainer would only have to do a tag, and trigger it, i guess
< laanwj>
luke-jr: no one needs to upload binaries
< sipa>
laanwj: that's cool, but it's also a really infrequent thing; making sure that keeps working may be more work than doing it manually...
< luke-jr>
michaelfolkson: NACK treating maintainers special
< laanwj>
there was another idea for the longer run to have bitcoincore.org build the binaries itself (it's deterministic after all)
< luke-jr>
laanwj: not sure we gain anything from that?
< laanwj>
then the maintainer would only have to do a tag, and trigger it, i guess
< laanwj>
luke-jr: no one needs to upload binaries
< sipa>
laanwj: that's cool, but it's also a really infrequent thing; making sure that keeps working may be more work than doing it manually...
< harding>
The deterministic build idea is already how we handle the website content basically, so it's not too strange.
< achow101>
laanwj: still have upload sha256sums
< laanwj>
seems beter than giving multiple people write aceess to the /bin
< achow101>
*signed sha256sums
< laanwj>
achow101: depends on how we're going to do the signing
< luke-jr>
laanwj: just check that uploads have N signers
< luke-jr>
we would want that even if it built itself
< laanwj>
achow101: but yeah, having that happen on the website is a bad idea :)
< harding>
The deterministic build idea is already how we handle the website content basically, so it's not too strange.
< achow101>
laanwj: still have upload sha256sums
< laanwj>
seems beter than giving multiple people write aceess to the /bin
< achow101>
*signed sha256sums
< laanwj>
achow101: depends on how we're going to do the signing
< luke-jr>
laanwj: just check that uploads have N signers
< luke-jr>
we would want that even if it built itself
< laanwj>
achow101: but yeah, having that happen on the website is a bad idea :)
< harding>
If N people sign the torrent hash, then the website could download that directly.
< neha>
to separate the next minor release question from a longer-term strategy: it sounds like there is no immediate objection to fanquake doing the next minor release? when is 0.20.2?
< laanwj>
in any case the uploading is the least interesting part
< laanwj>
the rest of the release process is where more work is
< laanwj>
neha: sgtm
< luke-jr>
neha: it won't make sense to do it once we get to November
< harding>
If N people sign the torrent hash, then the website could download that directly.
< neha>
to separate the next minor release question from a longer-term strategy: it sounds like there is no immediate objection to fanquake doing the next minor release? when is 0.20.2?
< laanwj>
in any case the uploading is the least interesting part
< laanwj>
the rest of the release process is where more work is
< laanwj>
neha: sgtm
< luke-jr>
neha: it won't make sense to do it once we get to November
< luke-jr>
since it doesn't have Taproot
< achow101>
0.20.2 is ready to go except for release notes
< luke-jr>
and rc cycle
< laanwj>
yes
< sdaftuar>
practical thing that people will have to figure out is what key they are checking a signature from when they download the binary/sha256sums. would that be fanquake's in this scenario?
< luke-jr>
since it doesn't have Taproot
< achow101>
0.20.2 is ready to go except for release notes
< luke-jr>
and rc cycle
< laanwj>
yes
< sdaftuar>
practical thing that people will have to figure out is what key they are checking a signature from when they download the binary/sha256sums. would that be fanquake's in this scenario?
< luke-jr>
sdaftuar: we really should be moving to a setup where many of us sign those
< michaelfolkson>
It appears to work well for c-lightning but smaller project, smaller number of contributors and seems to rotate around the three major contributors mostly.
< achow101>
luke-jr: we already have 0.20.2rc2 since early june
< sdaftuar>
luke-jr: sure, but i assume we're not there yet?
< neha>
sdaftuar: i think part of the goal is to achieve fault tolerance, so ideally yes
< laanwj>
sdaftuar: it should be multi-signed i think
< luke-jr>
sdaftuar: it's just a matter of doing it
< laanwj>
sdaftuar: i think that's dongcarl's thing too, the same sha256sum is signed by every builder
< laanwj>
so the signatures can be concatenated
< luke-jr>
someone just has to copy/paste others' signatures into the file
< achow101>
luke-jr: probably not, but I expect that's normal for minor releases for old versions
< luke-jr>
sdaftuar: we really should be moving to a setup where many of us sign those
< michaelfolkson>
It appears to work well for c-lightning but smaller project, smaller number of contributors and seems to rotate around the three major contributors mostly.
< achow101>
luke-jr: we already have 0.20.2rc2 since early june
< sdaftuar>
luke-jr: sure, but i assume we're not there yet?
< neha>
sdaftuar: i think part of the goal is to achieve fault tolerance, so ideally yes
< laanwj>
sdaftuar: it should be multi-signed i think
< luke-jr>
sdaftuar: it's just a matter of doing it
< laanwj>
sdaftuar: i think that's dongcarl's thing too, the same sha256sum is signed by every builder
< laanwj>
so the signatures can be concatenated
< luke-jr>
someone just has to copy/paste others' signatures into the file
< achow101>
luke-jr: probably not, but I expect that's normal for minor releases for old versions
< sdaftuar>
laanwj: ah ok. just want to make sure we think to do whatever communication to the community is required for the change
< sipa>
i think there is a conflation here
< luke-jr>
so long as laanwj's signature is included, I expect it will be smooth
< laanwj>
well i can do the signing and upload for 0.20.2 no problem
< sipa>
guix attestations only prove that a particular source code corresponds to a certain binary
< sdaftuar>
laanwj: ah ok. just want to make sure we think to do whatever communication to the community is required for the change
< sipa>
i think there is a conflation here
< luke-jr>
so long as laanwj's signature is included, I expect it will be smooth
< laanwj>
well i can do the signing and upload for 0.20.2 no problem
< sipa>
guix attestations only prove that a particular source code corresponds to a certain binary
< sipa>
an auto-building site doesn't need that if it does a guix build itself
< sipa>
the question is what it should be building
< laanwj>
sipa: the idea is that people who download the binary have something to verify
< neha>
a longer term question (which doesn't need to be answered right now) is how we might get to a placed where the community could tolerate it if laanwj's sig wasn't there for whatever reason
< laanwj>
sipa: currently the sha256sums.asc is signed with my GPG key, someone else cannot do that
< sipa>
an auto-building site doesn't need that if it does a guix build itself
< sipa>
the question is what it should be building
< laanwj>
sipa: the idea is that people who download the binary have something to verify
< neha>
a longer term question (which doesn't need to be answered right now) is how we might get to a placed where the community could tolerate it if laanwj's sig wasn't there for whatever reason
< laanwj>
sipa: currently the sha256sums.asc is signed with my GPG key, someone else cannot do that
< laanwj>
so the idea is what to do instead for future releases
< sipa>
oh ok, we're not talking about using guix attestations to instruct the site what to publish?
< sipa>
just something similar
< laanwj>
so the idea is what to do instead for future releases
< sipa>
oh ok, we're not talking about using guix attestations to instruct the site what to publish?
< sipa>
just something similar
< harding>
We've had to update the expiration on laanwj's key before, which created some confusion but not much. On Bitcoin.org years ago, we saw that 99% of people who downloaded binaries didn't download the SHASUMs file, so most people aren't verifying in any case.
< luke-jr>
:|
< luke-jr>
harding: or perhaps verifying via gitian.sigs as ideal, but.. unlikely
< ariard>
harding: yes though maybe we can hope that the 1% doing it will serve as canary to alert the others ?
< sdaftuar>
harding: i think it would be terrible though if the few people who do verify, stop doing it because one time they tried and it didn't seem to work so they threw their hands up
< harding>
We've had to update the expiration on laanwj's key before, which created some confusion but not much. On Bitcoin.org years ago, we saw that 99% of people who downloaded binaries didn't download the SHASUMs file, so most people aren't verifying in any case.
< luke-jr>
:|
< luke-jr>
harding: or perhaps verifying via gitian.sigs as ideal, but.. unlikely
< ariard>
harding: yes though maybe we can hope that the 1% doing it will serve as canary to alert the others ?
< sdaftuar>
harding: i think it would be terrible though if the few people who do verify, stop doing it because one time they tried and it didn't seem to work so they threw their hands up
< laanwj>
but yes it's kind of a hassle that so many instructions have my gpg key hardcoded now for validation
< harding>
I think on BitcoinCore.org, we could just provide copies of laanwj's signed shasums next to some other signed shasums file for a few releases, and then transition away from laanwj's to the alternative.
< laanwj>
(well it's a separate distribution signing key, not my main gpg key, but still i don't feel comfortable giving it to others)
< luke-jr>
harding: the combined file would still verify with laanwj's key
< sipa>
of course
< harding>
The BitcoinCore.org download page has shasum verification instructinos on it, so we could mention any alternative.
< laanwj>
but yes it's kind of a hassle that so many instructions have my gpg key hardcoded now for validation
< harding>
I think on BitcoinCore.org, we could just provide copies of laanwj's signed shasums next to some other signed shasums file for a few releases, and then transition away from laanwj's to the alternative.
< laanwj>
(well it's a separate distribution signing key, not my main gpg key, but still i don't feel comfortable giving it to others)
< luke-jr>
harding: the combined file would still verify with laanwj's key
< sipa>
of course
< harding>
The BitcoinCore.org download page has shasum verification instructinos on it, so we could mention any alternative.
< laanwj>
harding: makes sense to me
< harding>
If there's a clear plan for the alternative, someone please ping me and I'll open a PR for the website making the changes.
< laanwj>
harding: makes sense to me
< harding>
If there's a clear plan for the alternative, someone please ping me and I'll open a PR for the website making the changes.
< michaelfolkson>
Having multiple bitcoincore.org equivalents and rotation of release signers sounds good (decentralization, reduce single points of failure) but could certainly introduce confusion for users
< michaelfolkson>
Having multiple bitcoincore.org equivalents and rotation of release signers sounds good (decentralization, reduce single points of failure) but could certainly introduce confusion for users
< gleb>
While people are still here I wanted to mention that #21515 is ready for review again, although it makes sense to review #21859 first if you feel like it.
< jonatack>
thinking out loud, of the non-maintainers, personally i could see achow101 who has been very involved in everything to do with signing and gitian sigs. good additional criteria might be number of years active in general and in contributing gitian signatures.
< gleb>
While people are still here I wanted to mention that #21515 is ready for review again, although it makes sense to review #21859 first if you feel like it.
< jonatack>
thinking out loud, of the non-maintainers, personally i could see achow101 who has been very involved in everything to do with signing and gitian sigs. good additional criteria might be number of years active in general and in contributing gitian signatures.
< jonatack>
quite happy to see laanwj continue as well.
< jonatack>
quite happy to see laanwj continue as well.
< michaelfolkson>
jonatack: Right. Rotating it to anyone who puts their hand up doesn't sound like a great idea
< michaelfolkson>
jonatack: Right. Rotating it to anyone who puts their hand up doesn't sound like a great idea
< michaelfolkson>
Someone like achow101 obviously would be zero problem
< ariard>
yeah let's take time to do this, especially if you put more responsiblity on users to browse through multiple vending websites
< michaelfolkson>
Someone like achow101 obviously would be zero problem
< ariard>
yeah let's take time to do this, especially if you put more responsiblity on users to browse through multiple vending websites
< laanwj>
multiple vending websites?
< laanwj>
multiple vending websites?
< jonatack>
gleb indeed, looking forward to diving into erlay soon after 22.0 is ready
< achow101>
I'd be willing to do releases
< jonatack>
gleb indeed, looking forward to diving into erlay soon after 22.0 is ready
< achow101>
I'd be willing to do releases
< laanwj>
achow101: great!
< laanwj>
achow101: great!
< ariard>
laanwj: mirros? ultimately with bitcoincore.org you might have domain name/ip law issues :/
< ariard>
laanwj: mirros? ultimately with bitcoincore.org you might have domain name/ip law issues :/
< laanwj>
ariard: i don't think that's part of the plan right now, there's bitcoincore.org and the torrent
< lightlike>
gleb: cool, I'll try to review soon! I read that you incorporated some changes (e.g. static q), is the BIP linked in the OP still in sync with the current code?
< laanwj>
ariard: i don't think that's part of the plan right now, there's bitcoincore.org and the torrent
< lightlike>
gleb: cool, I'll try to review soon! I read that you incorporated some changes (e.g. static q), is the BIP linked in the OP still in sync with the current code?
< laanwj>
i mean, sure, you could have mirrors, but that makes it much harder for users to know what to trust, what if one gets compromised, in any case that can be considered independently, it's orthogonal to rotating who does the release
< laanwj>
i mean, sure, you could have mirrors, but that makes it much harder for users to know what to trust, what if one gets compromised, in any case that can be considered independently, it's orthogonal to rotating who does the release
< laanwj>
jonatack: that's cool
< laanwj>
jonatack: that's cool
< ariard>
quick update on coredev making progress, we had a call with veterans yesterday :)
< ariard>
quick update on coredev making progress, we had a call with veterans yesterday :)
< laanwj>
ariard: thanks!
< laanwj>
ariard: thanks!
< jonatack>
laanwj: yes and as PoW it's not gameable, can't go faster than the releases :D
< jonatack>
laanwj: yes and as PoW it's not gameable, can't go faster than the releases :D
< jonatack>
ariard: it was great seeing everyone, some for the first time. i was quite distracted and don't remember who is now supposed to do what, so will look out for your recap
< jonatack>
ariard: it was great seeing everyone, some for the first time. i was quite distracted and don't remember who is now supposed to do what, so will look out for your recap
< gleb>
lightlike: BIP is low-key in sync. The new changes technically don't violate the old BIP, but it might have some little references to meaningless (now) stuff
< gleb>
lightlike: BIP is low-key in sync. The new changes technically don't violate the old BIP, but it might have some little references to meaningless (now) stuff
< gleb>
I will soon create some FAQ on protocol design choices and deviations from the original proposal.
< gleb>
I will soon create some FAQ on protocol design choices and deviations from the original proposal.