Custodial Popcorn

[ZmnSCPxj-jr]

"Popcorn", in the sense of a small value being custodied at the LSP on behalf of the client. The intent is that the coins lost in your couch are more valuable than the popcorn being custodied on your behalf.

A problem is that our base layer really only enforces satoshi-valued amounts, and if the value owned by one side is below the dust limit, it is simply given to miners as fee --- i.e. any value below the dust limit is not practically enforceable onchain.

It would be nice if we could make a "small claims court" where a client could prove it has a lien on a popcorn-sized monetary amount (i.e. less than the dust limit plus fee to open an actual for-reals channel) custodied on an LSP, and the LSP is refusing to let the client use the popcorn to pay someone else. This would allow enforcement, of a sort, of sub-dust-limit amounts.

Of course, this is custodial, so....

Also, the amounts being considered as so tiny that it might not be worth worrying about anyway.

We would also need some way to upgrade from custodial to non-custodial.

[ZmnSCPxj-jr]

Crazy idea: have every LSP be a Chaumian bank (though using WabiSabi-style keyed-verification anonymous credentials instead of blinded signatures). LSP issues popcorn tokens to clients. If the client wants to send out (i.e. use its received zap to zap someone else) it contacts a competitor LSP and hands over control of the popcorn token to the competitor LSP conditional on the HTLC being fulfilled. Once the competitor LSP has gathered enough popcorn tokens of the LSP, it asks for onchain settlement from the issuing LSP; presumably LSPs are in a better position to enforce this than mere clients, and provide proof of misbehaviour.

On the other hand, misbehaviour here is not providing the data, which is difficult to prove. Hmm.

[ZmnSCPxj-jr]

Custodial Popcorn can possibly be inverted so that risks are inverted i.e. instead of client-trusts-LSP, it is LSP-trusts-client. The transform is done this way: Client single-funds a channel toward the LSP, LSP issues blinded tokens to client (without a corresponding transfer on the channel!); client periodically uses those tokens / trades the tokens, then client settles to the LSP periodically by saying "these are the tokens that remained with me" and then the client transfers the delta between the channel size and the tokens that remained with the client.

An additional mechanism would be for a client to go to another LSP, say "I have tokens from this first LSP" and make payments out via that other LSP without making a channel to them; the other LSP then aggregates tokens issued by the first LSP from multiple such clients and periodically the LSPs settle over the LN. The advantage here is privacy: the client has a channel with one LSP but leaks its outgoing payments to another HTLC, decoupling identity of its onchain funds vs its outgoing payments (whereas with a "normal" LSP the identity of its outgoing payments is tied to the onchain funds used by the client to open the channel to the LSP; the LSP might not know who the payee is, but it does know who the payer is and what onchain funds were used to pay with).

LSPs may also use the tokens of other LSPs strategically: if it has a channel with another LSP, and that channel is depleted and it is getting a lot of forwarding failures because of the lack of liquidity, it can withdraw the value of the other LSP tokens it holds and get some liquidity to power its forwards towards that LSP. This effectively rebalances through their shared clients.

Token values would degrade over time. Any such token-minting system would require rotation of keys used to mint tokens (or else unbound storage), so a client that wants to retain control of funds would need to have slightly-old tokens from a few rotations ago be re-issued with the latest key rotation, and that mechanism can deduct a small "servicing fee" each time tokens are re-issued with the latest key rotation, representing the cost of lockup of funds on behalf of the user. The client can then settle with the LSP by disposing of its tokens and paying the delta with the channel, which removes the servicing fee but now the client can only pay by leaking its actual payments to the LSP via normal in-channel HTLCs. To get privacy, the client pays for it by then asking for tokens and promising to pay the delta back to the LSP in the future, which lets the client pay for payments using the anonymized tokens (possibly via another LSP that is willing to credit the tokens of the first LSP it has).

Comes from @nothingmuch who credits @moonsettler for this idea.

