Jeff Burdges

We're fine to handle PRs by other parties, and publishing on crates.io if you prefer. I could do so if nobody else wants to, but first.. We'll ideally migrate to...

There is an error polynomial in an FFT decoder based upon the formal derivatives trick ala https://github.com/Bulat-Ziganshin/FastECC#faster which maybe still benefits from caching, but requires roughly the number of shards....

We're interested in the "perpendicular" situation with partial shards: We've an k-of-n encoding of a message of size m. We're using GF(2^16) since n>256, so each R-S polynomial contains exactly...

Yes. It's mostly an authentication question: How much do we want to make hashing and merkrle proofs overlap with the erasure coding? I suppose a shard type could expose an...

I suppose `ReedSolomon::new` gets somewhat heavy too, so maybe worth mentioning https://github.com/dermesser/memoize somewhere in the docs.

There are many parity devs who afaik are welcome to maintain what they like, but.. We abandoned the direct approaches here as being too slow for polkadot, due to us...

We made zero effort to be compatible, our interface remains unstable, and even our wire format could change with changing extension field optimizations, although polakdot demands a migration path. I've...

Any idea what is optimal here? We'd first want some fixed size bigint crate that avoids the `Vec` used by num-bigint? We'd then do SIMD support only for that crate?...

I prefer if symmetric cryptography overall transitioned to more flexible STROBE-like constructions, ala merlin, etc., and abstractions that permit judicious usage of asymmetric primitives, ala zk circuit friendly primitives, MuSig-DN,...

I took a direct approach to a VRF interface in https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs but the results proved disappointing. I'm experimenting with a new de-builder methods approach in https://github.com/w3f/ring-vrf/blob/master/src/schnorr.rs but maybe overly complex....