Co-authored-by: RubenSomsen <rsomsen@gmail.com>

Co-authored-by: Vojtěch Strnad <43024885+vostrnad@users.noreply.github.com>

BIP173 defines a 90 char limit, but we need 115. Most implementations
already remove this limit as lightning encodings are longer than 90 char
and use bech32, but still should be mentioned for wallet implementors.

This better matches conventions used in other BIPS.
It's also likely wallet software already has code for doing these
operations if they support BIP32.

Remove version since upgrades to silent payments not require
regenerating silent payment keys. If there is a future upgrade
that would require regenerating keys, then it should have a new BIP number.

Instead of 32-byte x-only keys, use compressed public keys
for the silent payments address.

This is to avoid parity mismatches, especially in the case of adding
labels to the spend public key, which will cause the sign of the
y point to flip between even and odd.

Without the extra byte, we would need the sender and receiver to
constantly negate the public and private keys at each step, which
adds complexity and computational expense.

If Alice's wallet supports receiving silent payments, they
can use the silent payment protocol to create change outputs
for themselves.

Mention this explicitly in the specification for sending.

Include a modified copy of bech32m (removes the 90 char limit)
and a copy of the python secp256k1 implementation from the
Bitcoin Core test framework

In order to maintain parity, negate the private keys for taproot outputs
before performing ECDH. This ensures the receiver will arrive at the same result
without needing to check both the even and odd y points for taproot x-only public keys

Detail backwards compatible upgrades vs backwards incompatible upgrades