BIP329: add optional data fields, fix a JSON type

[doc-hex]

If the goal is solely to move labels between cooperating wallets, then previously defined values are the absolute minimum needed. However, wallet data exports can serve other purposes and many values associated with
addresses, transactions and outputs are already on-hand for the wallet generating the export, and yet would be hard or impossible for importing tools to reconstruct.

This PR proposes a bunch of optional fields that could be useful to users of this data. All are optional.

[murchandamus]

cc: @craigraw

[nvk]

ACK

If there was appetite would go even further with added WAC optional field and attempt to cover as much common accounting needs.

[xavierfiechter]

Below are my thoughts on specific fields and suggestions for improving the proposal while keeping it practical:

Block Height and Timestamps

Including the block height is very useful, especially for understanding transaction confirmation status. The timestamp, while useful in some cases, feels less critical. It can be derived if needed, and excluding it could simplify the format.

Transaction and Fees

Fees are a tricky field to standardize, especially for batched or multi-party ownership transactions.
Shifting the focus to inputs and outputs rather than whole transactions and handling the fee on its own makes it a lot easier for me.

Fair Market Value and Rate

The FMV field is probably the attribute I wanted the most. The problem with exchange rate is, that there are many of them and I would stick to one (your own) value.

Keypath

Okay.

Value (in sats)

While value (in sats) can be looked up using tools like Electrum, having it as part of the format is still a helpful convenience.

Heights for Addresses

Nah. Address reuse is a bad practice.

While it’s tempting to include some additional fields (mainly confirmation block height, MFV and value in sats) for richer metadata, I believe the BIP should stick to the smallest common denominator for simplicity and broad compatibility. Generally, I'm okay to store and parse metadata from the text label field and delegating more advanced data aggregation, management, and lookups to external tools and services, like labelbase.space.

That said, if @craigraw is open to merging changes into BIP-329, I am happy to adapt the python-bip329 library to support these extensions and make them accessible on the Labelbase platform as well.

[jonatack]

A few fixups and suggestions.

[doc-hex]

A few fixups and suggestions.

Thanks, all accepted and merged.

[jonatack]

Note that commit 58d1ef5 in this PR is a fix proposed separately in #1749.

[jonatack]

Latest push e63bfa4 indeed took all my feedback per git diff f91e5dcc e63bfa45

@xavierfiechter any specific changes/removals you would strongly request?

Pinging BIP author @craigraw for feedback.