When attempting to support no_std in ln-types I found out that no-std makes it problematic:

• It essentially requires re-exporting this feature in the consuming libraries (and the consumers of consumers and so on...)
• It will not work well with the upcoming weak dependency features because the intention was for depending library to provide std = ["bitcoin?/std"] so that the number of features doesn't blow up.
• The feature is irrelevant for consumers that only use things without IO or allocation (e.g. Amount) so it's not nice to force it.

Proposed solution:

• Finer feature gating - disable blockdata and other things without alloc
• Either disable consensus encoding without either std or core2 or depend on core2 unconditionally (it reexports std) or use other crate or NIH io traits (and change encoding traits). As a byproduct of this we could get rid of .expect("hash engines don't err").
• Use dependency inversion to avoid dependency on hashbrown