[-] Krugtron9000@monero.town 2 points 6 days ago* (last edited 6 days ago)

it’s weird that they are able to ddos an onion. i thought tor had pow mitigations?

I want to know about this too. Why didn't you use HiddenServicePoWDefensesEnabled?

[-] Krugtron9000@monero.town 1 points 6 days ago

It's only three hops if, like Trocador, you don't need to hide the location of the server. They can (and should) enable HiddenServiceSingleHopMode. This hides the location of the client but not the location of the server. Six hops is only for darknet sites that need to hide the server location.

[-] Krugtron9000@monero.town 2 points 6 days ago* (last edited 6 days ago)

suffering non-stop DDoS attacks for the last three weeks, and they are using ToR exit nodes to conduct such attack

This doesn't add up:

  1. Exit nodes are not involved in onion site visits. Exit nodes are only involved in connections from Tor to the clearnet.
  2. The tor network itself does not have a particularly massive amount of exit node bandwidth, and anybody trying to use a large fraction of that will attract the attention of the tor developers. I have a very hard time believing that the bits per second you can push through tor exits result in a bandwidth bill that a popular exchange (like yours!) has any difficulty affording.

Blink twice if you've been threatened by a three-letter agency.

Good luck,

[-] Krugtron9000@monero.town 1 points 6 days ago

WASM is the millennials getting their turn to learn that "those who do not learn from history are doomed to repeat it".

Letting the bloated web offload more of its bloat to clients will simply result in an even worse web obesity crisis than already exists. The computational burden needs to stay with the side (the content producer) that has the ability to reduce the level of bloat. Anything else is a broken incentive structure.

[-] Krugtron9000@monero.town 4 points 6 days ago* (last edited 6 days ago)

This is precisely what Hashcash is. Hashcash is widely acknowledged as the primary ancestor of Bitcoin.

Also, Tor now has a system like this built-in. It uses PoW. It's quite new (less than a year old) and you have to explicitly enable it, but I'm sure the trocador admins know about this.

But seriously, regarding enshittification, I don't think javascript makes websites any harder to ddos. Rather, you get ddossed until you cry uncle and comply with the demands that you help MITM and fingerprint your customers. Javascript happens to be useful for fingerprinting. It has very little to do with ddos mitigation.

[-] Krugtron9000@monero.town 5 points 3 weeks ago

I also don't understand why websites are still using bespoke hand-rolled XMR payment frontends -- unless they are exchanges or (like localmonero) super-Monero-gurus... BTCPay server's Monero support is so good at this point... I have used it uncountably-many times and not once had any kind of problem.

Please folks, if you're going to accept Monero, consider using BTCPay Server.

[-] Krugtron9000@monero.town 5 points 3 weeks ago* (last edited 3 weeks ago)

First, make sure the transaction was completed for the correct amount net of monero transaction fees.

Yes, I absolutely made sure of that. Even waited for all ten confirmations.

One ~~secure~~ way to contact them is through matrix.

FTFY. And of course the (still!) embargoed clusterf*ck. Don't roll your own crypto, kids.

28

They will just take your money and not activate your account.

You can't contact them securely, because their only support contact is email but the PGP key on their website is corrupted (you can't re-wrap the lines of a PGP key!) and even after fixing the corruption it turns out that they forgot to publish their encryption key (the published key is signing-only).

So there's no secure way to contact them.

Total waste of my time and money. This is why everybody uses Mullvad.

10

Only half-joking. Your website spins at 100% cpu on my machine (firefox). Unfortunately it's one big fistulated mass of minified javascript so, not really debuggable.

sigh i miss the days when the web wasn't an app-delivery mechanism.

[-] Krugtron9000@monero.town 2 points 1 month ago

Not objecting or disagreeing, but could we get more than a one-line explanation for breaking protocol changes? maker selects arbitrator (breaking change) does not inspire a whole lot of confidence. Is there a discussion somewhere I can read that spells out the options and why this one was selected?

[-] Krugtron9000@monero.town 1 points 1 month ago

when/why was one ever required?

[-] Krugtron9000@monero.town 1 points 1 month ago

I think the many competing messengers are a good thing.

If they were backward-compatible (with their predecessors) and interoperable, I would agree. But they absolutely aren't. The lack of backward compatibility in the chat/messenger space is abhorrent.

[-] Krugtron9000@monero.town 1 points 1 month ago

It seems like everyone is trying to drag me to their favorite messenger

Yes, because people treat messenger choices as a popularity competition.

Look how many people I got to switch to crapware just because they wanted to chat with me! I must be super socially powerful! Woo hoo! Meanwhile, the technical consequences of this strategy are... predictable: crapware.

Opt out of all the noise and just stick to IRC.

[-] Krugtron9000@monero.town 7 points 1 month ago

Everybody reading this message should also read this, since it gives the details: https://github.com/haveno-dex/haveno/blob/master/docs/deployment-guide.md#register-keypairs-with-privileges

There are no servers in Haveno. Instead, there is a "developer (public) key" hardwired into the client. Instead of the owner of the localmonero.co domain (and TLS certificate, and onion url key), there is the "developer public key". The developer public key you have in your client basically decides "whose Haveno" you want to use. This is a good thing! I always worried about the localmonero.co domain being seized by a simple letter being sent to their registrar. With the developer key system this can't happen. The thugs have to actually go hunt down whoever has this key. The key isn't even kept online (like a TLS key or an onion key).

Whoever has the developer key decides who the arbitrators are. Just like localmonero -- whoever owned the domain name got to decide who the arbitrators were.

I think OP's posting is kind of an unnecessarily-scary way of saying that the client ought to ask the user to type in this key (or several of them!) at installation time, instead of being compiled in. That is a great idea.

view more: next ›

Krugtron9000

joined 1 month ago