--- Log opened Thu Aug 10 00:00:26 2023
00:21 -!- duderonomy [~duderonom@c-107-3-165-79.hsd1.ca.comcast.net] has quit [Ping timeout: 246 seconds]
12:38 -!- afilini [~afilini@2001:bc8:1828:245::2] has joined #bitcoin-rust
12:38 < afilini> sha512 impl from bitcoin_hashes is 25.3K (targeting armv7, optimizing for size)
12:39 < afilini> is there any interest in reducing this size? should i try working on it? maybe behind a feature, like lowmemory for secp
12:40 < afilini> (sha256 is 6.9K, ripmed160 4.8K)
12:45 < andytoshi> afilini: yeah, for sure i'd be interested. if there is a slowdown then yeah should be feature-gated
12:45 < andytoshi> i'm surprised it's so much bigger than sha512
12:48 < afilini> another interesting comparison: 
12:48 < afilini> 7.2KiB      [Unknown] rustsecp256k1_v0_6_1_sha256_write
12:48 < afilini> 6.9KiB bitcoin_hashes <bitcoin_hashes[6bd8b18c015b82b4]::sha256::HashEngine as bitcoin_hashes[6bd8b18c015b82b4]::HashEngine>::input
12:49 < afilini> the rust implementation is like 5% smaller than the c impl from secp. maybe the borrow checking allows the compiler to prune more unnecessary checks?
12:50 < afilini> it's also a bit wasteful to have both implementations in the same binary, but getting secp to use the rust implementation would probably be very messy
13:01 < andytoshi> that's an interesting idea ... i had always considered going in the opposite direction, on the assumption that the secp impl was faster
13:01 < andytoshi> but that wouldn't be possible due to creating a circular dependency between rust-secp and hashes
13:01 < andytoshi> i think, making rust-secp depend unconditionally on hashes, and pulling in the rust sha256 impl, wouldn't be too hard actually
13:02 < andytoshi> tobin was just advocating moving hashes into the rust-secp repo https://github.com/rust-bitcoin/rust-bitcoin/discussions/1985
13:02 < andytoshi> which i posted a disagreement with, but i could certainly be convinced..
13:39 < afilini> i think i would argue to just keep hashes in its own crate lol. i always find it a bit messy to have multiple crates (especially with diverging version numbers) in the same repo, because, for example, tags get mixed up
13:39 < afilini> in my opinion it makes sense to have multiple crates in a workspace only when you are normally working on all of them at the same time (so they would import each other via "path" imports in master)
13:41 < afilini> (i managed to get sha512 down to 9.4 KiB without much effort, tomorrow i'll do the same for the other functions and run benchmarks. it's for sure gonna be slower, but for my use-case that's fine)
13:42 < andytoshi> afilini: hashes is already in the rust-bitcoin repo. it was causing us quite a bit of pain having multiple repos that needed to be updated in lockstep
13:43 < andytoshi> moving it to the rust-secp repo instead would probably be an improvement from a maintenance/coordination POV
13:43 < andytoshi> afilini: cool! thanks for your work!
13:52 -!- duderonomy [~duderonom@c-107-3-165-79.hsd1.ca.comcast.net] has joined #bitcoin-rust
14:21 -!- Netsplit *.net <-> *.split quits: achow101
14:21 -!- Netsplit over, joins: achow101
22:06 < stevenroose> Some months ago, I re-picked up what I was trying for bitcoin-p2p and finally found some API that I really like. Work is stale for a few months now already, but published it anyway as some ppl might be interested in it.
22:06 < stevenroose> https://github.com/stevenroose/rust-bitcoin-p2p/
22:06 < stevenroose> Basically impls from *Manager is taken from nakamoto (with cloudhead's agreement, we discussed pulling p2p out of nakamoto and using the lib at some point)
22:07 < stevenroose> And I/O is done by some super thin "green thread runtime" built on top of cloudhead's poll crate popol. But it seems that might be very similar to io-reactor from dr-orlovsky and cloudhead. I only found out about that one after I was using erin for a while.
22:08 < stevenroose> The API focuses on (1) having a `Peer` abstraction, (2) having the Peer impl and Manager impls be totally isolated from each other and only have themselves as context, so that (3) all internal communication also happens through the same methods users would use to use the API.
22:09 < stevenroose> This means that (4) you can build an entirely custom setup by configuring each Manager manually and then do the interaction manually or just not have certain components, but there is a "organizer helper struct" `P2P` that will do all this linking for you so you just give it a single big config struct and it gives you a setup.
22:10 < stevenroose> No testing done so far, it should be in a state where after review of the API we start testing, but I wanted to have more feedback on API/design choices before I go dig too deep into this, especially since now i'm more interested in other things :)
--- Log closed Fri Aug 11 00:00:26 2023