News165: edits to darosior section for jnewbery feedback (thanks!)

Author: harding

_includes/specials/taproot/en/11-vaults-with-taproot.md

@@ -29,9 +29,9 @@ due to the use of merkle branches and shorter BIP340 signatures (especially for
 For instance, the *unvault* output script in a multi-party setup with 6 "cold" keys and 3 "active" keys
 (with a threshold of 2) could be represented as a Taproot of depth 2 with leaves:
 
-- `<X> CSV <active key 1> CHECKSIGADD <active key 2> CHECKSIGADD 2 EQUAL`
-- `<X> CSV <active key 2> CHECKSIGADD <active key 3> CHECKSIGADD 2 EQUAL`
-- `<X> CSV <active key 3> CHECKSIGADD <active key 1> CHECKSIGADD 2 EQUAL`
+- `<X> CSV DROP <active key 1> CHECKSIGADD <active key 2> CHECKSIGADD 2 EQUAL`
+- `<X> CSV DROP <active key 2> CHECKSIGADD <active key 3> CHECKSIGADD 2 EQUAL`
+- `<X> CSV DROP <active key 3> CHECKSIGADD <active key 1> CHECKSIGADD 2 EQUAL`
 - `<cold key 1> CHECKSIGADD <cold key 2> CHECKSIGADD <cold key 3> CHECKSIGADD <cold key 4> CHECKSIGADD <cold key 5> CHECKSIGADD <cold key 6> CHECKSIGADD 6 EQUAL`
 
 This is about 76.5 vbytes for the cheapest (happy) spending path and about 176.0 vbytes for the costliest (dispute) one.
@@ -55,14 +55,17 @@ Finally, vault protocols, like most pre-signed transactions protocols, would lar
 further proposed Bitcoin upgrades based on taproot such as [BIP118][]'s [SIGHASH_ANYPREVOUT][topic sighash_anyprevout]. Although requiring further caution
 and protocol tweaks, `ANYPREVOUT` and `ANYPREVOUTANYSCRIPT` would enable rebindable *cancel*
 signatures, which could largely reduce interactivity and allow 0(1) signature storage. This is
-particularly interesting for the *emergency* signature in the Revault protocol, as it would largely
-reduce the DoS attack surface. `ANYPREVOUTANYSCRIPT` signatures would also enable some forms of
-covenants that could eventually be made more flexible by the introduction of new sighash types.
+particularly interesting for the *emergency* signature in the [Revault protocol][], as it would largely
+reduce the DoS attack surface.  By having an `ANYPREVOUTANYSCRIPT` signature in an output you are
+effectively creating a covenant by restricting how the transaction
+spending this coin can create its outputs. Even more customizable
+future signature hashes would permit more flexible restrictions.
 
 [^0]:
     If known in advance you could pre-sign the *spend* transaction with a specific nSequence, but then
     you don't need an alternative spending path with "active" keys at all. Also, you don't usually know
     how you are going to spend your coins by the time you receive them.
 
 [darosior]: https://github.com/darosior
-[revault]: https://revault.dev/
+[revault]: https://github.com/revault
+[revault protocol]: https://github.com/revault/practical-revault/raw/master/revault.pdf