|
1 | | -# Silent Payments |
2 | | - |
3 | | -A rust implementation of BIP352: Silent Payments. |
4 | | - |
5 | | -## About |
6 | | - |
7 | | -**Warning: both this crate and BIP352 are still quite new. |
8 | | -Review this library carefully before using it with mainnet funds.** |
9 | | - |
10 | | -This library supports creating and sending to silent payment addresses, |
11 | | -building on [`secp256k1`](https://docs.rs/secp256k1/latest/secp256k1) |
12 | | -`PublicKey` and `SecretKey` structs for the interface. |
13 | | -In the future, the library will probably be expanded to rely on structs from rust-bitcoin as well. |
14 | | - |
15 | | -The library is split up in two parts: sending and receiving. |
16 | | - |
17 | | -## Feature Flags |
18 | | - |
19 | | -This library offers granular feature flags to minimize dependencies for different use cases: |
20 | | - |
21 | | -- **default**: Enables all features (`encode`, `sending`, `receiving`) |
22 | | -- **encode**: Enables string encoding/decoding for `SilentPaymentAddress` (adds `bech32` dependency) |
23 | | -- **serde**: Enables serde serialization/deserialization for types (adds `serde` dependency) |
24 | | -- **sending**: Enables sending functionality (adds `bitcoin_hashes`, `hex` dependencies) |
25 | | -- **receiving**: Enables receiving functionality (adds `bitcoin_hashes`, `hex`, `bimap`, `serde` dependencies) |
26 | | - |
27 | | -### Minimal Usage |
28 | | - |
29 | | -If you only need the type definitions (`Network` and `SilentPaymentAddress`) without any protocol functionality: |
30 | | - |
31 | | -```toml |
32 | | -[dependencies] |
33 | | -silentpayments = { version = "0.4", default-features = false } |
34 | | -``` |
35 | | - |
36 | | -This configuration only pulls in `secp256k1` as a dependency, significantly reducing the dependency tree for applications that only need to work with silent payment addresses without implementing the full protocol. |
37 | | - |
38 | | -**Bring Your Own Parser**: Even without the `encode` feature, you can construct a `SilentPaymentAddress` using `SilentPaymentAddress::new()` if you parse the bech32 yourself. This is useful if your application already has a bech32 parser and you want to avoid duplicate dependencies. The constructor documentation includes the complete bech32 format specification. |
39 | | - |
40 | | -### Custom Feature Combinations |
41 | | - |
42 | | -You can enable only the features you need: |
43 | | - |
44 | | -```toml |
45 | | -# Just types and string encoding (no protocol implementation) |
46 | | -silentpayments = { version = "0.4", default-features = false, features = ["encode"] } |
47 | | - |
48 | | -# Types with serde support (no protocol or encoding) |
49 | | -silentpayments = { version = "0.4", default-features = false, features = ["serde"] } |
50 | | - |
51 | | -# Only sending capability |
52 | | -silentpayments = { version = "0.4", default-features = false, features = ["sending"] } |
53 | | - |
54 | | -# Only receiving capability |
55 | | -silentpayments = { version = "0.4", default-features = false, features = ["receiving"] } |
56 | | -``` |
57 | | - |
58 | | -## Sending |
59 | | - |
60 | | -For sending to a silent payment address, you can call the `sender::generate_recipient_pubkeys` function. |
61 | | -This function takes a list of silent payment recipients, as well as a `partial_secret`. |
62 | | - |
63 | | -The `partial_secret` represents the sum of all input private keys multiplied with the input hash. |
64 | | -To compute the `partial_secret`, the `utils::sending::compute_partial_secret` function can be used, |
65 | | -although this requires exposing secret data to this library. |
66 | | -Other methods for calculating the `partial_secret` will be added later. |
67 | | - |
68 | | -## Recipient |
69 | | - |
70 | | -For receiving silent payments, we use the `receiving::Receiver` struct. |
71 | | -This `Receiver` struct implements a `scan_transaction` function that can be used to scan an incoming transaction for newly received payments. |
72 | | - |
73 | | -The library also supports labels. |
74 | | -The change label (label for generating change addresses) is included by default. |
75 | | -You can add additional labels before scanning by using the `add_label` function. |
76 | | - |
77 | | -## Examples |
78 | | - |
79 | | -Check out the `examples` folder for some simple sending and receiving examples. |
80 | | -These examples are still very elementary, and will be expanded later. |
81 | | -In the meantime, you can look at `tests/vector_tests.rs` to see how sending and receiving works in more detail. |
82 | | - |
83 | | -We are also working on another project called [SPDK](https://github.com/cygnet3/spdk) |
84 | | -(Silent Payments Development Kit) which builds on this library. |
85 | | -SPDK can be used as a basis for building a silent payments wallet. |
86 | | -It allows for scanning for incoming payments, as well as sending. |
87 | | -Even if SPDK itself doesn't seem interesting to you, it could still be a good resource |
88 | | -for showing how this library can be integrated with wallets. |
89 | | - |
90 | | -## Tests |
91 | | - |
92 | | -The `tests/resources` folder contains a copy of the test vectors as of May 1st 2024. |
93 | | - |
94 | | -You can test the code using the test vectors by running `cargo test`. |
| 1 | +## This crate has been integrated into the [SPDK workspace](https://github.com/cygnet3/spdk). |
0 commit comments