Against this, we should note that the original impetus / user story is that of nostr zaps, traditionally 21 sats each, being too small to pay for a channel open in the foreseeable future. The user story is that the client is someone who occassionally posts on nostr, who then aggregates the received funds and then gets a channel opened once the funds are large enough, hence Custodial Popcorn

[moonsettler]

the original impetus / user story is that of nostr zaps, traditionally 21 sats each, being too small to pay for a channel open in the foreseeable future. The user story is that the client is someone who occassionally posts on nostr, who then aggregates the received funds and then gets a channel opened once the funds are large enough, hence Custodial Popcorn

btw sending ecash on nostr does not require any special setup. it's the simplest most straightforward thing to do. it can even be done with a throwaway nsec and identifying the sender (if desired) inside the encrypted envelope with a meta protocol. the receivers could simply consolidate to self custody at their leisure.

{
"type": "cashu/v1",
"sender": "<real_npub>",
"memo": "optional message or tx identifier",
"tokens": [...]
}

[ZmnSCPxj-jr]

@moonsettler The tokens being sent would be cashu-style tokens? As I understand it it would require some interaction with the server anyway to transfer definitely to the receiver, is my understanding correct?

[moonsettler]

yes. the receiver would receive tokens he/she can spend through the mint. either pull into self custodial LN channel or move to a different mint. we can call it a sweep operation if we want, because before that the sender can also spend the same tokens. (unless they are bound to the receiver's pubkey, there have been experiments with that, it's enforced by the mint ofc)

the main point is the receiver can do this at their convenience when they come online, in fact their wallet can automatically do this.

[nothingmuch]

Comes from @nothingmuch who credits @moonsettler for this idea.

link that i never provided: https://gist.github.com/moonsettler/42b588fa97a1da3ac0adea0dd16dadf2

note that some of what is described is my own attempt to generalize this inversion into a market/price discovery mechanism, there the credit goes to to Paul Grignon's self issued credit concept, which is a bit like gift cards with a maturity curve & discount built into, so it's applying his design to moonsettler's concept, but with a different design goal.

[moonsettler]

yeah, i like the idea, iterated on it in a twitter thread:
https://twitter.com/4moonsettler/status/1728102530230677612

• sender gets non-custodial ecash from LSP
• sender creates encrypted envelope to the receiver's pubkey from a throwaway nsec
• receiver can swipe at his pleasure or spend the ecash
• sender can reclaim funds if they left unclaimed for long

forget zaps!

an LSP you have channels with. that seems like the most optimal. you would lock up a portion of your channel balance similarly to an HTLC but this goes to a new 2-of-2 address creating a credit ecash escrow, for which you are issued tokens.

settle with your LSP some time later, you will resolve that escrow by showing your unspent tokens.

[ZmnSCPxj-jr]

@moonsettler writes:

you would lock up a portion of your channel balance similarly to an HTLC but this goes to a new 2-of-2 address creating a credit ecash escrow

Let me see if I understand this correctly: the 2-of-2 escrow would not be enforceable on the Bitcoin blockchain, but instead requires mutual trust between the LSP and its client, correct?

Have you considered the use of Smart Contracts Unchained instead of a 2-of-2 mutual trust contract? Basically Smart Contracts Unchained extends the typical 2-of-3 escrow (2 keys are from the direct parties in the contract, 3rd key is an escrow that arbitrates in case of a conflict) so that an "escrow service" is a k-of-n of multiple services (so you get some of the advantages of Blockstream Liquid where you have distributed trust in a k-of-n, but gives you maximal freedom in changing who that k-of-n is) and the parties can agree in an n-of-n or if there is a disagreement they put up their contract and their witnesses to the contract. This does require third-party validation of tokens (because the escrow service is the third party in the contract), which I think are not possible with existing cashu tokens?

@nothingmuch is pushing for switching to WabiSabi credentials. Would WabiSabi credentials be third-party validatable? I guess the problem is that the server marks some credentials as spent, and thus the server needs to prove that the credential was spent somehow.

