Jeff Burdges

We've always wanted some mandatory processing of messages, so parachains cannot screw up whatever messaging demands mandatory execution. I've no idea why XCM should be able to execute any runtime...

I'm anyways dubious if the relay chain should be the transport for any non-mandatory messages, aka if XCM should do this. Instead, why not fork XCM into some best effort...

I know some projects are waiting on more from [`#![feature(generic_const_exprs)]`](https://github.com/rust-lang/rust/issues/76560) but.. If possible you should really switch from typenum to const generics of course.

We proved roughly the same result in https://eprint.iacr.org/2020/1245 too, so although proofs get mildly subtle quite a few people have now convinced themselves that this is secure. I deployed this...

I picked the `"sign:"` prefix because of https://github.com/w3f/schnorrkel/issues/39 In fact I believe that's not a serious concern, but adjusting seemed easier than checking any details at the time.

It's true "SigningContext" kinda sucks. :( I originally asked users to supply the label, but then this happened hastily: https://github.com/dalek-cryptography/merlin/pull/44

Inside the protocol `'static` labels work fine, of course. It's just when dynamic languages want to create a transcript that you encounter problems: https://github.com/paritytech/schnorrkel-js/issues/12 As an aside, I needed [this](https://github.com/w3f/schnorrkel/blob/master/src/sign.rs#L127)...

I suppose not really.. I wanted us to use stronger domain separation everywhere in polkadot, but others preferred Blake2 and no Blake2 STROBE variant exists, and we support other signature...

Are all these commits sequenced identically?

You might glance at the distributions stuff from the rand crate, probably not quite right here but worth a quick look.