--- Log opened Tue Jan 14 00:00:06 2020 00:47 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 252 seconds] 01:25 -!- jonatack [~jon@213.152.161.249] has joined #rust-bitcoin 03:04 -!- Ambrose28Ernser [~Ambrose28@ns334669.ip-5-196-64.eu] has joined #rust-bitcoin 03:04 -!- jonatack [~jon@213.152.161.249] has quit [Ping timeout: 240 seconds] 03:06 -!- jonatack [~jon@213.152.161.69] has joined #rust-bitcoin 04:00 -!- Ambrose28Ernser [~Ambrose28@ns334669.ip-5-196-64.eu] has quit [Ping timeout: 260 seconds] 04:27 -!- belcher [~belcher@unaffiliated/belcher] has joined #rust-bitcoin 05:22 < stevenroose> andytoshi, nickler: any idea why the recoverable signature serialization that Core uses is not part of rust-secp256k1? 05:23 < stevenroose> It always serializes into [u8; 64] + RecoveryId and also constructs from such a pair 05:23 < stevenroose> While Core has some serialization format of 65 bytes where the first byte is 27 + (0x04 if compressed else 0x00) + RecoveryId 05:24 < stevenroose> Is that left out on purpose because it's core-specific? Can I add that to rust-secp or should I create an equivalent RecoverableSignature type in rust-bitcoin::util::key or so? 05:49 < elichai2> stevenroose: yep it's bitcoin specific. and bitcoin uses that extra bits for also saying if it's compressed or not. see: https://github.com/elichai/bitsign/blob/master/src/main.rs#L127 06:47 < stevenroose> elichai2: yeah I mentioned that 06:51 -!- jonatack [~jon@213.152.161.69] has quit [Ping timeout: 260 seconds] 06:52 < stevenroose> Ah I remember having a tab with bitsign open :D Some colleague wanted to have such a tool, so I added it to hal as well 06:52 < stevenroose> hal message sign and hal message verify or hal message recover 06:52 < stevenroose> I did the byte serialization manually 06:53 < elichai2> stevenroose: is hal compatible with bitcoin core's message signing/verification? 06:56 < stevenroose> uhu 06:56 < stevenroose> v0.5.0 was not because of that byte, fixed that in v0.5.1 :) 06:59 < elichai2> adding bitcoin core supported message signing/verification is somewhat convoluted 06:59 < elichai2> we need base64 06:59 < elichai2> and to say if a private key is a p2pkh 07:05 < stevenroose> elichai2: base64 is not needed if it's just about serializing the recoverable signature to bytes 07:06 < stevenroose> base64 can be done by the user 07:06 < elichai2> it's about supporting whatever core returns etc 07:07 < stevenroose> basically to avoid this: https://github.com/stevenroose/hal/blob/master/src/bin/hal/cmd/message.rs#L44-L50 07:07 < stevenroose> and this in the other direction: https://github.com/stevenroose/hal/blob/master/src/bin/hal/cmd/message.rs#L96-L98 07:08 < elichai2> do you do key generation? 07:13 < elichai2> stevenroose: (in hal) 07:18 < stevenroose> elichai2: yeah with `hal key generate` 07:18 < stevenroose> It doesn't do manual entropy for now, but that shouldn't be hard to add 07:19 < elichai2> so I guess I just did a lot of duplicate work :P 07:19 < stevenroose> It isn't supposed to be used in production after all. Actually hal bip39 generate does take an --entropy flag. Ah but that's for the deterministic entropy, not just to add some randomness to OS prng. 07:20 < stevenroose> elichai2: well it seems I did the duplicate work for the signed message, and you did for key generation :p 07:20 < elichai2> oh heh 07:20 < stevenroose> I consider hal more of a random swiss army knife for testing/quick fixes/inspection 07:20 < elichai2> well I also added a HKDF that the user can provide his own entropy if he's paranoid 07:20 < stevenroose> elichai2: yeah I saw that, that's why I mentioned hal key generate doesn't do that. 07:21 < elichai2> it was a nightly project for instagibbs lol 07:21 < elichai2> (in one night :P) 08:35 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 09:31 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 09:31 -!- Dean_Guss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 10:07 < andytoshi> stevenroose: i really dislike recoverable signatures 10:07 < andytoshi> but i wouldn't be opposed to a feature-gated implementation in rust-bitcoin 10:08 < andytoshi> but as elichai2 says, part of the reason was that i also felt i'd need base64 10:08 < andytoshi> btw i'm looking at bitcoin_hashes #71 now. sorry for not doing it yesterday, i went to visit kanzure instead of being online 10:09 < stevenroose> andytoshi: yeah for Display and FromStr probably. Personally the most convenient would be a serialize and deserialize method in rust-secp. Or serialize_core and deserialize_core or something. 10:09 < stevenroose> It's literally just adding that 27 + compressed flag or something. 10:09 < andytoshi> stevenroose: i'd like to implement https://github.com/bitcoin/bitcoin/pull/16440 (BIP 322) using miniscript 10:09 < andytoshi> https://github.com/bitcoin/bips/blob/master/bip-0322.mediawiki is a better link 10:10 < andytoshi> stevenroose: i think this belongs in rust-bitcoin not rust-secp 10:10 < andytoshi> because it's so bitcoin-specific 10:10 < andytoshi> i know this is kinda an artificial distiction.. 10:10 < andytoshi> but like, a "bitcoin signed message" is an absurdly specific and ad-hoc thing 10:11 < andytoshi> heh i kicked travis on #71 "just in case" they'd fixed the emscripten thing 10:11 < andytoshi> and now it won't let me merge because it needs to finish. oops 10:13 < stevenroose> andytoshi: is that like "sign message with scriptPubKey" that combines proof-of-ownership of UTXO + message signature? 10:13 < stevenroose> It's actually kinda strange that Bitcoin defines a "signed message" standard :D 10:14 < andytoshi> stevenroose: yep, that's the one 10:15 < andytoshi> and yeah, lol, i don't think much of any thought went into signmessage and then it wound up being in super heavy use 10:15 < andytoshi> as it's the only commonly available way to prove that HSMs control keys, prove control of coins, prove address validity, etc 10:16 < andytoshi> i love that bip 322 suggests that a script interpreter is "not too big a burden" 10:18 < stevenroose> > as it's the only commonly available way to prove that HSMs control keys, prove control of coins, prove address validity, etc 10:19 < stevenroose> Why couldn't an HSM just sign a random/preformatted message without `Bitcoin Signed Message`, recoverable signatures and base64 being in the loop? 10:26 < gwillen> it could but without a standard for it nobody could verify it 10:26 < gwillen> for whatever reason bitcoin signed messages are standard enough 10:26 < andytoshi> stevenroose: "Bitcoin Signed Message" prevents you from signing an actual transcation with this 10:26 < gwillen> oh, also important. 10:26 < andytoshi> and the length encoding and other shit makes it easy to implement if you are a core developer 10:27 < andytoshi> aside from the recoverable signature crap it's actually pretty reasonable 10:33 < stevenroose> So BIP322 is generally accepted as a good way forward for proving key ownership? 10:34 < andytoshi> i think so. nobody has ever implemented it, probably because it requires a script interpreter 10:34 < andytoshi> but i think rust-miniscript shuold be the first 10:35 < andytoshi> and like, there is no other post-segwit post-multisig proposal for message signing 10:35 < andytoshi> merged bitcoin_hashes #71 and published 11:14 -!- DeanWeen [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 11:24 < instagibbs> you could also just perhaps support scripts that are valid miniscript for bip322 11:34 < andytoshi> yeah that's what i'm thinking 11:35 < andytoshi> would be better than the core PR i linked which appears to be only single-signer 11:47 < kanzure> hey don't blame me 11:47 < kanzure> (i'm a bit late) 11:47 < instagibbs> I think it's the best anyone is going to do really... people with very specific needs will have to go their own way 16:01 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 17:13 -!- belcher [~belcher@unaffiliated/belcher] has quit [Quit: Leaving] 19:26 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has quit [Remote host closed the connection] 19:26 -!- DeanGuss [~dean@gateway/tor-sasl/deanguss] has joined #rust-bitcoin 21:03 -!- ghost43_ is now known as ghost43 23:24 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 272 seconds] 23:29 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin 23:43 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 260 seconds] --- Log closed Wed Jan 15 00:00:08 2020