[-] Saki@monero.town 1 points 11 months ago

Imho this idea seems a bit too pushy, while your monero.im multisig escrow experiment is respectable. (I have nothing against you personally. Some of your ideas are interesting! Ideas and a person are different.)

You claimed you’re a “Trusted Monero Community member”; you claimed “I’m pretty known” To cover up these false claims “retrospectively”, now you’re trying to become better-know here (so your pro-profit business might be successful).
Recently you made several questionable moves: you said your page is no-js no-log but CF becon js is there. You didn’t understand Tails uBO subtlety either. And you disrepect Trocador.app … Frankly your posts seem a bit iffy. Nevertheless, some of your ideas might become splendid ones :)

[-] Saki@monero.town 1 points 11 months ago

I’ll accept that you’re saying you did this out of good will. So you too can accept that the results were not necessarily ideal, as many instances are not (or no longer) exactly Tor-friendly.

When talking to Tails users next time, you might want to consider nitter.oksocial.net (officially used by EFF too)

[-] Saki@monero.town 1 points 1 year ago

can’t read; access-controlled/non-libre

[-] Saki@monero.town 1 points 1 year ago

we’ve demonstrated that GitHub is fine as a platform for collaboration, knowing that we will detect any malicious activity on GitHub’s part really quickly as git acts almost as a blockchain

I don’t worry about source code integrity, but purely privacy-wise, it’s far from being ideal that users must access GitHub, monitored and recorded everything by Micro$oft.

The CCS Wallet Incident is sad but not surprising. Something that could happen as a human may make a mistake. “Normal” Monero users still love to use Reddit, Twitter, Windows 10, or Github, which is much more puzzling.

[-] Saki@monero.town 1 points 1 year ago

True. And no one even knows (yet) what was the problem to begin with.

[-] Saki@monero.town 1 points 1 year ago

Nothing is sure. It might be skilled attacker(s), it might be simply bad opsec, or it might be an inside job. Several people think and say that we need to minimize trust via mltisig (in retrospect, this seems so obvious but that’s just hindsight).

[-] Saki@monero.town 1 points 1 year ago

Looked into my key ring and found only a few RSA2048 keys (used by old Proton users). Apparently most devs use Ed or RSA4096 to sign today. Even Thunderbird (its OpenPGP is convenience first, security second, in a sense that your sec key is not passphrase-protected) generates at least RSA3072, RSA2048 is not even an option!

Though this news might be a joke, it’s totally possible that RSA2048 (or RSA itself) becomes eventually obsolete. Which doesn’t mean cryptography in general will be broken, of course. There are different kinds of "one-way" problems, like Ed, already widely used, based on elliptic curves.

If a faster factorization algorithm is found (though that may be proved to be impossible after all), it’s essentially great news. Even Gauss said, “the dignity of the science itself seems to require that every possible means be explored for the solution” (of primality test and factorization), meaning “We must try everything to find a better way to factor a big number!” (which also implies “a more effective attack against RSA!”).

Though no one wants broken cryptography, factorization is something number theorists would love to do quickly too, if possible at all.

See also [not directly related]: https://en.wikipedia.org/wiki/Logjam_(computer_security)

[-] Saki@monero.town 1 points 1 year ago

Yes, actually trying and seeing is the best way, if you’d really like to fine-tune anything. I don’t have much technical knowledge but empirically, any value may be about as good as another, if not too extreme. The end results might be about the same no matter which you use: 64, 80, 96, 128, etc. and just using the default settings may be good enough.

P2Pool may be somewhat special, as it’s not just about running a full-node but you have to run like 3 tools (each possibly resource-hungry) at the same time.

[-] Saki@monero.town 1 points 1 year ago

fyi p2pool README says:

--out-peers 64 --in-peers 32 is needed to (1) have many connections to other nodes and (2) limit incoming connection count because it can grow uncontrollably and cause problems when it goes above 1000 (open files limit in Linux). If your network connection's upload bandwidth is less than 10 Mbit, use --out-peers 16 --in-peers 8 instead.

[-] Saki@monero.town 1 points 1 year ago

A privacy-centric hosting company having in-house DDOS-protection would be ideal? This basedflare thing may be better than CF, though it feels exactly like CF for me an end user. Their error message is unhelpful too:

Verifying your connection to basedflare.com This process is automatic, please wait a moment... Error: Browser does not support WebAssembly.

A more-friendly error message would be: Use the “Standard” Security Level in Tor Browser; “Safer” “Safest” wouldn’t work for this. (Brave Search actually says something like that, nice to Tor users, though I seldom use Brave Search…)

[-] Saki@monero.town 1 points 1 year ago

Yeah… When I write about Haveno here, I kind of always add “hopefully!“ or “is coming?” (a ?)… I don’t think it’s a scam but…

[-] Saki@monero.town 1 points 1 year ago

I too would like to believe that the people working on it are well-intentioned, not scammers. What @moneromaxi pointed out seems to be somewhat different, though. Like, the development may be legit but overpriced. Maybe, maybe not, I’m not sure. One thing I can tell is, in 2011 it was said that Haveno would be released in 2022 and now 2023 is ending (two-whole-year delay). I hope it’s just being delayed!

view more: ‹ prev next ›

Saki

joined 1 year ago
MODERATOR OF