NIP-41: Key Invalidation; using HD (BIP32) derivation

[optout21]

• This proposed PR is a refinement of the existing NIP-41 PR, NIP-41: Key Invalidation. first draft. #158.
  It attempts to solve the exact same problem, using the very same high level approach, but using a different approach for key derivation.

• Viewable version of the NIP is here: https://github.com/catenocrypt/nips/blob/nip41-hd/41.md

• I have created a new PR, as opposed to commenting/editing the existing one, mostly due to the fact that the key generation cryptography is different, and this is at the heart of the scheme.
  But I fully acknowledge that the idea and solution was laid out in the original PR, and if the original authors prefer, I'm fine with incorporating these changes to the original PR.
  I view this mainly a technical aspect (github).

• A prototype implementation is available here: https://github.com/catenocrypt/nip41-hd-proto/

• The similarities and differences of this scheme to the original PR:

  • Solves the same original issue
  • Basic ideas of a chain of pre-generated set of keys, using the last, rotating to the previous, etc. are the same
  • The way to generate one key from the previous is different, here using 'standard' BIP32 derivation, though the basic layout is the same (key part, extra part, taking a hash of the concatenation).
  • The original scheme uses a (32-byte) 'hidden' public key. Here that is perfectly analogue to the 32-byte chain code of the extended key. One detail is that the chain code (analogue to the hidden key) can be represented as a hex string (though npub notation could also be used for it).
  • One difference is that in the original scheme, when invalidating key N and rotating to N-1, the hidden part of N is revealed. In this scheme it is the chain code of N-1. However, this is not a big difference, if one was to shift the hidden keys by one index, then the end result would be the same.
  • The generation of the 0th key is also different (using a derivation path as opposed to just taking the seed)

• An important question is a security analysis of how previously generated keys cannot be reconstructed, especially that chain code part of the new keys is published.
  The short answer is that with a chain code compromised, it is possible to reconstruct other siblings and all descendants, but not ancestors.
  An analysis should be added to the NIP text.