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

[Christopher Baines <mail@cbaines.net>]

[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]


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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 987 bytes --]