--- Day changed Sun Dec 10 2017 04:47 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has joined #secp256k1 09:53 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 09:53 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 09:55 < nsh> which print.h is rangeproof_impl.h looking for? 10:01 < arubi> say I want to include commitments with my signatures and messages as in sign to contract, and there will be times that I will re-use the same commitment with different messages and also the other way, different commitments with the same message. is it safe to : 10:01 < arubi> 1. generate k from rfc6979(d, hash( message|partial commitment ), where 'partial commitment' is the commitment data that the signer wishes to commit to 10:01 < arubi> 2. generate the tweak from hash( nonce|message|partial commitment ) 10:01 < arubi> 3. partial commitment is assumed to be recoverable to anyone who gets the signature and message 10:01 < arubi> the concern is signing in a way that leaks the private key. I think I'm avoiding that by fixing nonce generation to include the commitment, and tweak generation to include the message 10:02 < arubi> s/recoverable to anyone/recoverable by anyone/ 10:06 < andytoshi> nsh: where? 10:07 < nsh> l 16. i commented it out and builds and benches fine 10:07 < andytoshi> l 16 of what 10:07 < nsh> of rangeproof_impl.h in your branch from the PR linked in the ML post 10:08 < andytoshi> ok, thanks, i'll remove that 10:08 < nsh> np 10:10 < andytoshi> should be gone now 10:10 < nsh> +1 10:10 < andytoshi> sorry about that, print.h is a local file i have that can dump various libsecp objects to the terminal in a format that's usable in sage 10:10 < andytoshi> which i use for debugging 10:12 < nsh> ah, makes sense. np :) 10:12 < andytoshi> also, thank you for building my PR :P 10:12 < nsh> are the python bindings easy to set up for ipython experimentation? not done this before iirc 10:12 < andytoshi> i've never used them either 10:13 < nsh> kk 10:13 * nsh looks at https://github.com/ludbb/secp256k1-py 10:16 -!- arubi [~ese168@gateway/tor-sasl/ese168] has quit [Remote host closed the connection] 10:17 -!- arubi [~ese168@gateway/tor-sasl/ese168] has joined #secp256k1 10:39 < arubi> let me know if OT.. maybe 'hash( nonce|message|partial commitment )' should be 'rfc6979(nonce, message|partial commitment)' ? if I'm not making sense, what I'm trying to ask is if I could assert a nonce re-use _only_ if all three conditions are the same: private key, message, partial commitment. 10:39 < arubi> arg, nonce and tweak re-use 10:40 < andytoshi> there is no need to hash the message into the tweak 10:41 < andytoshi> and there is no risk related to the tweak being reused or otherwise non-uniform 10:42 < arubi> can you explain what you mean by non-uniform? 10:43 < andytoshi> i mean if you had some biased way to produce tweaks, as long as it was still collision-resistant in the original nonce/extra_commitment pair it would be fine 10:43 < andytoshi> if the original k is uniformly random (as it will be by rfc6979) then you cannot cause any sort of key leakage by shitty tweak selection 10:46 < arubi> oh, I see what you mean. thanks 11:02 < waxwing> nsh, secp256k1-py is what i've used (in JM last couple of years). ofek made one called coincurve too, which may be better for all I know, but haven't used it. 11:03 * nsh nods 11:22 -!- SopaXorzTaker [~SopaXorzT@unaffiliated/sopaxorztaker] has quit [Read error: Connection reset by peer] 12:38 < nsh> coincurve seems more workable, just thinking of easiest way to add the new bindings 12:38 < nsh> function templates and structs mostly 13:49 < andytoshi> rebased aggsig. wonder if i should make a new PR because the old one has almost 100 comments that are mostly to do with ecmult (and mostly to do with bos-coster, at that :)) 18:06 < maaku> [10:40:55] there is no need to hash the message into the tweak 18:06 < maaku> don't you need to do that to prevent multiple commitments? 18:16 < sipa> arubi: you have the nonce in your tweak hash? that means you can't prove the S2C message without revealing your private key? 18:40 < andytoshi> maaku: you need to hash the original nonce and whatever you're committing to. the original nonce will prevent multiple commitments 18:40 < andytoshi> original public nonce* 22:37 < arubi> sipa, maybe bad terminology on my part, 'k' = secret nonce and indeed 'nonce' = public nonce 22:50 < arubi> the idea is a bitcoin signed message like we have now, where you recover a pubkey and then compare the pubkeyhash to the address provided, but currently there is no way to also commit to the scriptpubkey. with a commitment to the scriptpubkey I can give you [p2pkh|bech32|p2sh(p2wpkh)], signature, public nonce and message, and you can check that the address I provided corresponds to the commitment of the scriptpubkey. 22:50 < arubi> recover a pubkey from the message and sig like you normally would, recreate the tweak with using appropriate hash of the scriptpubkey and provided nonce, and compare against the provided address. this way somebody replacing a bech32 address with a p2pkh one will invalide the commitment 22:50 < arubi> /goes to work for now