Avatar
/dev/fd0
6681268ace4748d41a4cfcc1e64006fb935bbc359782b3d9611f64d51c6752d9
Replying to Avatar hodlbod

**Security Update**

I've got some bad news for you guys. This morning, as I was adding error handling to flotilla, I discovered that Coracle has been sending user session objects to bugsnag when reporting errors.

Who is affected: Users who triggered an error in Coracle while signed in with their private key, since December 5th 2023.

What I've done:

- I immediately released a new version of Coracle, both to web and to zap.store

- I have deleted the affected apks from my releases

- I have deleted all my error data from bugsnag

- I have deleted my bugsnag project and rotated my api key, so lingering error reports will be dropped

- I have audited my code for use of the session object to ensure nothing else like this is happening

What you should do:

- If you're logged in with your private key, log out

- Hard refresh the page to ensure you have the latest version of Coracle

The bottom line is that if you signed in to Coracle with your private key, it has been shared with me and with bugsnag. In practical terms, your keys should still be secure, since they were sent over TLS, and have been deleted. But there is no guarantee I can offer that they are in fact gone.

I take my users' privacy seriously. My error reporting implementation doesn't record user IPs, it redacts identifying data, and it allows users to opt-out. I also warn the user when they attempt to enter an nsec into a text field. In this case, I simply screwed up, and I sincerely apologize. Reply to this note if you have any questions.

I can shitpost from a new key if it ever gets compromised. What about ecash users?

I have updated this table although more technical things could be added here. Let me know if you see something important is missing.

Use of custodians for payments is the most cringe thing about nostr.

1. I do not care what people think about me because the software works without me

2. It has implementations in 3 languages: python, kotlin and rust. Mobile app for android, ios and desktop apps are being used at the moment.

3. It does have sybil resistance using curve trees

nostr:note1rq4yruadusx85jp8pmsmxn59fguvzxatsqqzur98rdj7u0ken3ksq502sr

Protocol supports Tor as well. It is created for users with different needs and not necessarily a particular cult.

NEW RELEASE

v0.1.1 for joinstr: https://gitlab.com/invincible-privacy/joinstr-kmp/-/releases/v0.1.1

Changes

===============

- Improve UI

- Remove BIP 32 derivation paths from signed PSBT

- Wallet selection in settings

- Riseup VPN implementation

- Support Testnet and Mainnet

- Fix fee rate estimation

Review the code, verify APK, test it and share your feedback. Join simplex chat group if you need signet coins and other peers for testing.

Replying to Avatar PABLOF7z

Yesterday we were playing around with ideas at nostr:npub1s0veng2gvfwr62acrxhnqexq76sj6ldg3a5t935jy8e6w3shr5vsnwrmq5 , we needed something to preserve anonymity for blossom users that communicate with DVMs.

📢 Introducing Onion-routing for event publishing

This introduces insane privacy guarantees, someone can publish an event and not even the relay they are publishing from can now it's them, nor their IP address.

Technically this works very similar to Lightning, the sender constructs a route of pubkeys and can bounce around the message through pubkeys willing to route for them.

The sender can include small ecash tokens inside each onion layer to pay for the routing.

No hop in the route until the last one knows what they are routing, who its coming from and the sender very explicitly defines through which relays it should hop.

(for the sake of debugging, I built a traceroute-like view, so the sender can see the event being bounced around the different relays; in real conditions a sender wouldn't use that to preserve privacy)

Think of this like tor, just faster.

https://m.primal.net/LZtF.mp4

nostr:note1q8rnnu4ss798ue88400r5ytej50uzhx87d775q6jev7hs64tj2ksf2nkh2

Could be done without ecash: https://devpost.com/software/el-tor

Yes I was responding to someone on twitter at the same time so wrote "tweet" instead of post. It is possible and shared multiple times in this thread DYOR.

> You can also use e-cash non custodially if you run your own mint

Running your own mint, using it to mint ecash for yourself does not improve privacy. You might as well run LN node instead and use LN with self custody.

Recipient needs to be online for redeeming e-cash if its issues by untrusted mint.

> though I want to have e-cash if I must use a custodian

Why do you need a custodian in the first place? Whole point of creating bitcoin was to create e-cash with no trusted third parties. You can read old discussions on mailing lists, whitepaper and initial website.

> Users of lightning can benefit from the liquidity without using custodians themselves

AFAIK e-cash is used for small amount. Lightning already gets enough liquidity from boltz swaps, centralized exchanges etc. Ark and Mercury could provide more liquidity in the future without involving trusted third parties.

- Please read the tweet I replied to so that you understand the context of 'upgrades'

- Mints are third parties who custody bitcoin for users that may or may not use LN nodes. I have experimented enough and running a mint: https://thismoneydoesnotexist.lol

- It is possible with LN