02:18:31 j​babb:cypherstack.com: I'm using cuprate's cryptonight implementation by vendoring (copying) it into my current project. I don't like that for multiple reasons (I'd like to avoid copying things, I have to consider the licensing implication even tho I'm working open source, and it introduces maint concerns), any chance it could be made a library API? or extracted into its own crate or exposed as public?
02:18:33 j​babb:cypherstack.com: I would volunteer to do so if this would be a worthwhile contribution, but also, just copying it has worked and I'm maintaining attribution and will make sure the licensing is maintained
02:19:09 k​ayabanerve:matrix.org: build script to git clone, cut out the file, install as the built crate?
02:19:11 k​ayabanerve:matrix.org: there's worse ideas as far as hacks go while waiting for upstream to improve
02:19:20 j​babb:cypherstack.com: it works fine to copy and paste for now and then at least upstream changes won't break what I have going on
02:19:21 j​babb:cypherstack.com: it's just not an elegant clean solution we all love
02:20:16 j​babb:cypherstack.com: I'm using cuprate's cryptonight implementation by vendoring (copying) it into my current project. I don't like that for multiple reasons (I'd like to avoid copying things, I have to consider the licensing implication even tho I'm working open source, and it introduces maint concerns), any chance it could be made a library API or the crate published?
02:29:42 b​oog900:monero.social: Monero.social went down so meeting was missed yesterday. Hopefully we have more luck next week :)
02:31:45 b​oog900:monero.social: It is already you should be able to just point to it as a git cargo dependency
02:32:25 j​babb:cypherstack.com: yep, that works but blocks publishing. not a big deal for awhile tho
02:35:40 b​oog900:monero.social: Ah yeah, it should be easy to publish, it doesn't depend on any other crate so I'll publish it tomorrow
02:36:32 j​babb:cypherstack.com: I'm also using unpublished monero-oxide and monero-wallet-util crates so it's not like that crate's the only blocker to publishing, but that'd be great thanks :)
07:39:13 k​ayabanerve:matrix.org: have you considered that we aren't lazy for not publishing to crates.io, we're mindful about decentralized package management and the git protocol is the true spirit of FOSS, without requiring a specific centralized intermediary? Hm?
07:39:44 k​ayabanerve:matrix.org: /s. We have an open issue to tag 1.0 for oxide and below. I mentally put off crates.io until after that. I also have forgotten about that issue.
07:40:19 k​ayabanerve:matrix.org: Iirc, we're no longer binding to curve25519-dalek/rand_core and could rc.0 ed25519, io, and go from there?
07:40:40 k​ayabanerve:matrix.org: primitives is silly as it's now just... what is it even now? Just the `Bound` type definition?
07:41:14 k​ayabanerve:matrix.org: But as there's no better place for it, I'm fine signing off on that
07:41:30 k​ayabanerve:matrix.org: The ringct libs other than clsag should be without issue, which brings us to oxide proper.
07:42:41 k​ayabanerve:matrix.org: The new RPC lib caused a bunch of tweaks, but that's merged now...
07:42:48 k​ayabanerve:matrix.org: So we can probably focus on this again?
11:10:16 b​inarybaron:matrix.org: I have not (for the sake of simplicity)
11:10:35 b​inarybaron:matrix.org: Totally makes sense.
11:11:07 k​ayabanerve:matrix.org: Protocols which fail to differentiate successful decryptions from invalid ones, ignoring all questions descending as 'not my problem', are definitely simpler.
11:11:31 k​ayabanerve:matrix.org: If only someone had combined a stream cipher with a MAC to create a simple way to do both encryption _and_ authentication...
11:11:40 k​ayabanerve:matrix.org: (Chacha20Poly1305)
11:11:42 k​ayabanerve:matrix.org: :p
11:12:41 b​inarybaron:matrix.org: I admit this is not really my area of expertise but it does sound like that it’d be a better option :p
11:12:46 b​inarybaron:matrix.org: I’ll trust you on this
11:13:08 k​ayabanerve:matrix.org: It isn't something I'll harass you about, as you so have a specific use-case in mind. Some way to assert a message was meant to be decrypted, and it isn't simply random bytes which were attempted to be decrypted, with stronger guarantees than 'the first byte was the letter H', may be beneficial though.
11:13:27 b​inarybaron:matrix.org: Are you planning to move away from curve dalek entirely?
11:14:28 k​ayabanerve:matrix.org: No, yet we were in a weird place because curve25519-dalek uses the current-gen crypto libs while the next-gen has had rc's for... 6+ months?
11:14:53 k​ayabanerve:matrix.org: So we also had to indefinitely wait, or we had to not expose our usage of curve25519-dalek so we could upgrade it internally without undergoing a breaking change.
11:16:19 b​inarybaron:matrix.org: We currently need to handle both curve dalek ng (fork) and the curve dalek crate in our repo due to monero-oxides usage of it and the usage of the other fork crate in one of our DLEQ libraries
11:16:26 k​ayabanerve:matrix.org: rand_core 0.6 instead of 0.9, digest 0.10 instead of 0.11, ff/group 0.13 instead of 0.14, generic-array instead of flexible-array, etc.
11:16:52 k​ayabanerve:matrix.org: Ugh. You know Serai did a cross-group DLEq over the ff/group APIs, right?
11:17:23 k​ayabanerve:matrix.org: So it'll work with curve25519-dalek and k256 out of the box.
11:18:03 k​ayabanerve:matrix.org: It's also optimized, achieving 10% better performance and bandwidth, or some more opinionated trade-offs (like even faster perf yet with even more bandwidth).
11:21:07 b​inarybaron:matrix.org: I think the library that implements ECDSA adaptor signatures (ecdsa_fun) uses sigma_fun which also uses dalek ng
11:21:19 b​inarybaron:matrix.org: Unless you also have an adaptive signatures implementation … :p
11:21:37 b​inarybaron:matrix.org: Unless you also have an adaptor signatures implementation … :p
11:23:00 Cindy_: kayabanerve: i've had to use a mix of curve25519-dalek and monero-ed25519 because the scalar struct doesn't expose enough functions
11:23:11 Cindy_: like constructing a scalar from bytes modulo l
11:23:21 Cindy_: unless i didn't read docs
11:23:24 k​ayabanerve:matrix.org: No to having adaptor signatures, binarybaron
11:23:30 k​ayabanerve:matrix.org: Cindy_: That was the point.
11:24:43 k​ayabanerve:matrix.org: It has a minimal API because it's an API we're able to commit to for the next year, without concern. If we provided a function to, say, randomly sample a scalar, we'd have to ask rand_core 0.6, 0.9, or 0.10.0.rc
11:25:10 k​ayabanerve:matrix.org: We could reasonably expose arithmetic. We haven't done so at this time however.
13:04:38 b​oog900:monero.social: I have posted a CCS update: https://repo.getmonero.org/monero-project/ccs-proposals/-/merge_requests/611#note_33930
13:58:17 s​yntheticbird:monero.social: sub hour sync
13:58:30 s​yntheticbird:monero.social: I need time and nutrients to sink that in
13:59:34 b​oog900:monero.social: it feels good to finally be there, sub-hour has been a goal for a while.
14:04:31 Cindy: sub hour sync?
14:05:21 b​oog900:monero.social: syncing a node in under an hour.
14:05:22 s​yntheticbird:monero.social: sub hour sync
14:05:36 Cindy: oh wow
14:05:45 s​yntheticbird:monero.social: the formal definition is "Syncing the blockchain during shower time"
14:05:46 Cindy: does that factor in internet? orr
14:05:54 Cindy: just like a local node in the same network
14:06:45 b​oog900:monero.social: it was a sync how you would do a sync using real nodes on the network. Obviously you need the bandwidth for it though.
14:07:26 Cindy: is the subhour factoring in unlimited bandwidth?
14:07:42 Cindy: and like as fast as possible connection to another node
14:08:01 k​ayabanerve:matrix.org: SyntheticBovinae: The existing monerod syncs the entire blockchain in the time it takes me to take a shower.
14:08:33 k​ayabanerve:matrix.org: I mean, sure, I'm just crying for several hours of that, but the point of the shower is no can tell you're crying.
14:08:59 s​yntheticbird:monero.social: image.png
14:09:01 s​yntheticbird:monero.social: leaked photo of kayabanerve
14:09:01 Cindy: mood
14:09:02 b​oog900:monero.social: no, the machine that did it has gigabit bandwidth, the sub hour sync was a real sync, using a real system without any special connections to other nodes, just the internet.
14:09:19 Cindy: oh i see
14:09:28 s​yntheticbird:monero.social: LMFAO
14:09:52 b​oog900:monero.social: it was literally just me running cuprated, like you would run monerod.
14:10:34 s​yntheticbird:monero.social: Next step is testing with RAID 0 8x U.3 14Gb/s SSDs, 64 threads 5GHz and 800Gb/s ethernet
14:11:08 Cindy: like of course, if we need to measure how long it takes to sync
14:11:13 Cindy: we need to establish some speedrunning rules
14:11:36 s​yntheticbird:monero.social: true
14:11:40 s​yntheticbird:monero.social: speedrun leaderboard for sync when