Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix tests w/ sending outputs as subset of receiving #7

Open
wants to merge 14 commits into
base: silent-payments-bip
Choose a base branch
from

Conversation

Sosthene00
Copy link

I was having trouble running the tests, it failed at "Multiple outputs: multiple outputs, same recipient". After looking at the test logic and cygnet3 implementation, I noticed this slight difference between the python code and his rust. It seems to make sense to me and after that all tests pass.

josibake and others added 14 commits July 10, 2023 08:52
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
@josibake josibake force-pushed the silent-payments-bip branch 11 times, most recently from 91bf059 to 478a5c5 Compare August 4, 2023 08:11
@josibake josibake force-pushed the silent-payments-bip branch 2 times, most recently from 645c871 to c55f80c Compare August 9, 2023 09:49
@josibake josibake force-pushed the silent-payments-bip branch 3 times, most recently from eece921 to f0625f7 Compare January 11, 2024 15:40
@josibake josibake force-pushed the silent-payments-bip branch 4 times, most recently from b349517 to d73e924 Compare January 16, 2024 17:24
@josibake josibake force-pushed the silent-payments-bip branch 2 times, most recently from 30cdd03 to a2b52fe Compare January 26, 2024 16:27
@josibake josibake force-pushed the silent-payments-bip branch 2 times, most recently from 9c82669 to 57c89ae Compare April 4, 2024 06:21
@josibake josibake force-pushed the silent-payments-bip branch 3 times, most recently from d8ed18c to 36fefe5 Compare May 1, 2024 15:21
@josibake josibake force-pushed the silent-payments-bip branch 3 times, most recently from a60bfc3 to 17e1d16 Compare May 8, 2024 16:34
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants