Jeff Burdges

I miss-typed above `%` has high multiplicative precedence in programming, but I wrote it like `mod` which has precedence below addition in mathematics, oops. I'd think `relay_parent_slot_no` spreads work more...

Initially, I'd everyone using their own VRF in the tit-for-tat, so that nobody knew from who honest people fetch, but.. - this gives no "security" property per se, merely avoids...

We'd never widely "gossip" PoV blocks under any circumstances, as that'd be *extremely* inefficient. We do "gossip" parablocks among parachain nodes aka collators, but among the parachain nodes these parablocks...

We're clearly happy to pay for someone to work on set reconciliation via BCH codes in Rust of course, maybe @drahnr

Apologies again for being gruff there. We want good abstractions that makes building p2p networks easier, but afaik they do not appear to be as simple as things like eagerness...

We're about to do a new VRF, likely called VRedJubJub, that'll we'll need to support as well, and of course BLS signatures, but they do not add as much complexity...

We'd prefer doing this by features, not adding some new `Signer` trait to every substrate crate, right? We've [no roadmap](https://rust-lang.github.io/async-book/07_workarounds/06_async_in_traits.html) for async fns in traits of course, but this holds...

I donno if https://github.com/iqlusioninc/armistice is relevant, but maybe good to track if you'd working on this stuff

I've increasingly realized that block seals should probably use the `extra` arguments to VRFs in https://github.com/w3f/schnorrkel/blob/master/src/vrf.rs not a separate signature, but not worth the effort required to change this since...

We've several major projects that shall further change the session key crypto: beefy, including optimized signing, sassafras, including ring VRFs and ephemeral block signing keys, new session certificates for shashing...