From 422b38526d38eca5e34563cf7cdd00ff131237c1 Mon Sep 17 00:00:00 2001 From: callebtc <93376500+callebtc@users.noreply.github.com> Date: Mon, 26 Jun 2023 10:51:55 +0200 Subject: [PATCH 1/2] fix log(0) possibility --- 08.md | 12 +++++++++++- 1 file changed, 11 insertions(+), 1 deletion(-) diff --git a/08.md b/08.md index 25b8f90..93e3800 100644 --- a/08.md +++ b/08.md @@ -11,7 +11,17 @@ The problem is also described in [this gist](https://gist.github.com/callebtc/a6 ## Description -Before requesting a Lightning payment as described in [NUT-05][05], `Alice` produces a number of `BlindedMessage` which are similar to ordinary blinded messages but their value is yet to be determined by the mint `Bob` and are thus called *blank outputs*. The number of necessary blank outputs is `ceil(log2(fee_reserve))` which ensures that any overpaid fees can be represented and be returned by the mint to the wallet. +Before requesting a Lightning payment as described in [NUT-05][05], `Alice` produces a number of `BlindedMessage` which are similar to ordinary blinded messages but their value is yet to be determined by the mint `Bob` and are thus called *blank outputs*. The number of necessary blank outputs is `max(ceil(log2(fee_reserve)), 1)` which ensures that there is at least one output if there is any fee. If the `fee_reserve` is `0`, then the number of blank outputs is `0` as well. The blank outputs will contain the overpaid fees that will be returned by the mint to the wallet. + +This code calculates the number of necessary blank outputs in Python: + +```python +def calculate_number_of_blank_outputs(fee_reserve_sat: int): + assert fee_reserve_sat >= 0, "Fee reserve can't be negative." + if fee_reserve_sat == 0: + return 0 + return max(math.ceil(math.log2(fee_reserve_sat)), 1) +``` ## Example From a13002624ec8e7642cf4bec4381aad8e9ce7f339 Mon Sep 17 00:00:00 2001 From: callebtc <93376500+callebtc@users.noreply.github.com> Date: Thu, 29 Jun 2023 23:56:14 +0200 Subject: [PATCH 2/2] NUT-06: deprecate amount field and restriction --- 06.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/06.md b/06.md index c1bbb4e..b4ad1b8 100644 --- a/06.md +++ b/06.md @@ -5,19 +5,21 @@ NUT-06: Split tokens --- -The split operation is the most important component of the Cashu system. The wallet `Alice` can use it to redeem tokens (i.e. receive new ones in return) that she received from `Carol`, or she can split her own tokens to a target amount she needs to send to `Carol`, if she does not have the necessary amounts to compose the target amount in her wallet already. +The split operation is the most important component of the Cashu system. A split operation consists of multiple inputs (`Proofs`) and outputs (`BlindedMessages`). Mints verify and invalidate the inputs and issue new promises (`BlindSignatures`). -The basic idea is that `Alice` sends `Bob` a set of `Proof`'s and a set of `BlindedMessage`'s with an equal amount. Additionally, she specifies the `amount` at which she would like to have the split. +The split operation can serve multiple use cases. First, `Alice` can use it to split her tokens to a target amount she needs to send to `Carol`, if she does not have the necessary amounts to compose the target amount in her wallet already. Second, `Carols`'s wallet can use it to receive tokens from `Alice` by sending them to the mint and receive new ones in return. + +The basic idea is that `Alice` sends the mint `Bob` a set of inputs `Proofs` and a set of outputs `BlindedMessages`. `Alice` can decide which distribution of amounts the inputs and outputs have as long as their sum is equal. ## 6.1 - Split to send To make this more clear, we make an example of a typical case of sending tokens from `Alice` to `Carol`: -`Alice` has 64 satoshis in her wallet, composed of two tokens, one worth 32 sats and another two worth 16 sats. She wants to send `Carol` 40 sats but does not have the necessary tokens to combine them to reach the exact target amount of 40 sats. `Alice` requests a split from the mint. For that, she sends the mint `Bob` her tokens (`Proofs`) worth `[32, 16, 16]` and asks for a split at amount 40. The mint will then return her new tokens with the amounts `[32, 8, 16, 8]`. Notice that the first two tokens can now be combined to 40 sats. The original tokens that `Alice` sent to `Bob` are now invalidated. +`Alice` has 64 satoshis in her wallet, composed of two tokens, one worth 32 sats and another two worth 16 sats. She wants to send `Carol` 40 sats but does not have the necessary tokens to combine them to reach the exact target amount of 40 sats. `Alice` requests a split from the mint. For that, she sends the mint `Bob` her tokens (`Proofs`) worth `[32, 16, 16]`. Since she wants to split her tokens at amount 40, she also supplies `BlindMessages` with the amounts `[32, 8, 16, 8]`. The mint then responds with `BlindSignatures` of the same amounts `[32, 8, 16, 8]`. Notice that the first two tokens can now be combined to 40 sats. The original tokens that `Alice` sent to `Bob` are now invalidated. ## 6.2 - Split to receive -Another case of how split can be useful becomes apparent if we follow up the example above where `Alice` split her tokens ready to be sent to `Carol`. `Carol` can receive these tokens, which means to invalidate the tokens she receives and redeem them for new ones, using the same mechanism. Only if `Carol` redeems them for new tokens that only she can spend, `Alice` can't double-spend them anymore and this simple transaction can be considered settled. `Carol` requests a split of the tokens (`Proofs`) worth `[32, 8]` at the amount `40` (the total amount) to receive back new tokens with the same total amount. +Another case of how split can be useful becomes apparent if we follow up the example above where `Alice` split her tokens ready to be sent to `Carol`. `Carol` can receive these tokens using the same operation which means she invalidates the received tokens and requests new ones from `Bob`. Only if `Carol` redeems them for new tokens that only she can spend, `Alice` can't double-spend them anymore and this simple transaction can be considered settled. `Carol` requests a split of the tokens (`Proofs`) worth `[32, 8]` to receive back new tokens (of an arbitrary distribition) with the same total amount. ## Example @@ -31,9 +33,8 @@ With the data being of the form `PostSplitRequest`: ```json { - "proofs": Proofs, - "outputs": BlindedMessages, - "amount": int + "proofs": , + "outputs": , } ``` @@ -66,19 +67,18 @@ curl -X POST https://mint.host:3338/split -d \ ... } ], - "amount": 40 } ``` If successful, `Bob` will respond with a `PostSplitResponse` ```python -class PostSplitResponse(BaseModel): - fst: BlindedSignatures - snd: BlindedSignatures +{ + "promises": +} ``` -`BlindedSignatures` is a list (array) of `BlindedSignature`s (see [NUT-0][00]). +`BlindedSignatures` is a list (array) of `BlindedSignature`'s (see [NUT-0][00]). [00]: 00.md [01]: 01.md