BIP-352: add test vector for edge case - input key intermediate sum zero #2142

@shuv-amp discovered this edge case and reported to bdk-sp and BlueWallet.

Exercises [A, -A, A] input key pattern where the intermediate sum hits zero after the first two keys, but the final sum is non-zero. Implementations that validate after each pairwise addition (rather than summing all keys first) will incorrectly reject this case. @theStack - the reference implementation summation handles this case correctly as-is

Concept ACK

Thanks for adding! Can you add a brief entry to the changelog with bumped PATCH version?

LGTM for latest push diff only (removal of extra double-quote and changelog entry)

ACK 00957af80e5060347b4c333f9460f16a30e2ee32

Verified that the first two input keys cancel each other out and the corresponding pubkeys match as well:

$ uv run --with git+https://github.com/secp256k1lab/secp256k1lab python
Python 3.11.13 (main, Aug 18 2025, 19:22:12) [Clang 20.1.4 ] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from secp256k1lab.secp256k1 import Scalar, GE, G
>>> seckey1 = Scalar.from_bytes_checked(bytes.fromhex("a6df6a0bb448992a301df4258e06a89fe7cf7146f59ac3bd5ff26083acb22ceb"))
>>> seckey2 = Scalar.from_bytes_checked(bytes.fromhex("592095f44bb766d5cfe20bda71f9575ed2df6b9fb9addc7e5fdffe0923841456"))
>>> seckey1 + seckey2
Scalar(0x0)
>>> (seckey1 * G).to_bytes_compressed().hex()
'02557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975'
>>> (seckey2 * G).to_bytes_compressed().hex()
'03557ef3e55b0a52489b4454c1169e06bdea43687a69c1f190eb50781644ab6975'

Sanity-checked the new test (second to last) passes.

jon|(00957af8...):~/bitcoin/bips/bip-0352$ ./reference.py send_and_receive_test_vectors.json
Simple send: two inputs
Simple send: two inputs, order reversed
Simple send: two inputs from the same transaction
Simple send: two inputs from the same transaction, order reversed
Outpoint ordering byte-lexicographically vs. vout-integer
Single recipient: multiple UTXOs from the same public key
Single recipient: taproot only inputs with even y-values
Single recipient: taproot only with mixed even/odd y-values
Single recipient: taproot input with even y-value and non-taproot input
Single recipient: taproot input with odd y-value and non-taproot input
Multiple outputs: multiple outputs, same recipient
Multiple outputs: multiple outputs, multiple recipients
Receiving with labels: label with even parity
Receiving with labels: label with odd parity
Receiving with labels: large label integer
Multiple outputs with labels: un-labeled and labeled address; same recipient
Multiple outputs with labels: multiple outputs for labeled address; same recipient
Multiple outputs with labels: un-labeled, labeled, and multiple outputs for labeled address; same recipients
Single recipient: use silent payments for sender change
Single recipient: taproot input with NUMS point
Pubkey extraction from malleated p2pkh
P2PKH and P2WPKH Uncompressed Keys are skipped
Skip invalid P2SH inputs
Recipient ignores unrelated outputs
No valid inputs, sender generates no outputs
Input keys sum up to zero / point at infinity: sending fails, receiver skips tx
Input keys intermediate sum is zero but final sum is non-zero
Maximum per-group recipient limit K_max is exceeded (2324 matches): sending fails, receiver doesn't scan beyond limit
All tests passed