You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: _posts/2023-06-20-#2289.md
+18-6Lines changed: 18 additions & 6 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -5,16 +5,28 @@ title: "Create Taproot feature and introduce signer type enum"
5
5
pr: 2289
6
6
authors: [arik-so]
7
7
components: ["channel", "sign"]
8
-
host: dunxen
8
+
host: vladimirfomene
9
9
status: upcoming
10
10
commit:
11
11
---
12
12
13
-
_Notes and questions to follow soon!_
14
-
15
-
<!-- TODO: Before meeting, add notes and questions
16
13
## Notes
14
+
*[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
15
+
of (V1 established) Lightning channels by using [BIP 327] MuSig2, an n-of-n multisignature scheme with [BIP 340] Schnorr signatures.
16
+
In the case of Lightning, this is currently and specifically 2-of-2.
17
+
* 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,
18
+
and considering a large enough anonymity set, this would improve privacy as the close will just resemble a single-sig key-path spend.
19
+
* LDK PR 2289 defines the feature bits for `option_taproot` in the appropriate feature contexts.
17
20
18
21
## Questions
19
-
1. Did you review the PR? [Concept ACK, approach ACK, tested ACK, or NACK](https://github.com/lightningdevkit/rust-lightning/blob/master/CONTRIBUTING.md#peer-review)?
20
-
-->
22
+
1. Did you review the PR? [Concept ACK, approach ACK](https://github.com/lightningdevkit/rust-lightning/blob/master/CONTRIBUTING.md#peer-review)?
23
+
1. Why do Lightning features always reserve a pair of bits when defined?
24
+
1.**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?
25
+
1. Which feature bit pair is reserved for `option_taproot`? In which *contexts* can this feature appear?
26
+
1. For each feature context mentioned before, can you explain why the feature is relevant to that context (what it's used for)?
27
+
1. Which of the specified contexts are not currently relevant to Simple Taproot Channels and why?
28
+
1. What does the `ChannelSignerType` describe and why is it introduced?
0 commit comments