For third-party validatability: would it work with the BDHKE used in cashu to provide T and s*T and the DLEQ of s*G is to s*T so that the client can show it was issued that token, and then if the server has already marked that token as spent it can counterprove to the escrow "but I know the t behind T here it is, the client is lying"? The cient can malleate T here by inventing any number of random x and give x * T and x * s * T but can the original DLEQ proof of s*G is to s*T also be malleated to prove s * G is to s * x * T? I think the hash prevents that but maybe it can be malleated?

[nothingmuch]

@nothingmuch is pushing for switching to WabiSabi credentials. Would WabiSabi credentials be third-party validatable? I guess the problem is that the server marks some credentials as spent, and thus the server needs to prove that the credential was spent somehow.

Although being a KVAC system requires knowledge of the secret key to verify a credential presentation, the server can produce a publicly verifiaible proof that such a message was valid using its secret analogous to the proof of valid issuance that it must provide to prevent key tagging attacks, so the specific situation you are describing can be done.

A credential system that is not based on algebraic MACs can be used, e.g. Coconut is a publicly verifiable scheme.

(sorry for edit, accidentally posted before finishing the response)

[moonsettler]

@ZmnSCPxj-jr:

Let me see if I understand this correctly: the 2-of-2 escrow would not be enforceable on the Bitcoin blockchain, but instead requires mutual trust between the LSP and its client, correct?

it's the basis of the escrow, as most cases are assumed to be resolved cooperatively. neither party can gain by not cooperating and you are already in a highly interactive setting with lightning. presigned transactions can further lead to arbitration contracts. that can be trust oracles or maybe even BitVM fraud proofs. (altho i'm skeptical about it's economic viability for small amounts)

Have you considered the use of Smart Contracts Unchained instead of a 2-of-2 mutual trust contract? Basically Smart Contracts Unchained extends the typical 2-of-3 escrow (2 keys are from the direct parties in the contract, 3rd key is an escrow that arbitrates in case of a conflict) so that an "escrow service" is a k-of-n of multiple services (so you get some of the advantages of Blockstream Liquid where you have distributed trust in a k-of-n, but gives you maximal freedom in changing who that k-of-n is) and the parties can agree in an n-of-n or if there is a disagreement they put up their contract and their witnesses to the contract. This does require third-party validation of tokens (because the escrow service is the third party in the contract), which I think are not possible with existing cashu tokens?

yes i baseline recommend 3-of-4 for arbitration where both parties bring their own oracle from a reputable set. ecash fraud proofs are a big part of how arbitration could be carried out.

edit:
to make it even more clear why i think the 2-of-2 is perfectly fine is it makes it clear that the scheme is non-custodial as the oracles normally never have a say in spending the sats, the over-collateral makes sure that the user loses on not cooperating, and ofc such behavior would be punished by getting his channel closed as well.

ideally these escrows are obviated with a new commitment transaction after settlement. so they would never make it on-chain.

[ZmnSCPxj-jr]

@moonsettler with the current Poon-Dryja mechanism, every output contract does need to be infect with the Poon-Dryja mechanism, i.e. the 2-of-2 would actually be (A && B) || (B && revocation_key), and the transaction presented would also need to give the escrow and the revocation path AND be relative-time-locked. This is greatly simplified with Decker-Wattenhofer and Decker-Russell-Osuntokun but the former is groady and the latter requires NOINPUT or equivalent. At least if you wanted to really minimize trust. Hmmmmmmmmmmm.

Basically, every contract is infected, so that an arbitrary contract C between Poon-Dryja participants A and B requires both a (A && B && C) || (B && revocation) on the A-side commitment tx, and when this is spent, it also requires that outputs going to A and B on the second-stage tx are also infected with (A && relative-lock-time) || (B && revocation).

With an escrow as you mentioned, the base contract C would be (A && B) || ((A || B) && escrow_contract), which gets infected to (A && B) || (A && B && escrow_contract) || (B && revocation), with the second-stage tx redistributing the funds to an output B and (A && relative-lock-time) || (B && revocation). Hmmmm.

Sorry, this is melting my brain :P

[ZmnSCPxj-jr]

@nothingmuch

