--- Log opened Sun May 31 00:00:36 2020
02:13 -!- Kiminuo [~mix@89.238.186.252] has joined #rust-bitcoin
03:05 -!- Devon3Kuhic [~Devon3Kuh@static.57.1.216.95.clients.your-server.de] has joined #rust-bitcoin
03:55 -!- Kiminuo [~mix@89.238.186.252] has quit [Ping timeout: 240 seconds]
04:15 -!- surja795 [~surja795@c-24-62-248-154.hsd1.ma.comcast.net] has joined #rust-bitcoin
04:19 -!- surja795 [~surja795@c-24-62-248-154.hsd1.ma.comcast.net] has quit [Ping timeout: 258 seconds]
05:15 -!- surja795 [~surja795@c-24-62-248-154.hsd1.ma.comcast.net] has joined #rust-bitcoin
06:06 -!- Kiminuo [~mix@89.238.186.252] has joined #rust-bitcoin
06:13 -!- Pepe70 [~n@195.158.248.157] has joined #rust-bitcoin
06:15 -!- Pepe70 [~n@195.158.248.157] has quit [Remote host closed the connection]
06:21 -!- Pepe70 [~n@195.158.248.157] has joined #rust-bitcoin
06:44 -!- Kiminuo [~mix@89.238.186.252] has quit [Ping timeout: 246 seconds]
07:14 < elichai2> If we could get to a new major bump for rust-secp, I could point these that the `cc` problems are gone https://github.com/briansmith/ring/issues/984
07:14 < elichai2> although there are some open PRs we might want to get in first
07:26 -!- Kiminuo [~mix@89.238.186.252] has joined #rust-bitcoin
07:37 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
07:38 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
08:22 -!- Kiminuo [~mix@89.238.186.252] has quit [Ping timeout: 256 seconds]
08:25 -!- Pepe70 [~n@195.158.248.157] has quit [Remote host closed the connection]
08:45 -!- Kiminuo [~mix@89.238.186.252] has joined #rust-bitcoin
09:27 < cloudhead> Any reason why the `bitcoin` library doesn't have an equivalent to `Uint256::SetCompact(u32)`? Currently you can only go from `U256 -> u32` but not the other way.. or am I missing something?
09:31 -!- Devon3Kuhic [~Devon3Kuh@static.57.1.216.95.clients.your-server.de] has quit [Ping timeout: 256 seconds]
09:42 -!- Kiminuo [~mix@89.238.186.252] has quit [Ping timeout: 256 seconds]
09:43 -!- Kiminuo [~mix@89.238.186.252] has joined #rust-bitcoin
11:35 < sgeisler> cloudhead: I'm not aware that a `u256` can be transformed to `[u32; 8]` (I assume that's what you mean). There is a way to get the underlying `[u64; 4]` using the horribly named function `to_bytes()`. And there's a `From<&[u64]>` impl that does the inverse.
11:37 < sgeisler> Or do you mean constructing a `u256` from a single `u32`?  As you can construct one from a `u64` that should be possible by casting to `u64`.
11:40 -!- Kiminuo [~mix@89.238.186.252] has quit [Quit: Leaving]
11:46 < sgeisler> Oh, I totally missed you probably meant `compact_target_from_u256` with `U256 -> u32`. Yeah, in that case it would be nice to refactor the reverse function from `BlockHeader::target()`and make it publicly accessible.
12:05 < sgeisler> andytoshi, stevenroose: it's kinda weird that our best (only real?) hex implementation resides in bitcoin_hashes. What do you think about making it its own crate under the rust-bitcoin project?
12:08 -!- ghost43 [~daer@gateway/tor-sasl/daer] has quit [Remote host closed the connection]
12:09 -!- ghost43 [~daer@gateway/tor-sasl/daer] has joined #rust-bitcoin
12:31 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has quit [Ping timeout: 246 seconds]
12:37 -!- jonatack [~jon@2a01:e0a:53c:a200:bb54:3be5:c3d0:9ce5] has joined #rust-bitcoin
13:03 < cloudhead> sgeisler: okay, that's exactly what I mean, the logic resides in `BlockHeader::target`, but requires a header to use
13:04 < sgeisler> I don't think there would be any objections against extracting it into its own function
13:13 < stevenroose> sgeisler: yeah or just improving/adopting/contributing to the hex crate
13:14 < stevenroose> sgeisler: I'd be in favor of having that separate yes
13:14 < stevenroose> But it's not a huge nuisance tbh :p
13:23 < sgeisler> stevenroose: I think the only problem with the `hex` crate is that it's not under our control. Tbh, I don't care all that much since it's a very small crate and easy to review. So, either way: using the hex crate or having our own, idc. What I care about is not scattering custom hex impls around our code base or having to touch `bitcoin_hashes` to implement `FromHex` for another std lib type (mainly arrays of
13:23 < sgeisler> different sizes, can't await const generics).
13:26 < sgeisler> It's just not intuitive. E.g. I knew we had at least one rust-bitcoin hex impl, but had to search quite a while to find it. And I think I saw other, more specialized ones too. Would be nice to consolidate.
14:09 < cloudhead> sgeisler: ok thanks, I will propose a change
15:52 < cloudhead> here it is: https://github.com/rust-bitcoin/rust-bitcoin/pull/429
15:53 < cloudhead> the rust 1.22 target seems to be failing for an unrelated reason
19:05 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has quit [Quit: No Ping reply in 180 seconds.]
19:07 -!- willcl_ark [~quassel@cpc123762-trow7-2-0-cust7.18-1.cable.virginm.net] has joined #rust-bitcoin
19:20 -!- sgeisler_ [sid356034@gateway/web/irccloud.com/x-wytsersrsromyynn] has joined #rust-bitcoin
19:28 -!- Netsplit *.net <-> *.split quits: moneyball, sgeisler
19:28 -!- sgeisler_ is now known as sgeisler
19:31 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-ferchfbwyendkkci] has quit [Ping timeout: 240 seconds]
19:32 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-vkykyqvsmkgpqrsj] has quit [Ping timeout: 256 seconds]
19:42 -!- dpc [dpcmatrixo@gateway/shell/matrix.org/x-mapquevltlkthhzu] has joined #rust-bitcoin
19:59 -!- surja795 [~surja795@c-24-62-248-154.hsd1.ma.comcast.net] has quit [Remote host closed the connection]
20:03 -!- icota[m] [icotamatri@gateway/shell/matrix.org/x-sctvyrivogphjxke] has joined #rust-bitcoin
21:41 -!- dongcarl [~dongcarl@unaffiliated/dongcarl] has quit [Read error: Connection reset by peer]
--- Log closed Mon Jun 01 00:00:38 2020