About direct messages, what I have in mind is this:
1. Nobody can see who is messages whom
2. Even access to the nsec will not reveal this
3. When you delete a message it's really gone (from your side)
4. You can only use one device for DMs at any given time (though you can sync between devices using some other protocol if you really really want to offer redundant storage to the cops)
Once in a while your client generates a random new DM key and publishes the public key in an announcement. You client also keeps track of public keys of people you follow, or even just any DM public key it sees announced.
If A wants to send a message to B they generate a shared key using a diffie-hellman exchange (or something fancier). This is an ephemeral Nostr account. A posts a message using that new account, and encrypted such that only that account can read it. B should be monitoring all such potential accounts.
Each message contains a new random public key, so each reply is a new account. This means you really have to catch every message, so your conversation might get stuck.
These messages should be posted using the anonymous posting thing I described earlier.
Optionally when you announce a public key, you also publish a more narrow list of relays that others should use to reach you and that you use to post messages. This saves costs.
Paying relayers per note using e-cash tokens... aka Nostr meet Pastebin.
This makes it easier to post using a throwaway account. Relayers should announce which e-cash tokens they support, and their pricing. At minimum there should be a price per kilobyte day of storage (but pricing could be more complicated if needed).
A client then creates an envelope, which could be a regular Nostr note. This contains the e-cash tokens needed for payment, encrypted to the public key of each relayer that you want to use. The envelope also contains the actual message that you want to post.
Relayers can discard the envelope if they wish, so they don't have to store and upload all those tokens.
Something similar can be achieved with just a regular lightning invoice too, e.g. using lightning API keys: https://docs.lightning.engineering/the-lightning-network/l402
The envelope could be delivered over Tor, so it's nice if relayers list a hidden service.
Clients should track that their message is actually relayed. Just reuse the tokens if they're not claimed.
"Assuming the vigilante’s accusations are true, that would mean this individual accessed the private keys of Russian-controlled addresses, either through hacking or collaboration with an insider."
Or that GRU noticed what happened and started tagging Ukrainian (or random) addresses in the hopes of getting them blacklisted by gullible western chain surveilance companies. Which would explain why the article is deleted.
I guess Chainalysis deleted this due to some innacuracy, so take it with a grain of salt. But it seems people are doxxing military related Bitcoin addresses using OP_RETURN messages. Of course anyone can make any claim that way and we all know how trustworthy Chainalysis is, so I don't know what to make of it.
#[0] is there a way to see via which relay(s) a note was discovered? There's a couple that show up in Damus but not on Amethyst, which suggest I should probably add a relay somewhere?
You can't be zap-only with a custodial lightning account. I don't make the rules.
Is it possible to run a personal relay on a server that connect to other relays to sync stuff relevant to me? That way I can put that on a place for which exposing the IP is fine. And it would reduce bandwidth between my phone and that relay.
That's indeed the biggest change. This case might drag on for a long time. A 5000 page dossier, complex subject matter, languagebarrierc. It may set important precedent for anyone working on open source privacy tech, so both sides might want appeal the result too.
I hate waking up early... but at least there was some good news in the Tornado Cash trial.
Did Stamps destroy #bitcoin? #[1] and I explain what they are and how they relate to the two* invalid blocks that were recently produced:
* = one at the time of recording
I can't believe there are wallets out there that don't randomize the change output position. I guess fixed-amount mixers have an excuse not to since it doesn't matter and looks nicer.
But this is so helpful that they use the change strategy as the first step in their algoritm.
It's a bit awkward to have to follow yourself in order to see your own posts in the timeline. If only for the purpose of knowing it was sent. Do client authors hate themselves so much that they don't want to see their own stuff? :-)
(Of course you can still collude with yourself to setup a bunch of sock puppets and pump money in circles to make yourself look popular. Any ranking based on zap amounts could be done client-side by e.g. only including N degrees of separation from people you follow)
The plugin asked, so I gave it. I'm a simple man.
Mmm, I'm seeing this in the log:
fail: BTCPayServer.Plugins.NIP05.Zapper: Error zapping to wss://nostr.sethforprivacy.com
#[0] one more feature request: I'd like to be able to self host images. Perhaps you can add an upload URL setting (with some auth) so people can clone whatever you're running to host themselves?
Just realized there was a plugin. A bit annoying that it needs (?) a private key to receive zaps, but I guess that's part of the protocol.
Please try again...
Thanks! I'm seeing two settled payments in BTCPay, but nothing under Zaps in either Damus or Amethyst. Maybe I'm missing something...
#[3] / #[4] any idea?