News165: edits to darosior section

Author: jnewbery

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

@@ -1,11 +1,12 @@
 *By [Antoine Poinsot][darosior], [Revault][] developer*
 
-Bitcoin [vaults][topic vaults] are contracts that can reveal to a
-user that one or more of their signing keys has been obtained by an
-attacker, and which may allow the user to prevent the attacker from
-spending some or all of the user's funds.  Numerous such protocols have been
-proposed (single or multi-party, with or without [covenants][topic covenants]) so we'll focus on what they have in
-common. Contrary to [batched payments][topic payment batching] that execute multiple payments with a single onchain transaction,
+Bitcoin [vaults][topic vaults] are a type of contract that require two sequential
+transactions for a user to spend money from their wallet. Numerous such
+protocols have been proposed (single or multi-party, with or
+without [covenants][topic covenants]) so we'll focus on what they have in
+common.
+
+Contrary to [batched payments][topic payment batching] that execute multiple payments with a single onchain transaction,
 vaults use multiple transactions to execute a single payment. The first transaction, the *unvault*, pays
 to either:
 
@@ -21,10 +22,13 @@ Rather the opposite. The *spend* transaction must use the taproot script
 sending path, since it is encumbered by the relative timelock[^0] while the
 *cancel* transaction could in theory use the key spending path.
 
-Already requiring a lot of interactivity in practice, multi-party vaults can benefit from [Musig2][topic musig]
-and future key aggregation proposals made possible by [BIP340][]. However, these schemes come with new
+Since multi-party vaults already require a lot of interactivity in practice,
+they could theoretically benefit from interactive [multisignature][topic
+multisignature] and [threshold signature][topic threshold signature] schemes made
+possible by [BIP340][], such as [Musig2][topic musig]. However, these schemes
+come with new
 safety challenges. Since vault protocols are intended to be used for cold
-storage, the design choices are more conservative and would probably be the
+storage, the design choices are more conservative and vaults would probably be the
 last to use these new technologies.
 
 By switching to taproot, vaults would also benefit from a slight privacy and efficiency improvement
@@ -37,8 +41,13 @@ For instance, the *unvault* output script in a multi-party setup with 6 "cold" k
 - `<X> CSV DROP <active key 3> CHECKSIG <active key 1> CHECKSIGADD 2 EQUAL`
 - `<cold key 1> CHECKSIG <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.
-Compared to the roughly 134.75 vbytes (happy) and 189.5 vbytes (dispute) by using the following P2WSH:
+<!-- TODO: recalculate spending costs
+This is about xxxx vbytes for the cheapest (happy) spending path and about xxxx vbytes for the costliest (dispute) one.
+Compared to the roughly xxxx vbytes (happy) and xxxx vbytes (dispute) by using the following P2WSH: -->
+
+In taproot, only the leaf being used to spend the output needs to be revealed,
+so the transaction weight is considerably smaller than for the equivalent P2WSH
+script:
 
 ```text
 IF