Skip to content

Conversation

josibake
Copy link
Member

@josibake josibake commented Jul 21, 2023

This PR is part of integrating silent payments into Bitcoin Core. The project is tracked in #28536

Based on bitcoin-core/secp256k1#1698

BIP352

This PR focuses strictly on the BIP logic and attempts to separate it from the wallet and transaction implementation details. This is accomplished by working directly with public and private keys, instead of needing a wallet backend and transactions for testing. Labels for the receiver are optional and thus deferred for a later PR.

Test vectors from the BIP are included as unit tests.

@DrahtBot
Copy link
Contributor

DrahtBot commented Jul 21, 2023

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Code Coverage & Benchmarks

For details see: https://corecheck.dev/bitcoin/bitcoin/pulls/28122.

Reviews

See the guideline for information on the review process.
A summary of reviews will appear here.

Conflicts

Reviewers, this pull request conflicts with the following ones:

  • #32579 (headerssync: Correct unrealistic unit test behavior by hodlinator)
  • #31974 (Drop testnet3 by Sjors)
  • #27260 (Enhanced error messages for invalid network prefix during address parsing. by portlandhodl)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

LLM Linter (✨ experimental)

Possible typos and grammar issues:

  • exctracting -> extracting [spelling error in comment; misspelling impedes comprehension]
  • desintaions -> destinations [spelling error in documentation sentence]
  • std::<CPubKey, uint156> -> std::pair<CPubKey, uint256> [invalid/garbled type in documentation; wrong template/name and wrong integer size]
  • intendended -> intended [typo in function description]
  • faily -> fail [typo in comment causing confusion]
  • A explanation -> An explanation [article error in comment; should be "An" before vowel sound]

No other added code comments or documentation contained typographic/grammatical errors that made the English invalid or incomprehensible.

drahtbot_id_5_m

Copy link
Contributor

@aureleoules aureleoules left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left some comments. I will review further later.

@josibake
Copy link
Member Author

josibake commented Aug 1, 2023

Needs rebase, if still relevant

thanks, fixed!

@josibake
Copy link
Member Author

CI failure is due to the "test each commit" job not being able to handle a subtree merge commit. Ignoring for now; will look into fixing the CI job.

@Sjors
Copy link
Member

Sjors commented Jul 17, 2025

will look into fixing the CI job

Just add a dummy commit so the subtree merge is more than 6 deep :-)

Anyway, if you have to rebase again in the future, can you go past #32948? That makes it easier for me to rebase my index PR.

@DrahtBot
Copy link
Contributor

🚧 At least one of the CI tasks failed.
Task MSan, depends: https://github.com/bitcoin/bitcoin/runs/46645416048
LLM reason (✨ experimental): Memory sanitizer detected use of uninitialized memory during secp256k1 tests, causing CI failure.

Hints

Try to run the tests locally, according to the documentation. However, a CI failure may still
happen due to a number of reasons, for example:

  • Possibly due to a silent merge conflict (the changes in this pull request being
    incompatible with the current code in the target branch). If so, make sure to rebase on the latest
    commit of the target branch.

  • A sanitizer issue, which can only be found by compiling with the sanitizer and running the
    affected test.

  • An intermittent issue.

Leave a comment here, if you need help tracking down a confusing failure.

DashCoreAutoGuix pushed a commit to DashCoreAutoGuix/dash that referenced this pull request Aug 3, 2025
1580e3b fuzz: add ConstructPubKeyBytes function (josibake)

