What does "crackable, unencrypted" mean?
What are you asking the devs to encrypt and isn't "crackable" redundant when we're talking about software networks this far after 9/11?
Discussion
by "unencrypted" I mean this: (1) all 16 members of the ring signature are provided in plaintext -- everyone can see them (2) the "real" sender is definitely one of them -- only 15 ring members are decoys, you can't make them "all" decoys because, as part of monero's design, you must put the real sender's pubkey in the ring signature
by "crackable" I mean this: chain analysts can use data from their own wallets and those of their partners to eliminate some of the decoys in the ring signature -- e.g. if one of the decoy pubkeys belongs to them, and they know they didn't sign the transaction, they can remove that decoy, thus narrowing down the list of possible senders. Often, they can narrow it down to just one person, thus "cracking" monero's ring signature privacy and identifying the real sender. Here is a video where they do this multiple times, starting at minute 26:55
1. I clarified the main question already: what are you asking the devs to encrypt here that they haven't already? In other words, what's the problem?
2. Everyone knows modern computer networks are "crackable," encrypted or otherwise, but you threw the word "crackable" in there. I was noting how weird that was and how you put it next to the word "unencrypted" like there was supposed to be some connection
1. I clarified the main question already: what are you asking the devs to encrypt here that they haven't already? In other words, what's the problem?
2. Everyone knows modern computer networks are "crackable," encrypted or otherwise, but you threw the word "crackable" in there. I was noting how weird that was and how you put it next to the word "unencrypted" like there was supposed to be some connection
Weird, this appears to have double sent.
Nostr is having a lot of issues today nostr:npub1syjmjy0dp62dhccq3g97fr87tngvpvzey08llyt6ul58m2zqpzps9wf6wl
Mainly text input issues so far
> what are you asking the devs to encrypt here that they haven't already? In other words, what's the problem?
I recommend the devs (1) implement payment channels so the sender can create his payment data on a second layer instead of the base layer (2) implement onion routing between payment channels so that even the sender's channel counterparties aren't in a position to know if he's the sender or not (3) within those channels, actually encrypt all communication between counterparties so that ISPs can't read it (4) do not publish payment data on a blockchain, not even the encrypted blobs transmitted between channels
Or, you can just use lightning, because it already has all of those features
So you don't actually have any point here
You can just use Monero over Tor, why would you use lightning?
Smart people don't want a "layer 2" that doesn't use a decentralized p2p blockchain like the original
Even when you use monero over tor, the sender still has to publish his transaction info on the blockchain, including (1) the sender's pubkey (2) the recipient's pubkey. That is bad for the privacy of both parties. So don't do that. Lightning fixes this.
> Smart people don't want a "layer 2"
Smart people don't want to publish all of their transactions for everyone to see (and analyze)
Oh so you're one of those people that thinks it's better to only have lightning invoices and never use wallet addresses? 🤣
How would the actual layer 1 work then? Or is it just different there?
Don't waste your time on this monero bot.
People shouldn't waste their time on gangstalkers like you
Do you actually tell yourself I'm a bot to feel better about yourself or is that just an insult you like to use online?