Create Taproot feature and introduce signer type enum (channel, sign)

https://github.com/lightningdevkit/rust-lightning/pull/2289

Host: vladimirfomene  -  PR author: arik-so

Notes

  • Simple Taproot Channels is a proposal - in the form of an Extension BOLT to BOLTs 2, 3, and 5 - that aims to upgrade the funding and commitment design of (V1 established) Lightning channels by using BIP 327 MuSig2, an n-of-n multisignature scheme with BIP 340 Schnorr signatures. In the case of Lightning, this is currently and specifically 2-of-2.
  • The most obvious change for Simple Taproot Channels is the funding output being a P2TR instead of the currently used P2WSH. In a cooperative close, and considering a large enough anonymity set, this would improve privacy as the close will just resemble a single-sig key-path spend.
  • LDK PR 2289 defines the feature bits for option_taproot in the appropriate feature contexts.

Questions

  1. Did you review the PR? Concept ACK, approach ACK?
  2. Why do Lightning features always reserve a pair of bits when defined?
  3. Open question: Why is it helpful to just define the option_taproot feature in LDK at this point in time? Alternatively, why is there no harm in doing so?
  4. Which feature bit pair is reserved for option_taproot? In which contexts can this feature appear?
  5. For each feature context mentioned before, can you explain why the feature is relevant to that context (what it’s used for)?
  6. Which of the specified contexts are not currently relevant to Simple Taproot Channels and why?
  7. What does the ChannelSignerType describe and why is it introduced?