synchronize BIP 77 with code

[nothingmuch]

The BIP 77 spec is not fully up to date with these changes:

• short IDs
• uppercase bech32 fragment parameters
• RK1 fragment parameter
• ellswift encoding in DHKEM, bit uniformity of payload
• ensure DHKEM is sufficiently documented in BIP 77 in an unambiguous spec, since it's a draft RFC now
• padding rules for inner and outer messages

Additionally the document can be improved:

• UI/UX and privacy tradeoffs of relay and directory choices
• diagrams for byte representations of the payloads
• ascii sequence diagram to plantuml?
• Describe bip21 as a potential bootstrap mechanism where TLS is unavailable

[DanGould]

I started pushing these changes to a secondary branch so I don't interrupt the reviewers until we're ready for a review. FYI

Note that Short IDs likely also need to be uppercase since they're parsed as having a case-sensitive bech32 HRP in our code, too

[nothingmuch]

Note that Short IDs likely also need to be uppercase since they're parsed as having a case-sensitive bech32 HRP in our code, too

Yes, with the same rationale as fragment parameter, although the # character is not in the QR alphanumeric set, since it's % escaped according to RFC 3986 reccomendation to make the hex encoding uppercase, the run of alphanumeric QR code characters potentially starts at the beginning of the entire parameter, and lowercase shortid would break that

[DanGould]

ensure DHKEM is sufficiently documented in BIP 77 in an unambiguous spec, since it's a draft RFC now

77 links to the draft RFC. What more would make it sufficiently unambiguous?

====Secp256k1-based DHKEM====

[[https://www.ietf.org/archive/id/draft-wahby-cfrg-hpke-kem-secp256k1-01.html| Secp256k1-based DHKEM for HPKE]] is most appropriate because of secp256k1's availability in bitcoin contexts.

[DanGould]

Pushed changes to the secondary branch