--- Log opened Sat May 15 00:00:55 2021
02:32 -!- belcher_ is now known as belcher
04:24 -!- real_or_random [~real_or_r@173.249.7.254] has quit [Quit: ZNC 1.8.2 - https://znc.in]
04:26 -!- real_or_random [~real_or_r@173.249.7.254] has joined #secp256k1
06:41 -!- snowflake [~snowflake@gateway/tor-sasl/snowflake] has quit [Ping timeout: 240 seconds]
06:41 -!- snowflake [~snowflake@gateway/tor-sasl/snowflake] has joined #secp256k1
07:49 < roconnor> f*****g contravaraince, How does it work?
09:03 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has quit [Quit: Quit]
09:04 -!- BlueMatt [~BlueMatt@unaffiliated/bluematt] has joined #secp256k1
09:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has quit [Read error: Connection reset by peer]
09:35 -!- luke-jr [~luke-jr@unaffiliated/luke-jr] has joined #secp256k1
10:18 < real_or_random> roconnor: yeah idk how I got this wrong ^^
10:20 < roconnor> I think the existing API is both confusing and optimal.
10:22 < sipa> ignoring logistical overhead (which is substantial), the ideal solution would be having two separate sign functions, and two different nonce function types...
10:22 < sipa> taking this overhead into account, i think it's fine
10:23 < real_or_random> two separate functions is overkill for sure
10:24 < roconnor> If we consider the "moral subtyping" relationship as a partial order, the current API is a LUB of what would be those two separate function signatures.
10:25 < roconnor> This is why it looks confusing, because the current function signature is a fusion of two different function signatures.
10:25 < real_or_random> I still lean towards thinking that we should not implicitly do the cast for the user. The user can cast away the constness in his nonce function argument if he really wants to. "Explicit is better than implicit"
10:25 < roconnor> But it is optimal in the sense that its compatiable with both functions.
10:26 < roconnor> real_or_random: that is an interesting angle.
10:26 < sipa> also: mutable nonces are for far more advanced use cases (and testing)
10:26 < real_or_random> right
10:27 < sipa> so it may make sense to optimize for the common case
10:27 < real_or_random> also: the implementer of the nonce functions could be different from the sign() caller
10:28 < real_or_random> e.g. think of "optimized" language bindings / wrapper libraries that provide special nonce functions
10:29 -!- queip [~queip@unaffiliated/rezurus] has quit [Ping timeout: 260 seconds]
10:29 < real_or_random> So in the end, < 1% of users will want their own nonce function and probably < 1% of them need to write data out of it.
10:30 < real_or_random> (And it sounds dangerous to leak data out of your nonce function. ^^)
10:30 < real_or_random> I feel that sticking to const is slightly better but given that this is such an obscure use case, it's a pretty minor thing in the end.
10:32 -!- queip [~queip@unaffiliated/rezurus] has joined #secp256k1
10:33 < real_or_random> I'll reply in on github. Also note that this is not only about the nonce_functions but also the callbacks.
10:38 < roconnor> leaking data like incrementing your nonce counter?
12:18 < real_or_random> Yeah that's fine but you can do this in the caller... Ok, in the end it's arbitrary, you can do everything in the caller
19:31 -!- belcher_ [~belcher@unaffiliated/belcher] has joined #secp256k1
19:33 -!- belcher [~belcher@unaffiliated/belcher] has quit [Ping timeout: 240 seconds]
19:52 -!- roconnor [~roconnor@host-23-91-186-24.dyn.295.ca] has quit [Quit: Konversation terminated!]
--- Log closed Sun May 16 00:00:56 2021