Would you accept a PR for bitcoinjs-lib v7 migration (with @bitcoinerlab updates)?

[landabaso]

I was considering submitting a PR related to this library's dependency on @bitcoinerlab/descriptors.

app-bitcoin-new uses @bitcoinerlab/descriptors to validate addresses with an implementation different from the device's one and the new @bitcoinerlab/descriptors v3 branch now supports minitapscript as well (so the validation could be extended).

However, @bitcoinerlab/descriptors was also upgraded to align with the newer bitcoinjs-lib v7 branch, which has been available for about 5 months now (and the RC for over a year).

The new bitcoinjs-lib introduces some important changes, including:

• Uint8Array instead of Buffer
• bigint for satoshi amounts instead of number

Because of that, I think it would make more sense to upgrade @bitcoinerlab/descriptors together with bitcoinjs-lib.

I realize this would be a breaking change, especially because of the typing changes and the major bitcoinjs-lib version upgrade (which downstream apps may also depend on), so it would impact several parts of Ledger's codebase and other parts of your ecosystem.
I'd rather check first in case you are planning a different refactor or if downstream apps are not in a position to adopt this yet.

Before I give this PR a try, would you be open to this kind of update?

Let me know what you think, @bigspider.

[bigspider]

Hi @landabaso!

I'm always for upgrading, and if a breaking change is indeed needed, we can upgrade the version number accordingly, in order to make it clear.

However, not sure a breaking change is needed in the interface of the this library? I think it could always be made to accept Buffer as today (or Buffer | Uint8Array if desirable) on the prototype, and then convert internally to Uint8Array before calling upstream libraries.

[landabaso]

Correct! This can be done as a non-breaking change at the library level.

My concern was the bitcoinjs-lib dependency upgrade, since downstream apps might end up shipping two versions internally. But I agree it makes sense to do this step by step, so I'll take a look and see how cleanly it can be done.

[landabaso]

Hey Salvatore, quick update: I started the migration work (descriptors v3 + bitcoinjs-lib v7 path) and I found an issue on API compatibility.

Using Buffer | Uint8Array (and number | bigint for sat values) works well for input params, so backward compatibility there is manageable.
But that does not solve returned fields/types. The library currently expose Buffer/number in many public return paths:

• AppClient.signPsbt() -> PartialSignature.pubkey/signature are Buffer
• AppClient.registerWallet() -> [walletId, walletHMAC] as Buffer
• WalletPolicy.getId() -> Buffer
• PsbtV2.getInputWitnessUtxo().amount, PsbtV2.getOutputAmount() -> number
• multiple PsbtV2 getters returning scripts/txids/utxos as Buffer

So if we fully switch public returns to Uint8Array/bigint, that would be a breaking change for downstream apps/libs.

My proposal is to keep external API as Buffer/number everywhere and convert internally to v7 types; then do a separate major-release PR if you want to adopt pure v7 public API (breaking).