Mailing List Archive: Require opt-in for bitcoin upgrade?

Require opt-in for bitcoin upgrade?

Jul 10, 2021, 8:42 AM

Post #1 of 5 (47 views)

Gentoo currently has a number of packages required to run a bitcoin node
in its tree, including:
* net-libs/libbitcoinconsensus
* net-p2p/bitcoin-qt
* net-p2p/bitcoind

In version 0.21.1, bitcoin included a consensus algorithm changed call
taproot. There is no configuration opt-in with this change; bitcoin <
0.21.1 does not include taproot, bitcoin >= 0.21.1 does include taproot.

A PR [1] was created the bitcoin packaging proxy maintainer (Like
Dash-Jr, CC'ed) for the bitcoin 0.21.1 version bump. In that PR, Luke
insists that users must explicitly opt-in to the bitcoin 0.21.1 upgrade
because of the taproot consensus algorithm change. I encourage
interested parties to read the conversation in that PR to get the full
context.

* This is a minor version bump (assuming semver, this is the "patch"
level version change in bitcoin), indicating that upstream does not
consider this to be a major/breaking change.
* Upstream does not have a mechanism for notifying users or requiring
them to opt-in to this change
* Upstream does not have a mechanism to opt out of this change. The
users only option is to develop their own fork of the bitcoin software
or never upgrade the package if they want to avoid taproot.
* Taproot was locked by miners, so the network will be upgrading [2]

Therefore, I have a few questions for the fellow Gentoo developers:
1) Should we require users to explicitly opt-in to this upgrade beyond
the usual?
2) If so, how do we do that? I have been unable to find any
documentation or examples of existing packages that require explicit
upgrade opt-in. A REQUIRED_USE or a LICENSE [3] were suggested as well
as PROPERTIES="interactive" [4], but such approaches seem like
unintended/unconventional abuses of those settings as well as annoying
to the user.

My suggested approach was to notifying the user of the change in the
pkg_pretend phase [5] so they're aware before they actually upgrade;
however, the proxy maintainer disagreed and force a revert. [6]

Thank you for your consideration and assistance with this issue,
~Craig

[1] https://github.com/gentoo/gentoo/pull/21490
[2] https://taproot.watch/
[3] https://github.com/gentoo/gentoo/pull/21490#discussion_r663201705
[4] https://github.com/gentoo/gentoo/pull/21490#issuecomment-877542346
[5]
https://github.com/gentoo/gentoo/commit/e62b85aae5a2dd70ff120ebc284bf6d461e34b88#diff-e5afbd0e114be010e271302d0807aba076083d0e623ddd611f7e80b4b02a1c82R91
[6] https://github.com/gentoo/gentoo/pull/21490#issuecomment-877531697

Re: Require opt-in for bitcoin upgrade? [ In reply to ]

williamh at gentoo

Jul 10, 2021, 11:50 AM

Post #2 of 5 (47 views)

Permalink

On Sat, Jul 10, 2021 at 11:42:28AM -0400, Craig Andrews wrote:
> Gentoo currently has a number of packages required to run a bitcoin node
> in its tree, including:
> * net-libs/libbitcoinconsensus
> * net-p2p/bitcoin-qt
> * net-p2p/bitcoind
>
> In version 0.21.1, bitcoin included a consensus algorithm changed call
> taproot. There is no configuration opt-in with this change; bitcoin <
> 0.21.1 does not include taproot, bitcoin >= 0.21.1 does include taproot.
>
> A PR [1] was created the bitcoin packaging proxy maintainer (Like
> Dash-Jr, CC'ed) for the bitcoin 0.21.1 version bump. In that PR, Luke
> insists that users must explicitly opt-in to the bitcoin 0.21.1 upgrade
> because of the taproot consensus algorithm change. I encourage
> interested parties to read the conversation in that PR to get the full
> context.
>
> * This is a minor version bump (assuming semver, this is the "patch"
> level version change in bitcoin), indicating that upstream does not
> consider this to be a major/breaking change.
> * Upstream does not have a mechanism for notifying users or requiring
> them to opt-in to this change
> * Upstream does not have a mechanism to opt out of this change. The
> users only option is to develop their own fork of the bitcoin software
> or never upgrade the package if they want to avoid taproot.
> * Taproot was locked by miners, so the network will be upgrading [2]

I suggest the following:

1) a newsitem explaining this issue.
2) at the same time, package.mask the newer version temporarily and keep
the older version in the tree.
3) Once the network is upgraded, unmask the newer version and drop the
older version. If people want the older version at that point and write
a fork, you'll have to rename itt.

