NUT-XX: Offline Spilman (unidirectional) channel

[SatsAndSports]

Update: 2025-11-17: big rewrite. Less discussion, more details, deterministic outputs

With this NUT, Alice and Bob can - using any mint supporting P2PK (NUT-11) - set up a channel where, once this 'cashu channel' is opened, Alice can decrease her own balance and increase Bob's balance. After each update, Bob can verify the new balance without needing to contact the mint for every update of the balance.

This allows a very large number (billions) of balance updates, where each update may be very small (millisat), but with only using a small number (dozens) of proofs prepared in advance.

• Correct the name s/Spillman/Spilman/ https://gnusha.org/pi/bitcoindev/CA+CODZEQX_xiaJE7WtFZC2qfVfDqZAgg-ydU5Q73O-QTkXJpPw@mail.gmail.com/
• add a section at the bottom summarizing what Bob should do to verify the channel has been set up correctly.
• what should we do about fees? See the comment below. My default, I'm going with Bob (the reciever) pays the fees, as it's convenient in the code.
• can we use pay to blinded pubkey here?
• is there an existing deterministic splitting of a target amount into the amounts supported by the mint?

[SatsAndSports]

.. based on various ideas from multiple people in this Nostr thread: https://iris.to/note1es2eewq59msy3espdxn24s6y04vlz6987t6yrwr3jxvwr33aahyqvjm2qn

[c03rad0r]

Perhaps Bob doesn't need to check with the mint before going offline if Bob maintains a redeemed stack, because bob can verify that the proofs are locked to his pub key, that they were signed by the mint and that Bob hasn't redeemed them yet.

[SatsAndSports]

because bob can verify that the proofs are locked to his pub key, that they were signed by the min

I think I agree. Do you mean this offline check that Bob can do via Nut-12?

https://github.com/cashubtc/nuts/blob/main/12.md

I don't understand that fully yet myself

[c03rad0r]

Indeed, based on the following LLM summary of NUT-12, it seems to be the right tool for the job. I didn't realize this is so involved. I just assumed anyone would be able to verify that proofs are signed by the mint.. Happy to try to understand it together next time we cowork :)

Previously, only the mint itself could verify its own signatures. NUT-12 introduces DLEQ proofs, which allow users like Alice (who interacts with the mint) and Carol (who receives ecash from Alice) to verify that the mint (Bob) used the correct private key for signing.

The core idea is to prove that the private key used to create the mint's public key (A) is the same private key used to sign a blinded message (B').

[robwoodgate]

I haven't had chance to read through properly yet, but in general Cashu terms, "Bob" is usually the mint.

"Alice" and "Carol" would be peers. You might consider changing to keep the mental model clean and prevent misunderstandings?

EDIT: This concept is very cool, BTW!

[SatsAndSports]

Good point, I'll change that when I have time to go over this again in more details. So Alice and Carol have a channel, and Bob is the mint

I've had success implementing it, and found lots of interesting implementations challenges. Some mints don't support everything correctly. Some mints only have partial support for P2PK; they don't support SIG_ALL and they don't seem to support locktime correctly either. So I'll likely include details on the support needed if and when I get a chance to overhaul this proposal based on what I learned coding it up

I made a tool to check which mints support various P2PK features that we need: Youtube and Github

I haven't had chance to read through properly yet, but in general Cashu terms, "Bob" is usually the mint.

"Alice" and "Carol" would be peers. You might consider changing to keep the mental model clean and prevent misunderstandings?

EDIT: This concept is very cool, BTW!

[robwoodgate]

I made a tool to check which mints support various P2PK features that we need: Youtube and Github

Nice tool!

The SIG_ALL spec is relatively new - so only mints on newer software will support it.

The mint auditor is quite useful to cross reference the flavor / version software the mint is using:
https://audit.8333.space

I also saw your video processing thousands of sats per second. Love it!!

[SatsAndSports]

Big rewrite, primarily for the new deterministic-output-to-1-of-1-P2PK scheme.

Also, trying to bring more clarity and (hopefully) proving how little work Bob needs to do when Alice opens a channel and makes a payment to him without any input from him

I see there are other comments here that I haven't responded to yet! I'll try to check them now

[SatsAndSports]

The SIG_ALL spec is relatively new - so only mints on newer software will support it.

Yes indeed. In fact, the precise details of the sig_all message is changing (https://github.com/cashubtc/nuts/pull/302/files). So hopefully, we can get
everyone up to a final consistent version soon

The mint auditor is quite useful to cross reference the flavor / version software the mint is using: https://audit.8333.space

Ah yes! Even before thinking about this channel idea, I was thinking that the auditor should check many different usage patterns. A mint operator could set up their system to behave flawlessly with the auditor's usages, but rug everybody when the user deviates from what is covered by the auditor 😀

I also saw your video processing thousands of sats per second. Love it!!

Thanks! I'm kinda thinking of integrating it with some basic realistic use-case, like a streaming video where cashu must be paid to keep the stream going. But that's for slightly later

[SatsAndSports]

I haven't had chance to read through properly yet, but in general Cashu terms, "Bob" is usually the mint.

"Alice" and "Carol" would be peers.

For now, I'm sticking with Alice and Bob, as I find it convenient to be able to use 'his' and 'hers' without ambiguity.
If Bob is the mint, maybe Charlie could be the receiver. What do you think?

[robwoodgate]

I haven't had chance to read through properly yet, but in general Cashu terms, "Bob" is usually the mint.
"Alice" and "Carol" would be peers.

For now, I'm sticking with Alice and Bob, as I find it convenient to be able to use 'his' and 'hers' without ambiguity. If Bob is the mint, maybe Charlie could be the receiver. What do you think?

Charlie works great - the only well established names are Alice (consumer) and Bob (Mint). Having a "Charlie" so you can refer to his and hers is a great idea,

[SatsAndSports]

Fees (I link to here from the Description)

I think there are four different policies that we could have to deal with fees. But really only two of them are, I think, of interest

Imagine:

• Alice starts with 101 sats in proofs at the mint; i.e. ignoring the fees associated with those proofs, the total nominal value of those proofs is 101.
• She swaps those with the mint for the 2-of-2 funding token. Due to fees, that funding token has a total value of 100.
• Assuming that Bob's balance is at the maximum possible, when he closes the channel he gets deterministic outputs worth 99 sats, and Alice 0. The other sat was lost in fees
• Finally, Bob's wallet might (unnecessarily?) swap his deterministic outputs into simple non-NUT10 proofs. Again, due to fees, the total value of these is 98 sats

Q: What is the 'capacity' of this channel? Which of those four numbers

SatsAndSports: I currently think the capacity is 100, primarily because that's the easiest to code up. But maybe that's not the right motivation! An alternative is to say that it's 98, as that's the maximum value that Bob can extract. (Well actually, he could extract 99, if his wallet is intelligent enough to store his deterministic P2PK proofs as-is)