Pull request description:

  In bitcoin#28246 and bitcoin#28122 , we add a `PubKeyDestination` and a `V0SilentPaymentsDestination`. Both of these PRs update `fuzz/util.cpp` and need a way to create well-formed pubkeys. Currently in `fuzz/util.cpp`, we have some logic for creating pubkeys in the multisig data provider. This logic is duplicated in bitcoin#28246 and duplicated again in bitcoin#28122. Seems much better to have a `ConstructPubKeyBytes` function that both PRs (and any future work) can reuse.

  This PR introduces a function to do this and has the existing code use it. While the purpose is to introduce a utility function, the previous multisig code used `ConsumeIntegralInRange(4, 7)` which would have created some uncompressed pubkeys with the prefix 0x05, which is incorrect (see https://bitcoin.stackexchange.com/questions/57855/c-secp256k1-what-do-prefixes-0x06-and-0x07-in-an-uncompressed-public-key-signif)

  tldr; using `PickValueFromArray` is more correct as it limits to the set of defined prefixes for compressed and uncompressed pubkeys.

ACKs for top commit:
  Sjors:
    ACK 1580e3b

Tree-SHA512: c87c8bcd1f6b3a97ef772be93102efb912811c59f32211cfd531a116f1da8a57c8c6ff106b34f2a2b88d8b34fb5bc30d9f9ed6d2720113ffcaaa2f8d5dc9eb27
@josibake josibake force-pushed the implement-bip352 branch 2 times, most recently from 0220aad to fc30f20 Compare August 14, 2025 08:01
aa85bfb530 docs: update README
9f42a30b82 ci: enable silentpayments module
d504e48145 tests: add sha256 tag test
124750d580 tests: add constant time tests
b35ffa2e30 tests: add BIP-352 test vectors
038c5b9c9d silentpayments: add benchmarks for scanning
88eb3d4545 silentpayments: add examples/silentpayments.c
22b20fd617 silentpayments: receiving
df1de93765 silentpayments: recipient label support
76a0451c76 silentpayments: sending
3cd3a93bff build: add skeleton for new silentpayments (BIP352) module
f36afb8b3d Merge bitcoin-core/secp256k1#1725: tests: refactor tagged hash verification
5153cf1c91 tests: refactor tagged hash tests
d2dcf52091 Merge bitcoin-core/secp256k1#1726: docs: fix broken link to Tromer's cache.pdf paper
489a43d1bf docs: fix broken link to eprint cache.pdf paper
d599714147 Merge bitcoin-core/secp256k1#1722: docs: Exclude modules' `bench_impl.h` headers from coverage report
0458def51e doc: Add `--gcov-ignore-parse-errors=all` option to `gcovr` invocations
1aecce5936 doc: Add `--merge-mode-functions=separate` option to `gcovr` invocations
106a7cbf41 doc: Exclude modules' `bench_impl.h` headers from coverage report
a9e955d3ea autotools, docs: Adjust help string for `--enable-coverage` option
e523e4f90e Merge bitcoin-core/secp256k1#1720: chore(ci): Fix typo in Dockerfile comment
24ba8ff168 chore(ci): Fix typo in Dockerfile comment
74b8068c5d Merge bitcoin-core/secp256k1#1717: test: update wycheproof test vectors
c25c3c8a88 test: update wycheproof test vectors
20e3b44746 Merge bitcoin-core/secp256k1#1688: cmake: Avoid contaminating parent project's cache with `BUILD_SHARED_LIBS`
2c076d907a Merge bitcoin-core/secp256k1#1711: tests: update Wycheproof
7b07b22957 cmake: Avoid contaminating parent project's cache with BUILD_SHARED_LIBS
5433648ca0 Fix typos and spellings
9ea54c69b7 tests: update Wycheproof files

git-subtree-dir: src/secp256k1
git-subtree-split: aa85bfb530b9ffc3dde6eaa7a976e129b8bd2f58
Add a method for passing a KeyPair object to secp256k1 functions expecting a secp256k1_keypair.
This allows for passing a KeyPair directly to a secp256k1 function without needing to create a
temporary secp256k1_keypair object.
Wrap the silentpayments module from libsecp256k1. This is placed in
common as it is intended to be used by:

  * RPCs: for parsing addresses
  * Wallet: for sending, receiving, spending silent payment outputs
  * Node: for creating silent payment indexes for light clients
Have `IsValidDestination` return false for silent payment destinations
and set an error string when decoding a silent payment address.

This prevents anyone from sending to a silent payment address before
sending is implemented in the wallet, but also allows the functions to
be used in the unit testing famework.
Use the test vectors to test sending and receiving. A few cases are not
covered here, namely anything that requires testing specific to the
wallet. For example:

* Taproot script path spending is not tested, as that is better tested in
  a wallets coin selection / signing logic
* Re-computing outputs during RBF is not tested, as that is better
  tested in a wallets RBF logic

The unit tests are written in such a way that adding new test cases is
as easy as updating the JSON file
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.