Initial BIP-47 support

[kdmukai]

Implements:

• generating the recipient's BIP-47 shareable payment code (version 1).
• recipient's notification address.
• generate the nth payment address for the payer.
• generate the nth receive address for the recipient.
• extract the payer's payment code from a notification tx.

Implementation matches Samourai (still to be confirmed) and Sparrow (tested).

[stepansnigirev]

Overall, looks good. A few small changes required (i.e. your test doesn't pass). Also not clear if TODO will be addressed in this PR or in a separate one.

[kdmukai]

After my most recent commit, I am now satisfied with where this PR is at. Awaiting further review/feedback, but otherwise I consider this PR complete.

[Copilot]

Copilot was unable to review this pull request because the user who requested the review is ineligible. To be eligible to request a review, you need a paid Copilot license, or your organization must enable Copilot code review.

[miketlk]

AI review of BIP-47 implementation against the spec

Findings

1. High: get_payment_code_from_notification_tx does not implement the spec’s designated-input rules and fails on otherwise compliant notification transactions. It stops at the first input and only handles a P2PKH-like scriptSig or a [sig, pubkey] witness shape, but BIP47 defines the designated input as the first input that exposes a pubkey and says compliant wallets should recognize P2PK, P2PKH, bare multisig, and P2SH spends of those forms. See src/embit/bip47.py:228, src/embit/bip47.py:230, bips/bip-0047.mediawiki:151, bips/bip-0047.mediawiki:205. I verified locally that prepending a non-designated input with no exposed pubkey causes an IndexError instead of skipping to the next eligible input. The tests only cover a single one-input happy path, so they miss this entirely: tests/tests/test_bip47.py:240, tests/tests/test_bip47.py:255.

2. Medium: invalid unblinded payment codes are accepted instead of ignored. After unblinding, the code immediately Base58Check-encodes the payload without validating that the reconstructed x-coordinate is a valid secp256k1 point, even though the spec says such payloads must be ignored. See src/embit/bip47.py:251, src/embit/bip47.py:252, bips/bip-0047.mediawiki:189. I flipped one byte in the OP_RETURN payload from the vector transaction and the function still returned a PM... string instead of None. Current coverage only checks the valid vector and a wrong-recipient case: tests/tests/test_bip47.py:246, tests/tests/test_bip47.py:252.

3. Medium: the public API defaults and the tests encode non-standard address types as if they were BIP47 behavior. The spec defines version 1 payment addresses and notification addresses as P2PKH, but get_payment_address and get_receive_address default to p2wpkh, and the test suite treats p2wpkh / p2sh-p2wpkh vectors as normative. See src/embit/bip47.py:72, src/embit/bip47.py:109, bips/bip-0047.mediawiki:149, bips/bip-0047.mediawiki:227, tests/tests/test_bip47.py:27, tests/tests/test_bip47.py:173. If segwit derivation is an intentional extension, it should be documented as non-standard and not be the default under a spec-compliance API.

@kdmukai , could you please review this report? Is anything worth addressing before merging?