fixup! bolt-simple-taproot: taprooty level 1

Author: Roasbeef

bolt-simple-taproot.md

@@ -324,7 +324,7 @@ will use to _verify_ a new incoming commitment state sent by the remote party.
 In order to force close a channel, the holder of a verification nonce must use
 that same nonce to counter sign the commitment transaction with the other half
 of the musig2 partial signature. Rather than force an implementation to retain
-additional signing state (the verification nonce) to avoid holding as "hot"
+additional signing state (the verification nonce) to avoid holding a "hot"
 (fully broadcast able) commitment on disk, we instead recommend a counter based
 approach.
 
@@ -366,7 +366,7 @@ reproduced:
      the ASCII string `taproot-rev-root`.
 
   3. Given a commitment height/number (`N`), the verification nonce to send to
-     the remote party party can be derive by obtaining the `Nth` shachain leaf
+     the remote party party can be derived by obtaining the `Nth` shachain leaf
      preimage `k_i`. The verification nonce to be derived by calling the
      `musig2.NonceGen` algorithm with the required values, and the `rand'`
      value set to `k_i`.
@@ -481,10 +481,10 @@ The remote output of the commitment transaction uses the `combined_funding_key`
 as the top-level internal key, and then commits to a normal remote script.
 
 Anchor outputs use the `local_delayedpubkey` and the `remotepubkey` of both
-parries as the top-level
-internal key committing to the script `16 CSV`. Unless active HTLCs exist on
-the commitment transaction, if a local or remote output is missing from the
-commitment, its corresponding anchor must not be present, either.
+parties as the top-level internal key committing to the script `16 CSV`. Unless
+active HTLCs exist on the commitment transaction, if a local or remote output
+is missing from the commitment, its corresponding anchor must not be present,
+either.
 
 All HTLC scripts use the revocation key as the top-level internal key. This
 allows the revocation to be executed without additional on-chain bytes, and
@@ -500,8 +500,8 @@ placed in the `init` message, and the `node_announcement` message.
 
 | Bits  | Name                             | Description                                               | Context  | Dependencies      | Link                                  |
 |-------|----------------------------------|-----------------------------------------------------------|----------|-------------------|---------------------------------------|
-| 80/81 | `option_simple_taproot`| Node supports simple taproot channels | IN | `option_channel_type`+`option_anchors` | TODO(roasbeef): link |
-| 180/181 | `option_simple_taproot_staging`| Node supports simple taproot channels | IN | `option_channel_type`+`option_anchors` | TODO(roasbeef): link |
+| 80/81 | `option_simple_taproot`| Node supports simple taproot channels | IN | `option_channel_type` | TODO(roasbeef): link |
+| 180/181 | `option_simple_taproot_staging`| Node supports simple taproot channels | IN | `option_channel_type` | TODO(roasbeef): link |
 
 Note that we allocate _two_ pairs of feature bits: one the final version of
 this protocol proposal, and the higher bits (+100) for preliminary experimental
@@ -583,7 +583,7 @@ The sending node:
   - MUST specify the `next_local_nonce` field.
   - MUST use the `NonceGen` algorithm defined in `bip-musig2` to generate
     `next_local_nonce` to ensure it generates nonces in a safe manner.
-  - MOST not set the `announce_channel` bit.
+  - MUST not set the `announce_channel` bit.
 
 The receiving node MUST fail the channel if:
 
@@ -626,9 +626,6 @@ The recipient:
   - MUST reject the channel if `next_local_nonce` is absent, or cannot be
     parsed as two compressed secp256k1 points
 
-  - the specified public nonce cannot be parsed as two compressed secp256k1
-    points
-
 #### `funding_created` Extensions
 
 1. `tlv_stream`: `funding_created_tlvs`
@@ -755,7 +752,7 @@ The recipient:
 
 ### Cooperative Closure
 
-Compared to the base segwit v0 channel type, for simple taproot channels, then
+Compared to the base segwit v0 channel type, for simple taproot channels, the
 co-op close transaction now always signals RBF. In other words, the sequence
 field of the sole input to the cooperative close transaction MUST be
 less-than-or-equal to `0xfffffffd`. This enables a future cooperative closure
@@ -781,7 +778,7 @@ A new TLV field is added to the `shutdown` message:
 1. `tlv_stream`: `shutdown_tlvs`
 2. types:
     1. type: 8 (`shutdown_nonce`)
-    2: data:
+    2. data:
         * [`66*byte`:`nonces`]
 
 Before a signature can be generated for a co-op close transaction, both sides
