Silentpayments refactor#125
Conversation
…PubkeysInput` docs(sending): update docs for generate_recipient_pubkeys
* use bytes array instead of (String, u32) * enforce at least 1 outpoint passed as argument, prevents empty outpoints error * also updates calling sites in tests and examples
* new `TypedSecretKey<State>` type that keep track of changes made to a secret key and help enforce the protocol * `NonEmptyNormalizedKeys` type prevents empty keys array errors * taproot key normalization is now accessible as a public API, not buried inside a private function `get_a_sum_secret_key` * unrelated, but commited for convenience: `calculate_partial_secret` takes a secp context as argument
| fn try_from(value: u8) -> std::result::Result<Self, Self::Error> { | ||
| match value { | ||
| 0 => Ok(Self::ZERO), | ||
| _ => Err(Error::GenericError("Unknwon silent payment version".to_string())) |
There was a problem hiding this comment.
| _ => Err(Error::GenericError("Unknwon silent payment version".to_string())) | |
| _ => Err(Error::GenericError("Unknown silent payment version".to_string())) |
| pub(crate) fn calculate_input_hash( | ||
| outpoints_data: &[(String, u32)], | ||
| pub fn calculate_input_hash( | ||
| outpoint_head: &[u8; OUTPOINTS_LEN], |
There was a problem hiding this comment.
One refactoring change that I've been wanting to make for a long time is to use a custom OutPoint struct for our public api functions where we're expecting an outpoint struct. Maybe we can use that here too?
There was a problem hiding this comment.
We could, I was using bytes array though because that's not making a lot of assumptions but I agree that an ad hoc Outpoint type that acts as a thin wrapper around that bytes array and add some build-time guarantees is a good idea
There was a problem hiding this comment.
The real issue is that we can't rely on rust-bitcoin types so letting the caller the responsibility of using serialize(&outpoint).try_into().unwrap() seemed a good idea to me, maybe just document it better. The only risk I see is caller passing a null outpoint, but is it a real risk though?
Long overdue refactoring of silentpayments crate, some changes were things I wanted to do for a long time, others are made to prepare for the psbt integration.
Most significant ones are:
The rest is mostly incremental improvements that can be discussed case by case.