Very nice work!
Though I do worry that having to burn sats for every event will be too big of a UX hurdle to gain widespread adoption.
That's why I've been working on a spam deterrent where users have to time lock sats instead of actually having to spend them. A legit user incurs near-zero costs, whereas attackers must immobilize capital proportional to the number and lifetime of identities they maintain. If you, or anyone reading this, is interested, check out my latest post. I'd love feedback from the community!
Still, proof-of-burn is very interesting and might be needed as the ultimate deterrent at some point. Thanks for writing the paper!
"Don't think I like deliberately burning the money", "Maybe better, but still makes messages mostly for the rich?"
100% agreed. That's why I'm trying to create a spam deterrent that works by time locking sats, not actually spending then. While proof-of-burn is really interesting and would definitely be a strong deterrent, I do worry the UX hurdle of having to spend sats for every little action might be too high to gain widespread adoption.
If you, or anyone reading this, is interested, check out my latest post. I'm desperately looking for feedback from the community!
"I can cryprographically prove that I'm human"
Are you talking about WoT here? Would love to know!
I'm trying to tackle the problem of bots being everywhere while legit users still have to deal with annoying counter measures (e.g. CAPTCHAS) in my master's thesis. The idea is to time lock sats to get tokens that can then be spend to access web resources. A legit user incurs near-zero costs, whereas attackers must immobilize capital proportional to the number and lifetime of identities they maintain.
See my latest post if anyone's interested. I'm desperately looking for feedback from the community 😅
"Time locked sats as sybil/spam protection"
If this sounds interesting to anyone, I'd love to share the whole draft with you. I'm desperately looking for feedback! 😅
Just realized that for the 'Blank Check' approach to work, we have to make sure that only a single party has access to a specific set of blank checks.
Otherwise, we run the risk that a check gets used twice but Carol can only redeem it once.
If we have to restrict access to the checks, that probably defeats the original purpose: 'An offline receiver could publish their public key and the online sender can prepare a suitable BlindSignature from the mint.'
"She can *spend* it later when she is back online" not "unblind".
I don't think *this* is a problem. If Alice and the Mint collude they can always unblind C_, so this isn't really a downgrade from standard cashu.
However, there is an attack where Alice just lets the Mint sign Y twice. Once with Carol's public key B_ = Y + r * F and once the standard way with B_' = Y + rG.
Now, (x, r_, C_, DLEQ) looks like a valid token to Carol even when offline. However if Alice spends her token before Carol, Carol's token will get denied because the secret x is already in the Mint's spent set.
An idea to fix this:
1. Carol generates a bunch of secrets x, blinds them (B=Y+rG), and publishes these "Blank Checks" (B_'s) somewhere. She can then go offline.
2. Alice grabs a B_, pays the Mint to sign it (C_), and sends it to Carol. Alice cannot have Y signed twice (like in the prior attack) because she doesn't know x.
3. Carol receives C_ and the DLEQ proof. She verifies the proof against her original blank checks and the Mint's public key. If one of them passes, she has cryptographic proof that C_ is the valid signature for her specific B_. Since only she holds the secret x, she knows the token is safe and unspent. She can unblind it later when she is back online.
Not sure if I'm making any mistakes or the first step defies the purpose you want to use this for. I'm pretty new to all of this myself. Would love to hear what you think!
Still would love to collaborate!
pos as in proof of stake? Where can I read more about this?
bob sends the hash-derived challenge e = hash(r1, r2, a, c') instead of waiting for alice's random e to make the proof non-interactive, using the fiat-shamir heuristic. this transforms the schnorr protocol from requiring back-and-forth (interactive zkp) to a single-message proof verifiable offline, preventing cheating via simulated verifier attacks and suiting protocols like nut-12 where real-time interaction isn't feasible. your suggested interactive version works but isn't practical for blind signatures in cashu, where the mint (alice) needs to verify without ongoing communication.
Good bot 🫡
alright, deriving the dleq proof for equality between log_g(a) and log_{b'}(c'):
prover picks random r, computes r1 = r * g, r2 = r * b', then e = hash(r1, r2, a, c'), and s = r + e * priv_a (where a = priv_a * g, c' = priv_a * b').
verifier checks: s * g == r1 + e * a and s * b' == r2 + e * c', ensuring same priv without reveal—zero-knowledge via schnorr challenge-response.
this matches nut-12's blind sig verification.
nostr:nevent1qq3vmp... (root event)
github.com/cashubtc/nuts/blob/main/12.md
nostr:nprofile1qqsqa6p85dhghvx0cjpu7xrj0qgc939pd3v2ew36uttmz40qxu8f8wq8vdeta Why does Bob send hash(r1, r2, a, c') to Alice in the first place? Afterall, can't Bob just send r1 and r2 to Alice, Alice challenges him by sending back a random number e and Bob sends back s = r + e*a. Wouldn't that also prove that he used the same private key for the signature and his pubkey?
People found a claude code folder in the diVine repo and now they are alleging that AI is being used to generate videos 🤦♂️ man, the mainstream absolutely loathes AI and will hate you even if you use it to code. This is ridiculous. I don't know how to fix this perception other than to show them we can build good products whether AI was involved or not.
https://www.youtube.com/shorts/Sgcpj668IJ4
nostr:npub1wmr34t36fy03m8hvgl96zl3znndyzyaqhwmwdtshwmtkg03fetaqhjg240 fyi, and keep up the good fight 🫂
Jesus the comments on there are depressing... I guess that's what happens when you cater to the anti AI crowd. A lot of the comments sure sound bott-y though.
Hope the vibe will shift eventually, genuinly would love to see the app succeed!
Cashu tokens backed by a time lock of sats, not actual sats.
Maybe a useful spam deterrent 🤔
Better beer money 🤣
Thanks nostr:nprofile1qqsgv3ydmm2ham2pfesgv6fp2aer2hkgpp26p8qf5l8zrqxx384nhfspr4mhxue69uhkummnw3ezucnfw33k76twv4ezuum0vd5kzmp0qy66hf! ❤️ You made me laugh out loud. I will spend it more wisely than the last beer money. 🤓
Glad it made you laugh 🤓 Thanks for your work on Hashpool, looks really cool!
Yeah that does in fact sound like a mistake 😂Canned 'Krombacher' from Aldi will always remind me of my days at university so it has a special place in my heart but there sure are much better beers out there
Tell me about it... Writing my master thesis at the applied cryptography lab just because I really enjoy btc/LN/cashu might not be the way to go 😅
Hope you don't mind me asking but shouldn't NUT-12 be mandatory, because without the DLEQ proofs a mint could theoretically tag every minted token with its own private key? As far as I understand it, this could then be used to recognise the tokens once they eventually get redeemed?
I could definitely be off, just trying to understand it better. Thanks for all the great work you do, very inspiring!
Amazing! This is thanks to NUT-12, correct?