hey @LN⚡Server are you still there? users having issues with your mint
calle
calle@cashu.me
npub12rv5...85vg
DM @callebtc:matrix.org
who's running a cashu mint here? tag below or say hi!
has anybody already built a free version of pocket, the article bookmarking and reading app that dissapeared?
- browser extension to save a link
- article text gets parsed automatically
- stored somewhere in the cloud or on nostr
- web, ios, android apps to read all your stored articles
- bonus: social features to share articles, follow other user's bookmarks
- bonus: text to speech via open source TTS models
- bonus: TTS transcriptions are shared between users once created
While I'm at it – another proof that nostr devs aren't serious about adoption is still the lack of key rotation.
I get it. It's a big task and can't be solved by any individual client, it needs to be addressed on a protocol level. I'm also aware of the that were put forward. But you know what? Writing markdown and pushing it to the nips repo isn't enough. It's step 0.
This is a typical issue that would require devs to come together and all pull in one direction. It likely would have needed a champion who is willing to push for this change, talk to people, explain it to everyone, and actually care. Similar to how we push for bigger changes in the Bitcoin protocol. It takes time, and it takes a serious effort. Once again, nobody has taken over that role because nobody really cared enough.
Back in the day, there were massively big users who would've loved to join nostr – but didn't do it because of a lack of key rotation. Why would anyone with so much to lose join a protocol that can permanently rekt your identity with a simple XSS bug that exposes your nsec? Nobody listened to them.
This was brought up over, and over, and over again. Nobody cared enough.
@primal has a serious issue with muting users – it can't be that hard. The only client I haven't had issues is @Amethyst
Many nostr kind-0 devs don't realize how big of an issue this is for their users because they don't put themselves into the shoes of ordinary users who don't want to deal with this shit.
Liquid hack explained.
Liquid has confidential transactions that hide the amounts for improved privacy. A bug in how these transactions are validated caused inflation of Liquid BTC (L-BTC) and allowed hackers to empty the entire side chain.
Liquid nodes don't see the amounts of a confidential transaction, so to make sure that the transaction is still valid and doesn't cause inflation nodes check something called a balance proof and a range proof.
The balance proof establish that sum of the input amounts equal the output amounts, i.e., that "x L-BTC going in and x L-BTC going out". But there's a catch. Only relying on a balance proof isn't enough. You also need the range proof.
The range proof establishes that a hidden output amount falls within a positive range. That means a valid output must be at least 1 L-sat and at most 2^64 − 1 L-sats. Range proofs make sure that you can't mint "negative L-BTC".
Why is this even necessary? Remember, the amounts are hidden and a hidden negative amount would allow extra positive outputs to balance against it. Without a range proof, a transaction could say "I've put 1 L-BTC in, and I'm taking two outputs out: one with 4000 L-BTC and one with -3999 L-BTC)."
This is going to cause a disaster in a little bit.
Once the balance proof, the range proof, and other validations pass, a transaction is regarded as valid and can pass consensus. However, because especially the range proof is computationally expensive, Liquid nodes cache the result of a successful range proof in memory. Essentially, the node remembers "I saw this range proof before and it was valid, all good!".
In order to recognize the same range proof later on, you need to assign a label to it. This is called a cache key. This cache key is the actual cause of the bug.
The way this cache key was constructed allowed two different transactions to collide on their cache key. Essentially, one valid transaction (1 L-BTC in, 1 L-BTC out) had the same cache key as an invalid transaction (1 L-BTC in, 4000 L-BTC out).
Here's the hack: the attackers submitted the valid transaction (1 L-BTC in, 1 L-BTC out) first. Liquid nodes verified this transaction successfully, created a cache key called REKT and stored it in their cache. Then the attackers carefully crafted a second invalid transaction with (1 L-BTC in, 4000 L-BTC out) that created the same cache key REKT.
Instead of validating the second transaction and realizing that it printed money out of thin air, Liquid nodes found it in their cache and said "hey I saw this transaction before, everything is fine" and that caused the inflation.
The attackers then took their 4000 L-BTC and withdrew 4000 BTC onto the Bitcoin base chain.
I'm amazed someone would buy this crap but hey, I'm all for it, hope the price goes up a little more
View quoted note →