News241: harding section, describe alt-vault

_posts/en/newsletters/2023-03-08-newsletter.md

@@ -11,7 +11,85 @@ This week's newsletter FIXME:harding
 
 ## News
 
-- Sander's alt-VAULT FIXME:harding (waiting until Sunday to see if any replies)
+- **Alternative design for OP_VAULT:** Greg Sanders [posted][sanders
+  vault] to the Bitcoin-Dev mailing list an alternative design for
+  providing the features of the `OP_VAULT`/`OP_UNVAULT` proposal (see
+  [Newsletter #234][news234 vault]).  His alternative would add three
+  opcodes instead of two.  To provide an example:
+
+    - *Alice deposits funds in a vault* by paying a [taproot][topic
+      taproot] tree which contains at least two [tapscripts][topic
+      tapscript], one with her unvault tapscript and one with her freeze
+      tapscript, e.g. `tr(key,{trigger,freeze})`.
+
+      - The *trigger tapscript* contains her less-trusted authorization
+        conditions (such as requiring a signature from her hot wallet)
+        and an `OP_TRIGGER_FORWARD` opcode.  At the time she creates
+        this tapscript, she provides the opcode a *spend delay*
+        parameter, e.g. a relative timelock of 1,000 blocks (about 1
+        week).
+
+      - The *freeze tapscript* contains any authorization conditions
+        Alice wants to specify (including none at all) and
+        an `OP_FORWARD_DESTINATION` opcode.  At the time she creates
+        this tapscript, she also chooses her more-trusted authorization
+        conditions (such as requiring multiple signatures from multiple
+        cold wallets and hardware signing devices).  She provides the
+        opcode a commitment to those conditions in the form of a hash
+        digest.
+
+    - *Alice initiates an unvaulting* by spending the output received to
+      the above taproot tree (using it as an input) and choosing the
+      trigger tapscript.  At this time, she provides two additional
+      parameters to the `OP_TRIGGER_FORWARD` opcode, the index of the
+      output which will receive this input's funds and a hash-based
+      commitment to how she wants to be able to spend the funds later.
+      The opcode verifies that the indicated output of this transaction
+      pays a taproot tree similar to the one being spent except that the
+      trigger tapscript is replaced with a script using an
+      `OP_CHECKSEQUENCEVERIFY` (CSV) relative delay equal to the delay
+      specified previously (e.g., 1000 blocks) and an
+      `OP_FORWARD_OUTPUTS` opcode which includes Alice's commitment
+      hash.  The method of reconstructing the taproot tree is similar to
+      an earlier [covenant][topic covenants] proposal,
+      `OP_TAPLEAF_UPDATE_VERIFY` (see [Newsletter #166][news166 tluv]).
+
+    - *Alice completes the unvaulting* by waiting until the relative
+      timelock has expired and then spending the unvaulting output,
+      choosing the tapleaf with the `OP_FORWARD_OUTPUTS` opcode.  The
+      opcode verifies that the spending transaction's output amounts and
+      scripts hash to the same commitment Alice made in the previous
+      transaction.  In this case, Alice has successfully deposited funds
+      to a vault, begun an unvaulting, been forced to wait at least
+      1,000 blocks to allow her monitoring programs to verify she really
+      did want to spend the funds to the specified outputs, and
+      completed the spend.
+
+    - If something goes wrong, *Alice freezes the funds*.  She can do
+      this at any time up until an unvaulting is completed by simply
+      choosing to spend using the freeze tapscript from the output of
+      either the vaulting or initial unvaulting transactions.  Recall
+      that Alice explicitly placed the freeze tapscript in the vaulting
+      transaction, and note that it was implicitly carried over by the
+      transaction with initiated the unvaulting.
+
+  One of the advantages to users of this approach over the original
+  `OP_VAULT` design is that the freeze tapscript can contain any
+  authorization conditions Alice wants to specify.  In the `OP_VAULT`
+  proposal, anyone knowing the parameters chosen by Alice could spend
+  her funds to the freeze script.  That wasn't a security problem but it
+  could be annoying.  In Sanders's design, Alice could (for example)
+  require a signature from a very lightly protected wallet in order to
+  initiate a freeze---this would perhaps be enough of a burden to
+  prevent most griefing attacks but not enough of a barrier to prevent
+  Alice from quickly freezing her funds in an emergency.
+
+  Several other advantages are aimed at making the consensus-enforced
+  [vaulting protocol][topic vaults] easier to understand and verify as
+  safe.
+
+  As of this writing, Sanders's proposal had only received limited
+  discussion on the mailing list.
 
 - **New Optech Podcast:** the weekly Optech Audio Recap hosted on
   Twitter Spaces is now available as a podcast.  Each episode will be
@@ -64,3 +142,6 @@ Proposals (BIPs)][bips repo], and [Lightning BOLTs][bolts repo].*
 [core lightning 23.02rc3]: https://github.com/ElementsProject/lightning/releases/tag/v23.02rc3
 [lnd v0.16.0-beta.rc1]: https://github.com/lightningnetwork/lnd/releases/tag/v0.16.0-beta.rc1
 [podcast post]: /en/podcast-announcement/
+[sanders vault]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-March/021510.html
+[news234 vault]: /en/newsletters/2023/01/18/#proposal-for-new-vault-specific-opcodes
+[news166 tluv]: /en/newsletters/2021/09/15/#covenant-opcode-proposal