I propose we split some parts of rust-bitcoin into multiple crates:

• bitcoin-encoding which has all the string encodings that bitcoin uses: base58, base58check, bech32, bech32m, base64, hex
  • this would collapse base64_compat, bech32-bitcoin, byteorder all into one dep that we control. maybe also bech32.
  • would also let us write a unified interface to all these
  • an allmost-natural place for us to stick the endianness code :P
  • potentially could be a dep of rust-secp, letting us encode keys and base64 signatures the way users expect
  • lets us deal with the unique no_std difficulties around string encoding in one place
• bitcoin-primitives which defines block/transaction/script, and the p2p messages, and the consensus::Encodable trait
  • lets users parse/serialize bitcoin stuff without needing rust-secp and the rest of the massive dep tree. see e.g. Make secp256k1 optional #527
  • similar benefits to the above wrt no_std, lets us deal with Vec encoding and use of io::Write in one place (ok, two places, bitcoin_hashes has the same dependency on io)
• bitcoin-keys which deals with private/public keys, addresses, bech32, taproot, as well as computing sighashes. I think this is the only one that'd require a rust-secp dependency
• bitcoin-psbt

I think this covers all the contents of the library. Then the main "bitcoin" crate would simply have optional deps on all of the above and re-export everything from them.