josie

> EDIT: oh, you probably meant the raw 33-byte results of the shared secret creation and public tweak data. Maybe those should be changed to secp256k1_pubkey instead. Yep! Sorry, my...

> It might make sense to have a return code signalling "ignore this tx, it's not suitable for silent payments" to differentiate it from an actual error that happened. Thinking...

> "invalid input data is passed", indicating that the user did something wrong (case 1 above) and "the individual input data passed is fine, but we still can't continue" (case...

> One open question is if we really need a dedicated routine to calculate A_tweaked = input_hash * A_sum (for light clients / silent payment indexes...). That routine would essentially...

I've rewritten [#28122](https://github.com/bitcoin/bitcoin/pull/28122) to use this module here: https://github.com/josibake/bitcoin/tree/implement-bip352-secp256k1-module. So far, so good! I'll take a fresh look here tomorrow with some feedback, and then update #28122 once I've cleaned...

> @josibake: I've add the missing `_create_tweaked_pubkey` function to the API. As far as I'm aware, a user would have all the necessary routines now that are needed for a...

> What is the input `k` in `_sender_create_output_pubkey`? `k` is a counter used by the receiver to create multiple outputs for the sender. Using the variable `k` here to match...

Thanks for chiming in @real-or-random , this is exactly the kind of review we are looking for at this stage! As much as possible, we'd like to keep this module...

@real-or-random spent some time digesting your comment and wanted to summarize some thoughts: > I think the entire module, as proposed, is a bit unusual for libsecp256k1 because it only...

@theStack I started refactoring the API based on https://github.com/bitcoin-core/secp256k1/pull/1471#issuecomment-1984303397. I've only completed the sender side, but will continue working on the receiver side. The main changes are: 1. Provide a...