let my try to explain it more succinctly what i'm trying to accomplish nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7!

the first DLEQ proves C' = k*B'

second DLEQ proves C = k*Y

it Alice gives Carol the first DLEQ Crol can't produce or verify C from it without r. r blinds the relationship between C' and C thus protects the 'unlinkability' aspect. Alice however can reveal the second DLEQ to anyone.

ofc there are special cases where Bob would know that C' and C are related, for example if there is only one token in existence of his database of a certain denomination.

thanks for the correction, will fix!

yes, the first DLEQ Alice receives at the time the token is minted. however will not ask for the second immediately, that would be bad for her privacy.

so in theory it doesn't break unlinkability, because B' or C' can't be linked to C, and these two DLEQ-s don't happen in the same session. they would happen displaced in time. Someone would present C for Bob anyhow, Bob doesn't know if that is Alice or Carol. Bob may know that C' is related to a specific lightning invoice, but he has no idea that C is related to any such thing.

time and a different world. everyone had to rush to work or school pretty early, there was no time to sit down and eat. to this day i usually don't eat anything before noon got so used to it. just a coffee to get me started.

when i was a kid we had no cereal, or breakfast.

nostr:npub1vadcfln4ugt2h9ruwsuwu5vu5am4xaka7pw6m7axy79aqyhp6u5q9knuu7

can i ask you to take a look at this as well?

i have been meaning to ask an opinion on this (second) DLEQ from someone:

https://github.com/moonsettler/cashu/blob/dleq-por/docs/specs/40.md#alice-requests-dleq-proof-on-c

the idea is that the first DLEQ only proves that k private key was used to create C signature, if the r blinding factor is revealed because normally it only proves the relationship between B' and C'. this second DLEQ however is supposed to be a publicly verifiable proof that a token was signed by Bob without breaking unlinkability.

that sounds like the optimistic scenario to me because mankind survives.

i know who i could ask, but i don't want to nag them with something so basic.

so lemme put the thinkboi hat on...

K = kG

K' = K+sG = (k+s)G so if i send s to K then he can calc the private key k' to the new silent pub K' i made for him, but i can't, because i don't know k right?

so all people observing this would see is that a pub they never seen before initiated a DM to K but there was never any reply. then some other new pub dms with a new pub... 🤔

time to use 'silent dm's! you should be able to derive a unique pub for a session from a pub with a tweak and send the 'notification dm' from a throwaway pub... or something like that.

but let's make something clear here! it's not sha256 you have to worry about, idk why people keep bringing that up. not realistic.

i'm say it's a hundred trillion times easier to migrate all web service to larger keys overnight than to do anything about it on bitcoin.

sha256 is more important for binary and document integrity than secrets. for example an adversary could alter binary packages and load them with malware and the digital signatures would check out. or just replace transactions or whole blocks in the bitcoin blockchain. that would be some trolling...

i heard this line touted a lot but it's a wholly unimpressive argument. most systems are trivial to upgrade to higher and higher keysizes way faster than how q computers can progress. and they almost immediately gain the security benefits of such upgrade without a long migration period that can never be truly completed.

what could have been... otoh i could be dead by now in some stupid accident doing something fun like scuba or sky diving. a jetpack accident...

it shouldn't reveal anything at all. maybe the changes in the size of the backup needs some consideration like padding.

btw there is already a solution figured out for issues like this:

you could create a programmable voucher, that has time locked refund conditions.

you can ask the mint to sign this voucher in exchange for redeemed fungible ecash. basically the recipient can give you something like a paynym or a nostr pub (public profile info), and you can lock in the funds while online.

then he can accept and verify this mint signed voucher when you meet offline that is say good for 2 days, after which you can claw it back if the deal doesn't work out. he can claim it at his leisure later that day.

it's not exactly intended for this fringe use case, but could work.

it would be nice to have a designated kind for cashu communication in general that does not distinguish from the internal content. for challenges and proofs instead of a json api where proving malicious conduct or abandoning the session is hard to prove by the wronged side. the relays wouldn't have to keep those events for long like 30 days tops is enough for anyone to grab them who is interested in specific events.

changed the notation to the one i'm more comfortable with (and probably less confusing to all of those involved in cashu; removed the relationship between x and r because it will probably not work in the future; added (proposed) DLEQ on C blind signature that doesn't break unlinkability when revealed, thus the signature can be proven to be created with Bob's private key without revealing the blinding factor used by Alice...

https://github.com/moonsettler/cashu/blob/dleq-por/docs/specs/40.md

we got something way better than that. only it's difficult to prove the correctness. it's a strong intuition for now.