--- 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 <hex> 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