Although being a KVAC system requires knowledge of the secret key to verify a credential presentation, the server can produce a publicly verifiaible proof that such a message was valid using its secret analogous to the proof of valid issuance that it must provide to prevent key tagging attacks, so the specific situation you are describing can be done.

It seems to me, naively, that if the client wanted to show a third party a proof that it was issued a token, it could present both T and its corresponding blinding factor b, and the exact same DLEQ given by the server in the initial issuance of the BDHKE.

Of course, once this is revealed to the escrow and the escrow challenges the server to give the t so it can show that it already marked the t as invalid, the server now knows the b and can now link the blinded token to the specific issuance. Is this an acceptable privacy leak?

Basically in any case where the escrow set needs to judge between "the client says it has this token unspent, but the server is not crediting it" we want the client to be able to provide an entire "smoking gun" solely from data available during token issuance, without the server having to cooperate, as they are now in adversarial positions if they have reached the point where they need third parties to adjudicate between them.

A credential system that is not based on algebraic MACs can be used, e.g. Coconut is a publicly verifiable scheme.

Thanks, how different is this from WabiSabi? Would the credentials need to be group elements / points that are actually Pedersen commitments like in WabiSabi or...?

[moonsettler]

@moonsettler with the current Poon-Dryja mechanism, every output contract does need to be infect with the Poon-Dryja mechanism, i.e. the 2-of-2 would actually be (A && B) || (B && revocation_key)

sounds good to me. once you have your potential 2-of-2 output you can pre-sign further arbitration steps optionally.

[nothingmuch]

It seems to me, naively, that if the client wanted to show a third party a proof that it was issued a token, it could present both T and its corresponding blinding factor b, and the exact same DLEQ given by the server in the initial issuance of the BDHKE.

Of course, once this is revealed to the escrow and the escrow challenges the server to give the t so it can show that it already marked the t as invalid, the server now knows the b and can now link the blinded token to the specific issuance. Is this an acceptable privacy leak?

That seems somewhat dubious to me. I spent some time trying to figure out whether it can still be achieved without revealing b (it can with a proof of knowledge), but that is still problematic since (T, tB) are exposed together, and I don't really see a way around this since T is a hash to curve point. Admittedly it's possible to prove knowledge of t with general NIZKs as opposed to Sigma protocols, but at what feels like a prohibitive complexity increase. To verify the DLEQs, though, T must be a public input, and so is bT in the DLEQ that is just copied. Since T is a hash to curve point, and I don't see a way to formulate that statement without revealing it in some way.

Perhaps the compressed Sigma protocol literature can offer some insight for how to prove knowledge of a DLEQ proof instead of providing it directly, thereby allowing only T and sT to be revealed to the escrow.

But, given it's already specified, I don't see why this would be better than just using the publicly verifiable variant of privacy pass, which relies on blind RSA? Seems like a better approach than trying to bypass the limitations with this recursive PoK approach.

A credential system that is not based on algebraic MACs can be used, e.g. Coconut is a publicly verifiable scheme.

Thanks, how different is this from WabiSabi? Would the credentials need to be group elements / points that are actually Pedersen commitments like in WabiSabi or...?

Quite similar in the abstract, but using pairing based threshold blind signature scheme instead of an algebraic MAC on an Abelian group.

Nitpicking, those would be credential attributes, not the credentials themselves (which is the attributes as well as the signature/MAC covering them), but yes, more or less the same. Formally, attribute values always field elements and the issuer only sees ElGammal commitments/encryptions of those, with re-randomization for credential presentation, but that's a minor difference.

I worked out some of the details about two years ago but lost my notes (i think this was on physical paper), the attributes there are not group elements so it's a bit trickier, but not unlike Danake which uses an algebraic MAC scheme that is not as convenient as the Signal KVAC one.

I looked at the paper right now but could not figure out at a glance what was challenging at the time, but IIRC it had to do with what would have been the equivalent of a balance proof.

[SeverinAlexB]

Before this dusts of into the nirvana: I still think a standard like this is needed. No idea when we should work on it (we already have lots on our plate) or how legally feasible it is but the base problem of handling initial small amounts is still here.