[bug#46266] gnu: Update bitcoin-core to 0.21.0

In addition to updating, I made as well, separate `bitcoin-core-0.20` and `bitcoin-core-0.21` packages.
Due to RPC changes, it is possible that other programs compatible with older `bitcoin-core` version is not compatible with newer version.
Thus, an `operating-system` declaration, may need to pin a specific major version.

Hoping for your kind review and acceptance of this patch.

Tested with `guix build bitcoin-core`.
Is there more testing I need to do before this is accepted?

Regards,
ZmnSCPxj


From 319a66d931f2191ab91037e0ba9da1c2b969229d Mon Sep 17 00:00:00 2001
From: ZmnSCPxj <ZmnSCPxj@protonmail.com>
Date: Wed, 3 Feb 2021 00:51:07 +0000
Subject: [PATCH] gnu: Update bitcoin-core to 0.21.0

* gnu/packages/finance.scm (make-bitcoin-core): New procedure, moved from ...
(bitcoin-core): ... here. Update to 0.21.0.
(bitcoin-core-0.20): New variable.
(bitcoin-core-0.21): New variable.
---
 gnu/packages/finance.scm | 16 ++++++++++++----
 1 file changed, 12 insertions(+), 4 deletions(-)

--
2.30.0

Hi ZmnSCPxj,

Sorry for the delay in getting back to you.

guix-patches--- via <guix-patches@gnu.org> writes:

> In addition to updating, I made as well, separate `bitcoin-core-0.20`
> and `bitcoin-core-0.21` packages.  Due to RPC changes, it is possible
> that other programs compatible with older `bitcoin-core` version is
> not compatible with newer version.  Thus, an `operating-system`
> declaration, may need to pin a specific major version.

I think it's OK to keep older versions if that's important, but it would
be good to specifically note why specific older versions are useful to
keep. I'm saying that because it's useful to know when an older version
can be removed. So, for 0.20 are there incompatibilities that you're
aware of?

The second thing is, I wouldn't immediately jump to the
(make-... pattern, and I would instead use package inheritance. See the
ruby packages for example [1].

1: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ruby.scm#n95

Package inheritance makes it simpler to make changes to individual
versions, and avoids the complexity of introducing a procedure.

Does that all make sense?

Thanks,

Chris

Good morning Christopher,

> Hi ZmnSCPxj,
>
> Sorry for the delay in getting back to you.
>
> guix-patches--- via guix-patches@gnu.org writes:
>
> > In addition to updating, I made as well, separate `bitcoin-core-0.20`
> > and `bitcoin-core-0.21` packages. Due to RPC changes, it is possible
> > that other programs compatible with older `bitcoin-core` version is
> > not compatible with newer version. Thus, an `operating-system`
> > declaration, may need to pin a specific major version.
>
> I think it's OK to keep older versions if that's important, but it would
> be good to specifically note why specific older versions are useful to
> keep. I'm saying that because it's useful to know when an older version
> can be removed. So, for 0.20 are there incompatibilities that you're
> aware of?

Previously between 0.18.x to 0.19.0.1, the RPC command `sendrawtransaction` changed its second parameter from a boolean `allowhighfees` to a numeric `maxfeerate`.
Thus, an automated update from 0.18.x to 0.19.0.1 would have lead to problems in dependent software that used the older `allowhighfees` parameter.
So I think it is a good policy in general to provide major versions for Bitcoin Core at least, to avoid such issues in the future.

Another is that Bitcoin Core itself has a policy of not pushing updates; the idea is that the user should consciously elect to update to a newer version, because there may be consensus changes that the user does not agree with.
Using an unanchored `bitcoin-core` would break this policy and make Guix provide always the latest available.
Of course, it is possible to use inferiors and so on.

Finally, 0.21.1 is intended to include consensus policy changes on the activation of the new Taproot feature.
Whatever is deployed in 0.21.1 may or may not be agreed to by the specific user, thus `bitcoin-core` should ideally not be updated automatically to 0.21.1.

Bitcoin Core makes an effort to maintain older major versions in order to allow users to avoid particular changes in later major versions they do not agree with.

> The second thing is, I wouldn't immediately jump to the
> (make-... pattern, and I would instead use package inheritance. See the
> ruby packages for example [1].
>
> 1: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ruby.scm#n95
>
> Package inheritance makes it simpler to make changes to individual
> versions, and avoids the complexity of introducing a procedure.
>
> Does that all make sense?

Okay, thank you.

Regards,
ZmnSCPxj

ZmnSCPxj <ZmnSCPxj@protonmail.com> writes:

> Good morning Christopher,
>
>> Hi ZmnSCPxj,
>>
>> Sorry for the delay in getting back to you.
>>
>> guix-patches--- via guix-patches@gnu.org writes:
>>
>> > In addition to updating, I made as well, separate `bitcoin-core-0.20`
>> > and `bitcoin-core-0.21` packages. Due to RPC changes, it is possible
>> > that other programs compatible with older `bitcoin-core` version is
>> > not compatible with newer version. Thus, an `operating-system`
>> > declaration, may need to pin a specific major version.
>>
>> I think it's OK to keep older versions if that's important, but it would
>> be good to specifically note why specific older versions are useful to
>> keep. I'm saying that because it's useful to know when an older version
>> can be removed. So, for 0.20 are there incompatibilities that you're
>> aware of?
>
> Previously between 0.18.x to 0.19.0.1, the RPC command
> `sendrawtransaction` changed its second parameter from a boolean
> `allowhighfees` to a numeric `maxfeerate`.  Thus, an automated update
> from 0.18.x to 0.19.0.1 would have lead to problems in dependent
> software that used the older `allowhighfees` parameter.  So I think it
> is a good policy in general to provide major versions for Bitcoin Core
> at least, to avoid such issues in the future.
>
> Another is that Bitcoin Core itself has a policy of not pushing
> updates; the idea is that the user should consciously elect to update
> to a newer version, because there may be consensus changes that the
> user does not agree with.  Using an unanchored `bitcoin-core` would
> break this policy and make Guix provide always the latest available.
> Of course, it is possible to use inferiors and so on.
>
> Finally, 0.21.1 is intended to include consensus policy changes on the
> activation of the new Taproot feature.  Whatever is deployed in 0.21.1
> may or may not be agreed to by the specific user, thus `bitcoin-core`
> should ideally not be updated automatically to 0.21.1.
>
> Bitcoin Core makes an effort to maintain older major versions in order
> to allow users to avoid particular changes in later major versions
> they do not agree with.

Ok, I've found https://bitcoincore.org/en/lifecycle/#schedule now which
makes me feel a little better at keeping older versions around, as there
are dates from the upstream project which help signal when removing
versions from Guix might be good.

>> The second thing is, I wouldn't immediately jump to the
>> (make-... pattern, and I would instead use package inheritance. See the
>> ruby packages for example [1].
>>
>> 1: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ruby.scm#n95
>>
>> Package inheritance makes it simpler to make changes to individual
>> versions, and avoids the complexity of introducing a procedure.
>>
>> Does that all make sense?
>
> Okay, thank you.

On this point, are you OK with sending an updated patch?

Thanks,

Chris

Good morning Christopher,

> ZmnSCPxj ZmnSCPxj@protonmail.com writes:
>
> > Good morning Christopher,
> >
> > > Hi ZmnSCPxj,
> > > Sorry for the delay in getting back to you.
> > > guix-patches--- via guix-patches@gnu.org writes:
> > >
> > > > In addition to updating, I made as well, separate `bitcoin-core-0.20`
> > > > and `bitcoin-core-0.21` packages. Due to RPC changes, it is possible
> > > > that other programs compatible with older `bitcoin-core` version is
> > > > not compatible with newer version. Thus, an `operating-system`
> > > > declaration, may need to pin a specific major version.
> > >
> > > I think it's OK to keep older versions if that's important, but it would
> > > be good to specifically note why specific older versions are useful to
> > > keep. I'm saying that because it's useful to know when an older version
> > > can be removed. So, for 0.20 are there incompatibilities that you're
> > > aware of?
> >
> > Previously between 0.18.x to 0.19.0.1, the RPC command
> > `sendrawtransaction` changed its second parameter from a boolean
> > `allowhighfees` to a numeric `maxfeerate`. Thus, an automated update
> > from 0.18.x to 0.19.0.1 would have lead to problems in dependent
> > software that used the older `allowhighfees` parameter. So I think it
> > is a good policy in general to provide major versions for Bitcoin Core
> > at least, to avoid such issues in the future.
> > Another is that Bitcoin Core itself has a policy of not pushing
> > updates; the idea is that the user should consciously elect to update
> > to a newer version, because there may be consensus changes that the
> > user does not agree with. Using an unanchored `bitcoin-core` would
> > break this policy and make Guix provide always the latest available.
> > Of course, it is possible to use inferiors and so on.
> > Finally, 0.21.1 is intended to include consensus policy changes on the
> > activation of the new Taproot feature. Whatever is deployed in 0.21.1
> > may or may not be agreed to by the specific user, thus `bitcoin-core`
> > should ideally not be updated automatically to 0.21.1.
> > Bitcoin Core makes an effort to maintain older major versions in order
> > to allow users to avoid particular changes in later major versions
> > they do not agree with.
>
> Ok, I've foundhttps://bitcoincore.org/en/lifecycle/#schedule now which
> makes me feel a little better at keeping older versions around, as there
> are dates from the upstream project which help signal when removing
> versions from Guix might be good.

Okay, I will add a comment linking to this as well in the patch.

>
> > > The second thing is, I wouldn't immediately jump to the
> > > (make-... pattern, and I would instead use package inheritance. See the
> > > ruby packages for example [1].
> > > 1: https://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/ruby.scm#n95
> > > Package inheritance makes it simpler to make changes to individual
> > > versions, and avoids the complexity of introducing a procedure.
> > > Does that all make sense?
> >
> > Okay, thank you.
>
> On this point, are you OK with sending an updated patch?

Yes, please give me a few days or weeks.

Regards,
ZmnSCPxj