>
> Therefore, I have a few questions for the fellow Gentoo developers:
> 1) Should we require users to explicitly opt-in to this upgrade beyond
> the usual?
> 2) If so, how do we do that? I have been unable to find any
> documentation or examples of existing packages that require explicit
> upgrade opt-in. A REQUIRED_USE or a LICENSE [3] were suggested as well
> as PROPERTIES="interactive" [4], but such approaches seem like
> unintended/unconventional abuses of those settings as well as annoying
> to the user.

If you do, I think you can do it the way I suggested without adding
extra things to the ebuild.

>
> My suggested approach was to notifying the user of the change in the
> pkg_pretend phase [5] so they're aware before they actually upgrade;
> however, the proxy maintainer disagreed and force a revert. [6]

As far as I know proxy maintainers can't force anything; they defer to
developers because we are the ones who are more familiar with the way
the tree works.

That being said, I still think the cleaner solution is to use
a temporary package.mask along with a newsitem.

Thanks,

William

Re: Require opt-in for bitcoin upgrade? [ In reply to ]

williamh at gentoo

Jul 10, 2021, 1:14 PM

Post #3 of 5 (47 views)

Permalink

Hey All,

I'm responding again because I saw that I left Luke off of my original
message and I cleaned up my steps a bit.

We talked about this on the irc channel, and several of us feel that you
don't need anything special in the ebuild at all, you can do this via
package.mask and a newsitem.

I suggest the following assuming that the older version will stop
working when the network is fully upgraded.

- Publish a newsitem explaining this issue.
- After the newsitem is published, Commit the newer version under
package.mask with the mask message being an explanation of the issue.
- at this point, if people want to opt in, they can unmask the newer
version and add it to package.accept_keywords.
- Once the network is upgraded, unmask the newer version (and you
might have to fast stable if the older version doesn't work).
- If I understand correctly, at this point, opting in isn't
optional since the network is upgraded, so if people don't want
to use the new algo they can't use bitcoin.

That will give everyone time to see the newsitem before the newer version hits.

It seems like this is the best you can do since upstream is doing a hard
switchover to the new algo.

William

Re: Require opt-in for bitcoin upgrade? [ In reply to ]

williamh at gentoo

Jul 10, 2021, 2:18 PM

Post #4 of 5 (47 views)

Permalink

To update everyone involved in this, please read my last comment on the
pr. Basically, this can be treated like a test version by adding it to
package.mask with an appropriate message then maybe publishing a
newsitem if the maintainer wants it to be known by other users.

William

Re: Require opt-in for bitcoin upgrade? [ In reply to ]

candrews at gentoo

Jul 10, 2021, 3:17 PM

Post #5 of 5 (47 views)

Permalink

On 2021-07-10 17:18, William Hubbs wrote:
> To update everyone involved in this, please read my last comment on the
> pr. Basically, this can be treated like a test version by adding it to
> package.mask with an appropriate message then maybe publishing a
> newsitem if the maintainer wants it to be known by other users.
>
> William

IMHO, a news item is a bit much... I feel that the package.mask message
is sufficient. Huge thank you to all participants for discussing the
topic and coming up with the package.mask idea!

Here's a PR which is hopefully agreeable:
https://github.com/gentoo/gentoo/pull/21587

~Craig

Mailing List Archive

Attached Files:

Attached Files:

Attached Files:

Attached Files: