deploy: 83b682a

05/index.html

@@ -783,6 +783,7 @@
 
 <h1 id="nut-05-melting-tokens">NUT-05: Melting tokens<a class="headerlink" href="#nut-05-melting-tokens" title="Permanent link">&para;</a></h1>
 <p><code>mandatory</code></p>
+<p><code>used in: NUT-08, NUT-15</code></p>
 <hr />
 <p>Melting tokens is the opposite of minting tokens (see <a href="../04/">NUT-04</a>). Like minting tokens, melting is a two-step process: requesting a melt quote and melting tokens. Here, we describe both steps.</p>
 <p>In the first request the wallet asks the mint for a quote for a <code>request</code> it wants paid by the mint and the <code>unit</code> the wallet would like to spend as inputs. The mint responds with a quote that includes a <code>quote</code> id and an <code>amount</code> the mint demands in the requested unit. For the method <code>bolt11</code>, the mint includes a <code>fee_reserve</code> field indicating the reserve fee for a Lightning payment.</p>

07/index.html

@@ -864,6 +864,7 @@
 
 <h1 id="nut-07-token-state-check">NUT-07: Token state check<a class="headerlink" href="#nut-07-token-state-check" title="Permanent link">&para;</a></h1>
 <p><code>optional</code></p>
+<p><code>used in: NUT-17</code></p>
 <hr />
 <p>With the token state check, wallets can ask the mint whether a specific proof is already spent and whether it is in-flight in a transaction. Wallets can also request the witness data that was used to spend a proof.</p>
 <h3 id="token-states">Token states<a class="headerlink" href="#token-states" title="Permanent link">&para;</a></h3>

08/index.html

@@ -866,7 +866,8 @@
 
 
 <h1 id="nut-08-lightning-fee-return">NUT-08: Lightning fee return<a class="headerlink" href="#nut-08-lightning-fee-return" title="Permanent link">&para;</a></h1>
-<p><code>optional</code>, <code>depends on: NUT-05</code></p>
+<p><code>optional</code></p>
+<p><code>depends on: NUT-05</code></p>
 <hr />
 <p>This document describes how the overpaid Lightning fees are handled and extends <a href="../05/">NUT-05</a> which describes melting tokens (i.e. paying a Lightning invoice). In short, a wallet includes <em>blank outputs</em> when paying a Lightning invoice which can be assigned a value by the mint if the user has overpaid Lightning fees. This can be the case due to the unpredictability of Lightning network fees. To solve this issue, we introduce so-called <em>blank outputs</em> which are blinded messages with an undetermined value.</p>
 <p>The problem is also described in <a href="https://gist.github.com/callebtc/a6cc0bd2b6f70e081e478147c40fc578">this gist</a>.</p>

09/index.html

@@ -782,7 +782,8 @@
 
 
 <h1 id="nut-09-restore-signatures">NUT-09: Restore signatures<a class="headerlink" href="#nut-09-restore-signatures" title="Permanent link">&para;</a></h1>
-<p><code>optional</code> <code>used in: NUT-13</code></p>
+<p><code>optional</code></p>
+<p><code>used in: NUT-13</code></p>
 <hr />
 <p>In this document, we describe how wallets can recover blind signatures, and with that their corresponding <code>Proofs</code>, by requesting from the mint to reissue the blind signatures. This can be used for a backup recovery of a lost wallet (see <a href="./">NUT-09</a>) or for recovering the response of an interrupted swap request (see <a href="../03/">NUT-03</a>).</p>
 <p>Mints must store the <code>BlindedMessage</code> and the corresponding <code>BlindSignature</code> in their database every time they issue a <code>BlindSignature</code>. Wallets provide the <code>BlindedMessage</code> for which they request the <code>BlindSignature</code>. Mints only respond with a <code>BlindSignature</code>, if they have previously signed the <code>BlindedMessage</code>. Each returned <code>BlindSignature</code> also contains the <code>amount</code> and the keyset <code>id</code> (see <a href="../00/">NUT-00</a>) which is all the necessary information for a wallet to recover a <code>Proof</code>.</p>

10/index.html

@@ -840,6 +840,7 @@
 
 <h1 id="nut-10-spending-conditions">NUT-10: Spending conditions<a class="headerlink" href="#nut-10-spending-conditions" title="Permanent link">&para;</a></h1>
 <p><code>optional</code></p>
+<p><code>used in: NUT-11, NUT-14</code></p>
 <hr />
 <p>An ordinary ecash token is a set of <code>Proofs</code> each with a random string <code>secret</code>. To spend such a token in a <a href="../03/">swap</a> or a <a href="../05/">melt</a> operation, wallets include <code>proofs</code> in their request each with a unique <code>secret</code>. To autorize a transaction, the mint requires that the <code>secret</code> has not been seen before. This is the most fundamental spending condition in Cashu, which ensures that a token can't be double-spent.</p>
 <p>In this NUT, we define a well-known format of <code>secret</code> that can be used to express more complex spending conditions. These conditions need to be met before the mint authorizes a transaction. Note that the specific type of spending condition is not part of this document but will be explained in other documents. Here, we describe the structure of <code>secret</code> which is expressed as a JSON <code>Secret</code> with a specific format.</p>

11/index.html

@@ -953,7 +953,8 @@
 
 
 <h1 id="nut-11-pay-to-public-key-p2pk">NUT-11: Pay to Public Key (P2PK)<a class="headerlink" href="#nut-11-pay-to-public-key-p2pk" title="Permanent link">&para;</a></h1>
-<p><code>optional</code>, <code>depends on: NUT-10</code></p>
+<p><code>optional</code></p>
+<p><code>depends on: NUT-10</code></p>
 <hr />
 <p>This NUT describes Pay-to-Public-Key (P2PK) which is one kind of spending condition based on <a href="../10/">NUT-10</a>'s well-known <code>Secret</code>. Using P2PK, we can lock ecash tokens to a receiver's ECC public key and require a Schnorr signature with the corresponding private key to unlock the ecash. The spending condition is enforced by the mint.</p>
 <p>Caution: If the mint does not support this type of spending condition, proofs may be treated as a regular anyone-can-spend tokens. Applications need to make sure to check whether the mint supports a specific kind of spending condition by checking the mint's <a href="../06/">info</a> endpoint.</p>

13/index.html

@@ -896,7 +896,8 @@
 
 
 <h1 id="nut-13-deterministic-secrets">NUT-13: Deterministic Secrets<a class="headerlink" href="#nut-13-deterministic-secrets" title="Permanent link">&para;</a></h1>
-<p><code>optional</code> <code>depends on: NUT-09</code></p>
+<p><code>optional</code></p>
+<p><code>depends on: NUT-09</code></p>
 <hr />
 <p>In this document, we describe the process that allows wallets to recover their ecash balance with the help of the mint using a familiar 12 word seed phrase (mnemonic). This allows us to restore the wallet's previous state in case of a device loss or other loss of access to the wallet. The basic idea is that wallets that generate the ecash deterministically can regenerate the same tokens during a recovery process. For this, they ask the mint to reissue previously generated signatures using <a href="../09/">NUT-09</a>.</p>
 <h2 id="deterministic-secret-derivation">Deterministic secret derivation<a class="headerlink" href="#deterministic-secret-derivation" title="Permanent link">&para;</a></h2>

14/index.html

@@ -836,7 +836,8 @@
 
 
 <h1 id="nut-14-hashed-timelock-contracts-htlcs">NUT-14: Hashed Timelock Contracts (HTLCs)<a class="headerlink" href="#nut-14-hashed-timelock-contracts-htlcs" title="Permanent link">&para;</a></h1>
-<p><code>optional</code> <code>depends on: NUT-10</code></p>
+<p><code>optional</code></p>
+<p><code>depends on: NUT-10</code></p>
 <hr />
 <p>This NUT describes the use of Hashed Timelock Contracts (HTLCs) which defines a spending condition based on <a href="../10/">NUT-10</a>'s well-known <code>Secret</code> format. Using HTLCs, ecash tokens can be locked to the hash of a preimage or a timelock. This enables use cases such as atomic swaps of ecash between users, and atomic coupling of an ecash spending condition to a Lightning HTLC.</p>
 <p><code>HTLC</code> spending conditions can be thought of as an extension of <code>P2PK</code> locks <a href="../11/">NUT-11</a> but with a hash lock in <code>Secret.data</code> and a new <code>Proof.witness.preimage</code> witness in the locked inputs to be spent. The <code>preimage</code> that was used to spend a locked token can be retrieved using <a href="../07/">NUT-07</a>. Caution: applications that rely on being able to retrieve the witness independent from the spender must check via the mint's <a href="../06/">info</a> endpoint that NUT-07 is supported.</p>

15/index.html

@@ -839,7 +839,8 @@
 
 
 <h1 id="nut-15-partial-multi-path-payments">NUT-15: Partial multi-path payments<a class="headerlink" href="#nut-15-partial-multi-path-payments" title="Permanent link">&para;</a></h1>
-<p><code>optional</code> <code>depends on: NUT-05</code></p>
+<p><code>optional</code></p>
+<p><code>depends on: NUT-05</code></p>
 <hr />
 <p>In this document, we describe how wallets can instruct multiple mints to each pay a partial amount of a bolt11 Lightning invoice. The full payment is composed of partial payments (MPP) from multiple multi-path payments from different Lightning nodes. This way, wallets can pay a larger Lightning invoice combined from multiple smaller balances on different mints. Due to the atomic nature of MPP, either all payments will be successful or all of them will fail.</p>
 <p>The Lightning backend of the mint must support paying a partial amount of an Invoice and multi-path payments (MPP, see <a href="https://github.com/lightning/bolts/blob/master/04-onion-routing.md">BOLT 4</a>). For example, the mint's Lightning node must be able to pay 50 sats of a 100 sat bolt11 invoice. The receiving Lightning node must support receiving multi-path payments as well.</p>

17/index.html

@@ -912,7 +912,8 @@
 
 
 <h1 id="nut-17-websockets">NUT-17: WebSockets<a class="headerlink" href="#nut-17-websockets" title="Permanent link">&para;</a></h1>
-<p><code>optional</code>, <code>depends on: NUT-07</code></p>
+<p><code>optional</code></p>
+<p><code>depends on: NUT-07</code></p>
 <hr />
 <p>This NUT defines a websocket protocol that enables bidirectional communication between apps and mints using the JSON-RPC format.</p>
 <h2 id="subscriptions">Subscriptions<a class="headerlink" href="#subscriptions" title="Permanent link">&para;</a></h2>