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

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

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