New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Bitcoin 0.21.1 #21490
Bitcoin 0.21.1 #21490
Conversation
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
Signed-off-by: Luke Dashjr <luke-jr+git@utopios.org>
Pull Request assignmentSubmitter: @luke-jr dev-util/bitcoin-tx: @luke-jr, @gentoo/proxy-maint Linked bugsNo bugs to link found. If your pull request references any of the Gentoo bug reports, please add appropriate GLEP 66 tags to the commit message and request reassignment. In order to force reassignment and/or bug reference scan, please append Docs: Code of Conduct ● Copyright policy (expl.) ● Devmanual ● GitHub PRs ● Proxy-maint guide |
taproot locked - so why do we need to the user to do anything? My understanding is that the ship has sailed, taproot is happening, so to continue being a bitcoin node as of November taproot must be supported. |
Pull request CI reportReport generated at: 2021-06-30 20:49 UTC New issues caused by PR: There are existing issues already. Please look into the report to make sure none of them affect the packages in question: |
Bitcoin is not a centralised network. The signalling only indicates miners are prepared early, but the actual protocol change depends on the community's acceptance. |
But the community has accepted - taproot is locked: https://taproot.watch/ |
Miners are not the community. Signalling shouldn't even begin until the community has decided, but that observation is not a reason to change rules on people without their own active consent. (This is one reason why we have intentionally never included any auto-upgrade in the software itself.) Perhaps an argument can be made to forego the consent, but "miners say so" certainly is not that. |
How about an Also, can you please fix the issues reported by CI? |
" | ||
RDEPEND="${DEPEND}" | ||
BDEPEND=" | ||
>=sys-devel/autoconf-2.69 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this BDEPEND is needed at all, but if it is, there are eclass variables for this from autotools.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
???
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
???
autoconf BDEPEND for autotools.eclass is already handled by the eclass (by default), so you don't really need this.
From autotools.eclass:
# @ECLASS-VARIABLE: AUTOTOOLS_AUTO_DEPEND
# @PRE_INHERIT
# @DESCRIPTION:
# Set to 'no' to disable automatically adding to DEPEND. This lets
# ebuilds form conditional depends by using ${AUTOTOOLS_DEPEND} in
# their own DEPEND string.
: ${AUTOTOOLS_AUTO_DEPEND:=yes}
if [[ ${AUTOTOOLS_AUTO_DEPEND} != "no" ]] ; then
case ${EAPI} in
5|6) DEPEND=${AUTOTOOLS_DEPEND} ;;
7) BDEPEND=${AUTOTOOLS_DEPEND} ;;
>dev-libs/libsecp256k1-0.1_pre20200911:=[recovery,schnorr] | ||
" | ||
RDEPEND="${DEPEND}" | ||
BDEPEND=" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same BDEPEND comments.
ewarn "before November. (You must make a decision either way - simply not upgrading" | ||
ewarn "is insecure in all scenarios.)" | ||
ewarn "To learn more, see https://bitcointaproot.cc" | ||
if ! use bitcoin_protocol_taproot; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think this is the right approach (but I do agree with ensuring users are informed):
-
You mentioned upstream doesn't do auto-upgrades, but does it warn at all on installation/upgrade 'manually'?
-
(Additionally, I don't really want to go beyond what upstream did or didn't do. Gentoo isn't really the place to lobby or impose what you wish they'd done upstream. Not saying that's what happening here, I just want to be careful of the line, because I know it's tempting sometimes.)
-
I'd much prefer a news item for people who have this set of packages installed or a pkg_postinst message. Note that in general, we assume users read elogs because they often
contain important information. (People won't be running the new binary until they explicitly restart e.g. bitcoind anyway). -
In terms of reasons against pkg_pretend dying, the main issue is that it hurts automation (the package manager can only detect failure after dependency resolution and so on), and we already have REQUIRED_USE for things like this.
A REQUIRED_USE setting which isn't satisfied by default would trigger a QA warning which we could possibly waive, but I'm still more inclined to go for the news item or pkg_postinst here. Those are the two official methods for letting users know about upcoming changes.
What do you reckon?
(cc @candrews)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FWIW, it appears to me that this is nothing that users should be notified via gentoo mechanisms. I know that this is probably a delicate topic for some (as it's bitcoin). But ultimately a use flag that does nothing besides preventing the package from being emerged if not set, is not something we should introduce nor encourage in ::gentoo.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Upon reflection, I agree with @Flowdalic. Users should be subscribed to upstream's news notifications (mailing lists, whatever). We should really only be using Gentoo news items (and arguably pkg_postinst) for critical breaking changes.
This kind of thing is quite natural for Bitcoin. I think we should therefore be doing a pkg_postinst message at most.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a critical breaking change, one that can potentially cost the user their life savings.
I brought the subject up at today's Bitcoin development meeting, and there didn't seem to be much agreement for foregoing explicitly user interaction.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then shouldn't upstream be doing something about it? Make bitcoind or whatever scream if a config option hasn't been set? Gentoo, being downstream, isn't the place to lobby for things you wish were done upstream?
I also don't see anything on https://bitcoin.org/en/download mentioning this. Can you walk me through what happens when I run Bitcoin Core on say, Windows, and there's an update available?
There still is user interaction. People should not be doing unattended upgrades because people have to read pkg_postinst messages anyway (see e.g. PAM upgrades, OpenSSH, ...). If they are, they're going to have other problems.
Let's go a bit further too, I don't want to be the only people doing this.. what's happening with Debian/Ubuntu .debs? Fedora/* RPMs?
Separately: I'm wondering why Bitcoin isn't available for download in the UK. I assume something to do with the Wright case. Should we be restricting mirroring in Gentoo? Or fetch restricting?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Then shouldn't upstream be doing something about it?
We don't have any automatic updating upstream, intentionally.
Make bitcoind or whatever scream if a config option hasn't been set?
That was also discussed, but it won't be here for Taproot.
I also don't see anything on https://bitcoin.org/en/download mentioning this.
It probably should. https://bitcoincore.org/ is pretty explicit about it.
Can you walk me through what happens when I run Bitcoin Core on say, Windows, and there's an update available?
Nothing. You have to manually seek it out and choose to upgrade.
People should not be doing unattended upgrades because people have to read pkg_postinst messages anyway (see e.g. PAM upgrades, OpenSSH, ...).
Telling the user after the fact is kinda too late?
Let's go a bit further too, I don't want to be the only people doing this.. what's happening with Debian/Ubuntu .debs? Fedora/* RPMs?
We asked them not to package at all. I maintain the PPA, and plan to do something similar (debconf has a way to insist on explicit user interaction)
Separately: I'm wondering why Bitcoin isn't available for download in the UK.
It is. What gave you the impression it isn't?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I brought the subject up at today's Bitcoin development meeting, and there didn't seem to be much agreement for foregoing explicitly user interaction.
I read said meeting and agree that this is caused by using bitcoin via a package manager that performs auto updates and by bitcoin core enabling new consensus rules on new updates by default. I really appreciate your effort here.
That said, I think we best we can do is educate Gentoo users about this situation, that every net-p2p/bitcoind update potentially comes with new defaults that they need to research about. But if ! use new-consensus-rule; then die; fi
seems excessive, especially since it may aborts an upgrade process (if --keep-going
is not enabled).
I am currently leaning towards a short warning message on every update, but in case of taproot, a news item seems also sensible. Other means could be discussed as well, like a guard file, that if not existent prevents bitcoind from starting.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
REQUIRED_USE
seems to solve the problem of aborting other updates.
Another possibility is an additional dummy LICENSE which isn't part of the default-accepted lists?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
People should not be doing unattended upgrades because people have to read pkg_postinst messages anyway (see e.g. PAM upgrades, OpenSSH, ...).
Telling the user after the fact is kinda too late?
But it's not after the fact. Users shouldn't be doing unattended upgrades. They will see the log and downgrade if necessary?
Separately: I'm wondering why Bitcoin isn't available for download in the UK.
It is. What gave you the impression it isn't?
https://bitcoin.org/en/download says "(This software is presently not available for download in the UK, and download links will not work if you are located within the UK.)" and the links (as it says) don't work.
I'm okay with a one-off news item as @Flowdalic suggests to indicate to users they should always check on major upgrades and we'll do an elog too. In future, just an elog. How about that?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
But it's not after the fact. Users shouldn't be doing unattended upgrades. They will see the log and downgrade if necessary?
It is after the fact, by definition. PAM/OpenSSH notices are things to do after the update, not reasons one might not consent to the upgrade.
https://bitcoin.org/en/download says "(This software is presently not available for download in the UK, and download links will not work if you are located within the UK.)" and the links (as it says) don't work.
This is bitcoin.org's owner playing political games. There isn't any actual problem.
I'm okay with a one-off news item as @Flowdalic suggests to indicate to users they should always check on major upgrades and we'll do an elog too. In future, just an elog. How about that?
That doesn't ensure the user has consented. This also isn't generally recognisable as a major upgrade (0.21.0 -> 0.21.1).
ewarn "before November. (You must make a decision either way - simply not upgrading" | ||
ewarn "is insecure in all scenarios.)" | ||
ewarn "To learn more, see https://bitcointaproot.cc" | ||
if ! use bitcoin_protocol_taproot; then |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I brought the subject up at today's Bitcoin development meeting, and there didn't seem to be much agreement for foregoing explicitly user interaction.
I read said meeting and agree that this is caused by using bitcoin via a package manager that performs auto updates and by bitcoin core enabling new consensus rules on new updates by default. I really appreciate your effort here.
That said, I think we best we can do is educate Gentoo users about this situation, that every net-p2p/bitcoind update potentially comes with new defaults that they need to research about. But if ! use new-consensus-rule; then die; fi
seems excessive, especially since it may aborts an upgrade process (if --keep-going
is not enabled).
I am currently leaning towards a short warning message on every update, but in case of taproot, a news item seems also sensible. Other means could be discussed as well, like a guard file, that if not existent prevents bitcoind from starting.
ewarn "effective, and if enforced inconsistently within the community may compromise" | ||
ewarn "your security or others! If you do not know what you are doing, learn more" | ||
ewarn "before November. (You must make a decision either way - simply not upgrading" | ||
ewarn "is insecure in all scenarios.)" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That kinda implies that it is possible to upgrade without using taproot. But if so, why do we have to die
if taproot is not enabled?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If people actually reject Taproot, they can indeed reject it. But doing so would involve writing code, getting others to adopt it, etc - it's not something we can just support as-is today until someone puts the work into it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am currently leaning towards a short warning message on every update, but in case of taproot, a news item seems also sensible. Other means could be discussed as well, like a guard file, that if not existent prevents bitcoind from starting.
I'm on board with a log message and/or news item, but I won't merge with the blocking use flag approach.
I'd really like to get this Bitcoin version bump in soon...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In future, I'd really prefer it if a solution was figured out upstream and we didn't need to have these debates. But yeah, agreed. See #21490 (comment).
I'm going to merge this PR with a couple changes:
|
Please revert. That is unethical and I did NOT sign-off on it. |
I had to revert it due to @luke-jr reaching out and claiming statement above. Please reach consensus of some kind. |
Thanks. I'm not sure what the rush is - this upgrade is not important until November. We do have 4 months to find a clean and ethical solution (though hopefully it won't take nearly that long). What concerns are there with using REQUIRED_USE or a dummy LICENSE? |
we do have
https://dev.gentoo.org/~zmedico/portage/doc/man/emerge.1.html |
but idk if ^ is not deprecated. ask QA in doubt. |
Interesting. From what I'm reading, the purpose of the PROPERTIES value is to mask the package during unattended upgrades, so it sounds okay. We could maybe also include a suggestion to touch a file in /etc/bitcoin/ if one wants to accept non-interactively? |
PROPERTIES=interactive signals portage that ebuild may ask for user input, afaik. |
Emailed the gentoo-dev list requested further input: https://archives.gentoo.org/gentoo-dev/message/b4e73ddcb2409e71c66ad314d51de0f7 |
A few corrections and clarifications to that email (inline): On Saturday 10 July 2021 15:42:28 Craig Andrews wrote:
It does not indicate that. Everyone else upstream that has commented on the matter, agrees user opt-in must be maintained at this time (probably until activation in November). The reason it is a patch-level version change, is that
We intentionally do not support automatic upgrades to avoid the issue, and ensure opt-in. Users explicitly opt-in when they go to our website, see the release (explicitly mentioning the addition of Taproot), and choose to actively download and install it. What Gentoo needs here, is an equivalent.
Assuming other users do upgrade, non-upgrading is not a viable way to reject Taproot. Only creating a fork will do the job. If users in general, however, reject Taproot, Bitcoin Core (and others) will have no choice but to back out the changes for Taproot, in which case there would be a 0.21.2+ without it.
Miners do not determine Bitcoin's consensus rules at all.
Anything other than this, at this time, would be unethical. This isn't just a policy. This is consensus rules the user is imposing on every other user. This has direct real-world financial risk. There may (or may not) be an argument for legal liability if such a change is made without user consent. Doing so also compromises the security model of the Bitcoin network, which is based on the assumption that each user makes the decision for himself. |
@luke-jr I sent a couple of emails on this, but after reading here, i definitely think the best answer for this is to not have anything unusual in the ebuild, but to commit the bump under package.mask along with a mask message explaining the issue. If you want a wider announcement, you can publish a newsitem after the package is committed behind a mask. |
@williamh That sounds acceptable, though maybe a bit stronger than would be ideal. Reading your email, I want to note that:
I don't think these change the conclusions you reached, however. Shall I go ahead and make the changes proposed for the package.mask solution? |
It seems we're both working on this at the same time :) Here's a PR with has package.mask: #21587 Hopefully everyone finds it agreeable. Thanks to all for your assistance with this issue. |
Closing this in favour of #21587 |
Other than the typical bump, note this release changes the Bitcoin consensus rules. It is important that users explicitly opt-in to consensus rule changes. To accomplish this, a new
bitcoin_protocol_taproot
USE flag is added, unset by default, that must be set by users to install (pkg_pretend
willdie
if it is unset). Not sure if this is the best approach or something else is desirable.