--- Log opened Fri Jun 18 00:00:41 2021 00:23 -!- belcher_ is now known as belcher 00:29 -!- powerjungle [~powerjung@h081217087223.dyn.cm.kabsi.at] has quit [Quit: ZNC - https://znc.in] 00:39 -!- rich- is now known as PaulTroon 00:42 -!- PaulTroon is now known as yakshaver 00:43 -!- yakshaver is now known as remyers 02:28 -!- dunxen [dunxen@gateway/vpn/protonvpn/dunxen] has joined #bitcoin-rust 02:54 -!- dunxen [dunxen@gateway/vpn/protonvpn/dunxen] has quit [Quit: Leaving...] 04:00 -!- h4sh3d [~h4sh3d@user/h4sh3d] has quit [Ping timeout: 268 seconds] 05:32 -!- tibo_ [~tibo@2400:4050:2a83:7000:c435:9e8d:87cd:ad38] has quit [Remote host closed the connection] 07:57 -!- h4sh3d [~h4sh3d@user/h4sh3d] has joined #bitcoin-rust 10:14 < andytoshi> so, regarding a bech32 release 10:14 < andytoshi> it looks like we always use `alloc` when std is disabled? 10:14 < andytoshi> rather than feature-gating it as we did with bitcoin_hashes? 11:49 < devrandom> I assume RCasatta chose to do that because of the heavy use of Vec / String 12:51 < BlueMatt> andytoshi: what would you prefer? 12:51 < BlueMatt> andytoshi: currently devrandom's rust-bitcoin pr requires that you specify at least either std or no-std, and compile-fails if you have neither 12:51 < BlueMatt> or we could go RCasatta[m]'s approach like on rust-bech32 12:53 < devrandom> the single feature approach would mean to pull in hashbrown unconditionally 12:54 < BlueMatt> oh, right, yea, that's why we didnt do that :) 12:54 < BlueMatt> yes, good idea :p 13:01 < andytoshi> BlueMatt: i would prefer having an explicit feature to pull in alloc, since it changes the MSRV 13:03 < BlueMatt> andytoshi: I guess the quesiton for rust-bech32 is that if you disable default features, we either dont compile or we require you say "alloc" 13:03 < BlueMatt> personally I dont think it matters, but if you feel strongly, do it! I'll ack :) 13:08 < andytoshi> heh, yeah, fair enough ... if the alternative is just not compiling 13:08 < andytoshi> i think i'm fine with it as-is 13:09 < andytoshi> though we should note somewhere that the MSRV is different if you disable std 13:16 < BlueMatt> yes, absolutely. 13:16 < BlueMatt> luckily crates.io now shows README.mds :) 13:54 < andytoshi> so what needs to be done here? should i make a PR to bump the minor version number and update the README? 13:55 < andytoshi> i guess the old behavior with nostd was "compilation fails" and now it's "MSRV is 1.36" so that's not a breaking change 13:55 < andytoshi> and nothing should've changed if std is on 13:55 < BlueMatt> andytoshi: that's my understanding, yes. 13:55 < andytoshi> dope 13:56 < BlueMatt> no_std is so close I can taste it 13:58 < andytoshi> kk https://github.com/rust-bitcoin/rust-bech32/pull/53 version bum 13:59 < andytoshi> clark gave me merge & crates access. i guess he did for you too? 13:59 < BlueMatt> yea, I'll let you upload, tho :) 13:59 < andytoshi> sounds good :0 13:59 < andytoshi> :) 14:00 < BlueMatt> yea, just went and re-skimmed the no_std pr, I think you're good to go. 14:00 < andytoshi> dope 14:00 < andytoshi> can you click merge tho 14:01 < BlueMatt> oh, ci passed, ok 14:02 < andytoshi> published :) 14:03 < BlueMatt> cc devrandom 14:03 < BlueMatt> andytoshi: oh, can we do the same with bitcoin_hashes? 14:04 < andytoshi> oh sure 14:05 < andytoshi> https://github.com/rust-bitcoin/bitcoin_hashes/pull/129 is open -- i see you acked it, want to merge? 14:05 < andytoshi> i don't think i need a changelog update for the std+alloc thing 14:06 < BlueMatt> yea, let me go back through prs sec 14:07 < BlueMatt> yea, looks good, done. 14:08 < andytoshi> published :) 14:10 < BlueMatt> awesome. so re: rust-bitcoin: 603 currently requires a major version bump, which is probably ok, but alternatively we could split out the merkle block construction changes and include that in a separate pr in the next major version and release no_std without it 14:10 < BlueMatt> either are fine, just a quesiton of "wen next major version" 14:13 < BlueMatt> andytoshi: oh, can i merge https://github.com/rust-bitcoin/rust-secp256k1/pull/305 ? 14:13 < BlueMatt> or was there any followup before we ship a new rust-secp version? 14:17 < andytoshi> BlueMatt: yeah you can merge 305 14:18 < andytoshi> then we can pull 304 and 306 into a new major version bump which we can do reasonably quickly 14:19 < BlueMatt> done! 14:19 < andytoshi> dr-orlovsky: https://github.com/rust-bitcoin/rust-secp256k1/pull/306 did you see my comment here 14:19 < andytoshi> dope 14:19 < BlueMatt> what's your take on timeline to next rust-bitcoin release/ 14:19 < BlueMatt> ? 14:20 < andytoshi> hmmm, so, i had originally thought that this next major rev would be the big one where we break all the APIs and stuff 14:20 < andytoshi> but it seems like we've accumulated a number of more-useful things 14:20 < andytoshi> that people probably want on a shorter timeline 14:22 < andytoshi> actually seems like https://github.com/rust-bitcoin/rust-bitcoin/pull/525 has wide support (there is some arguing about rustfmt but we can ignore that for now) 14:22 < andytoshi> so i could re-make/rebase that that PR 14:22 < andytoshi> (this is the module-flattening one) 14:23 < andytoshi> BlueMatt: i think even with some fairly invasive module-rearranging, we could probably do a major rev in the next 2-3 weeks 14:23 < andytoshi> or at least get to a point where we are pinging people repeatedly for the same short list of PRs 14:25 < BlueMatt> hmm, would be nice to do no_std without a huge rearrange of the crate 14:26 < BlueMatt> devrandom: what do you think about no_std without a major version bump by just un-exposing the one hashmap-exposed function? 14:26 < BlueMatt> then we can re-expose it in the next major v 14:27 < andytoshi> we can punt on the API rearrangement then 14:27 < andytoshi> if nostd would naturally require a major bump 14:27 < andytoshi> what is the hashmap-exposed function issue? 14:30 < devrandom> BlueMatt: are you talking about `MerkleBlock::from_block` and `from_header_txids`? 14:31 < BlueMatt> devrandom: yes 14:31 < BlueMatt> andytoshi: there is one function that has a HashMap in the API, and HashMap is not no_std, so we have to use hashbrown for that, which then causes you to have a different api based on std or no_std features 14:31 < BlueMatt> which is bad cause how do you pick if you have both? 14:31 < BlueMatt> anyway, i think we should just un-expose those two functions for no_std builds and then change the api in the next version 14:32 < BlueMatt> its two functions, its almost not worth thinking about 14:32 < devrandom> (PR currently has them take a function arg instead of a HashSet, but that's an API change) 14:34 < dr-orlovsky> andytoshi: fixed #306 in secp according to your comment. Re next bitcoin release, can we have it ASAP as we merge all taproot related stuff? I'd really like to get it working on signet before mainnet activation 14:36 < devrandom> BlueMatt: actually, we could have a new style `from_header_txids_predicate` with the function arg, and leave the current `from_header_txids` signature as it is. so that would be adding an API method, which is doesn't require a major rev? 14:37 < BlueMatt> oh, thats true, and then just dont expose the old ones? 14:37 < BlueMatt> I mean all of this is a bit naval gazing 14:37 < devrandom> right 14:37 < BlueMatt> one major bump for a part of the api that isn't likely to be used in no_std immediately (or any time soon) 14:37 < BlueMatt> its not a big deal either way. 14:38 * BlueMatt -> dinner 14:38 < BlueMatt> see y'all 14:38 < devrandom> I'm good with either 14:38 < devrandom> off to bed, LMK what's the consensus 14:39 < BlueMatt> I think you pick :p 14:41 < andytoshi> i like the idea of exposing a new function and un-exposing (when nostd) the old one 14:41 < andytoshi> thanks dr-orlovsky. not sure why CI is still failing tho 14:42 < dr-orlovsky> checking that 14:43 < andytoshi> ohh 14:43 < andytoshi> it's that you added new functions but didn't create fuzz stubs for them 14:45 < andytoshi> dr-orlovsky: i think you can just move the new FFI definitions out of the big #[cfg(fuzzing)] block 14:45 < dr-orlovsky> yeah, seems that can be a reason 14:47 < dr-orlovsky> fixed that and force-pushed 14:57 < dr-orlovsky> works now 15:04 < andytoshi> dope 17:06 -!- belcher_ [~belcher@user/belcher] has joined #bitcoin-rust 17:10 -!- belcher [~belcher@user/belcher] has quit [Ping timeout: 252 seconds] 23:58 < devrandom> OK, 603 is now non-API-breaking, but I deprecated the two `HashSet` referring functions --- Log closed Sat Jun 19 00:00:43 2021