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

[ZmnSCPxj via Guix-patches via <guix-patches@gnu.org>]

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