Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

NUT-06: Deprecate amount in POST /split #34

Merged
merged 3 commits into from
Jul 8, 2023
Merged
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
24 changes: 12 additions & 12 deletions 06.md
Original file line number Diff line number Diff line change
Expand Up @@ -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

Expand All @@ -31,9 +33,8 @@ With the data being of the form `PostSplitRequest`:

```json
{
"proofs": Proofs,
"outputs": BlindedMessages,
"amount": int
"proofs": <Proofs>,
"outputs": <BlindedMessages>,
}
```

Expand Down Expand Up @@ -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>
}
```

`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
Expand Down