Skip to content

Conversation

@jlest01
Copy link

@jlest01 jlest01 commented Aug 25, 2024

This PR proposes a new --silent-payments-index option that creates an index of Bip352 silent payments.
Most of the code is based on @Sosthene00's fork, but I made the following changes:

. It uses bitcoin-core/secp256k1#1519 and rust-bitcoin/rust-secp256k1#721 instead of the rust-silentpayments crate.
. It adds a new --silent-payments-index configuration option. Without this option, the server does not index silent payments and works the same as it does today.
. The code does not use Box[u8] in db.rs.

To run this, something like the following command can be used: cargo run -- --log-filters=INFO --db-dir <db_dir> --daemon-dir ~/.bitcoin/ --network signet --electrum-rpc-addr="127.0.0.1:60001" --silent-payments-index

@jlest01 jlest01 force-pushed the bip352-silentpayments-module branch from 6df1529 to c1e110c Compare September 6, 2024 23:57
@securitybrahh
Copy link

securitybrahh commented Dec 2, 2024

does not index silent payments

but I can make silent payments to the node, from a client?

Comment on lines +442 to +447
if self
.index
.store
.iter_spending(SpendingPrefixRow::scan_prefix(outpoint))
.next()
.is_none()
Copy link
Contributor

Choose a reason for hiding this comment

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

If I understand correctly, this must make sure only transactions with (P2TR) unspent outputs are scanned.
Making an index dependent on data from another index seems odd to me, I have some questions about this:

  • Does this handle collisions of spending entries in the database (correctly)?
  • Wouldn't a user want historic data after restoring a wallet?
  • Looking at the code, spending is made sure to be updated to the current chain tip and then tweaks is indexed (do I get this correctly?). This will include spent transactions (imagine 1 P2TR output TXs) as blocks get propagated, but not on the initial sync or when spent in the same block. Is this intended?

Comment on lines +538 to +541
let height = index.chain.get_block_height(&hash).expect("Unexpected non existing blockhash");
let mut value: Vec<u8> = u64::try_from(height).expect("Unexpected invalid usize").to_be_bytes().to_vec();
value.extend(tweaks.iter());
batch.tweak_rows.push(value);
Copy link
Contributor

Choose a reason for hiding this comment

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

If I understand correctly, the key of the stored key-value pair is the block height. Is RocksDB the right tool for the job then? I think this can easily be achieved using two files that only need appending when building/updating the index: one for the tweaks, and one for the offsets and lengths in the tweaks file, for every block (for random access).

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.

3 participants