--- Day changed Thu Oct 25 2018 00:46 < dongcarl> @andytosh1 From our previous convos about `PublicKey`s, the Address would encapsulate an `Option` where `PublicKey` is `rust-bitcoin`'s representation of a `PublicKey` not `secp256k1`'s right? 08:56 < stevenroose> This text format for bytes makes very little sense to me.. https://github.com/stepancheg/rust-protobuf/blob/master/protobuf/src/text_format/print.rs#L8-L25 11:16 < stevenroose> If a crate is yanked, can the name be reused? 12:31 < andytosh1> dongcarl: yeah 12:31 < andytosh1> dongcarl: i'd like the `Address` struct to roughly match the information available from Core's validateaddress (i think it's now getaddressinfo) RPC 12:32 < andytosh1> stevenroose: i've never heard of a crate being "yanked" -- if you want to reuse a name typically you have to ask the maintainer to add you as an owner, then you just release a new version with your new stuff 14:35 < stevenroose> BlueMatt: out of curiosity, what's the status of betterhash? 15:14 < BlueMatt> ariard: the first commit in #217: https://github.com/rust-bitcoin/rust-lightning/pull/217/commits/dac336be6aedd98f1d08c0ef0990f078c5f0a905 15:15 < BlueMatt> which I'd managed to confuse myself into thinking was merged, but its not 15:15 < BlueMatt> so dont worry about it 15:16 < BlueMatt> stevenroose: mostly implemented, though there's a few issues left that need to be addressed - https://github.com/TheBlueMatt/mining-proxy/issues 16:17 < stevenroose> andytoshi: dongcarl: there is no rust-bitcoin Signature type, right? So I guess secp256k1::Signature should be the only one. However, I'm getting InvalidSignature when parsing the one my Trezor gives me. I tried der, der_lax and compact. Could I be missing something? Ah, let me try consensus decoding 16:18 < stevenroose> Not defined on Signature. yeah they are just blobs inside a script ofc 16:23 < stevenroose> Hmm, the signature looks huge: 1f7f1a4a124f6b3ce71b7a1dab980a2bc66c92eba99613d907d8c1b24a0f204f7d377c45e5d2474141073d392a5f82d396f3f2ef95a064e64a2335ea6748ddcc84 (it's for a message, not a tx, but shouldn't be any different afaik) 16:23 < BlueMatt> signmessage signatures are recoverable signatures, not normal signatures 16:40 < stevenroose> BlueMatt: oh. does rust-secp256k1 support them? 16:40 < BlueMatt> yea, but its a different type iirc 16:43 < stevenroose> RecoverableSignature, got it! 16:50 < stevenroose> BlueMatt: it can't be deserialized from bytes without explicitly giving it a RecoveryId.. Can I just provide 0 if I don't have it? 17:01 < stevenroose> I'll look at it later, have to go. The sig I got is 65 bytes. I tried using the last byte as the RecoveryId, but didn't work (it's higher than 3) 17:09 < andytoshi> you may need to ask them. with ledger they had some weird adhoc format that their crypto chip was producing and i had to manually bit-munge it for icboc 17:09 < andytoshi> https://github.com/apoelstra/icebox/blob/master/src/util.rs#L39 17:10 < andytoshi> lol reading that comment, i was being way too clever for my own good 18:14 < Blackwolfsa> @BlueMatt When I updated that default min_dust_limit_satoshis I spotted all the test failed because during the unit tests. The estimator function calculates the starting value as 26... 18:16 < Blackwolfsa> I added a cfg test case to force it to 467 for unit tests, but I also spotted a todo at that function without any other text 18:33 < BlueMatt> looks like rust 1.30 broke honggfuzz building on travis :( 18:39 < Blackwolfsa> those two PRs of mine built fine this morning... 18:40 < BlueMatt> yea, 1.30 came out today 18:41 < Blackwolfsa> yeah must have been after work, ran rustup update now and its updating 18:48 < Blackwolfsa> Is there any outstanding issues on those two PR's of mine? 18:54 < BlueMatt> I havent had a chance to take a look yet today, was finishing up the serializer stuff for 0.0.6 and now looking at #214 cause gotta get 0.0.6 done todayish 19:10 < Blackwolfsa> cwl 19:33 < BlueMatt> Blackwolfsa: re: 202: we can't sleep in our socket handler 19:35 < BlueMatt> we should let the user decide how they want to handle threading, not blocking user threads arbitrarily 19:36 < BlueMatt> Blackwolfsa: re: 169: the docs here are still pretty thin: https://github.com/rust-bitcoin/rust-lightning/pull/169/files#diff-561ed89f6f138e5bd18c7d813aa8e380R32 19:36 < BlueMatt> can you write out full sentences that explain things? 20:32 < Blackwolfsa> on 202, should that not only block the connection to the syncing peer? 21:08 < Blackwolfsa> or do we need to pass that on to some other user created thread?