@@ -812,7 +809,7 @@ message's existing `tlv_stream`:
 2. types:
    1. type: 6 (`partial_signature`)
    2. data:
-      * [`32*byte`: `partial_signature`
+      * [`32*byte`: `partial_signature`]
 
 Both sides **MUST** provide this new TLV field.
 
@@ -877,17 +874,15 @@ sort of fee rate negotiation. The regular segwit v0 channels permit either side
 to accept a prior offer by a peer that it would have accepted in the current
 round. For musig2, as each signature comes with nonce state, the prior offer
 may actually be using distinct nonce state, rendering it unable to be comined
-for the final transaction braodcast.
+for the final transaction broadcast.
 
 Instead, the responder will simply accept what the initiator proposes. The
 responder can always CPFP after the fact if they require a higher fee rate. The
 initiator is the one that pays fees directly (coming out of their settled
-output), so the responder will always have their full funds develiered to them.
+output), so the responder will always have their full funds delivered to them.
 This change ensures that cooperative close always succeeds after a single
 round.
 
-
-
 ### Channel Operation
 
 `n_a_L`: Alice's local secret nonce
@@ -1073,9 +1068,9 @@ The new output has the following form:
     * `to_delay_script_root = tapscript_root([to_delay_script, revoke_script])`
     * `to_delay_script` is the delay script:
         ```
-        <local_delayedpubkey> OP_CHECKSIG
-        <to_self_delay> OP_CHECKSEQUENCEVERIFY OP_DROP
-    * `revoke_script` is the delay script:
+        <local_delayedpubkey> OP_CHECKSIGVERIFY
+        <to_self_delay> OP_CHECKSEQUENCEVERIFY
+    * `revoke_script` is the revoke script:
         ```
         <local_delayedpubkey> OP_DROP
         <revocation_pubkey> OP_CHECKSIG
@@ -1122,7 +1117,7 @@ to achieve this property, we'll utilize a NUMS point (`simple_taproot_nums`) By
 using this point as the internal key, we ensure that the remote party isn't
 able to by pass the CSV delay.
 
-Using a NUMS key has a key benefit: the static internal key allows the remote
+Using a NUMS key has a key benefit: the static internal key allows the remote 
 party to scan for their output on chain, which is useful for various recovery
 scenarios.
 
@@ -1135,8 +1130,8 @@ The `to_remote` output has the following form:
     * `to_remote_script_root = tapscript_root([to_remote_script])`
     * `to_remote_script` is the remote script:
         ```
-        <remotepubkey> OP_CHECKSIG
-        1 OP_CHECKSEQUENCEVERIFY OP_DROP
+        <remotepubkey> OP_CHECKSIGVERIFY
+        1 OP_CHECKSEQUENCEVERIFY
         ```
 
 This output can be swept by the remote party with the following witness:
@@ -1204,8 +1199,8 @@ An offered HTLC has the following form:
     * `htlc_success`:
         ```
         OP_SIZE 32 OP_EQUALVERIFY OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
-        <remote_htlcpubkey> OP_CHECKSIG
-        1 OP_CHECKSEQUENCEVERIFY OP_DROP
+        <remote_htlcpubkey> OP_CHECKSIGVERIFY
+        1 OP_CHECKSEQUENCEVERIFY
         ```
 
 In order to spend a offered HTLC, via either script path, an `inclusion_proof`
@@ -1222,9 +1217,9 @@ Accepted HTLCs inherit a similar format:
     * `htlc_script_root = tapscript_root([htlc_timeout, htlc_success])`
     * `htlc_timeout`:
         ```
-        <remote_htlcpubkey> OP_CHECKSIG
-        1 OP_CHECKSEQUENCEVERIFY OP_DROP
-        <cltv_expiry> OP_CHECKLOCKTIMEVERIFY OP_DROP
+        <remote_htlcpubkey> OP_CHECKSIGVERIFY
+        1 OP_CHECKSEQUENCEVERIFY OP_VERIFY
+        <cltv_expiry> OP_CHECKLOCKTIMEVERIFY
         ```
     * `htlc_success`:
         ```
@@ -1276,8 +1271,8 @@ A HTLC-Success transaction has the following structure:
         * `htlc_script_root = tapscript_root([htlc_success])`
         * `htlc_success`:
         ```
-        <local_delayedpubkey> OP_CHECKSIG
-        <to_self_delay> OP_CHECKSEQUENCEVERIFY OP_DROP
+        <local_delayedpubkey> OP_CHECKSIGVERIFY
+        <to_self_delay> OP_CHECKSEQUENCEVERIFY
         ```
 
 ##### HTLC-Timeout Transactions