When are you going to get rid of the trade limits?

Nobody will take it seriously until you do.

Are you daft, man? Just remove the absurd trade size limits.

There are multiple professional traders from LocalMonero who won’t touch Haveno with a ten-foot pole until you fix this. You’re killing your own market. The really good traders’ time is valuable; the per-trade overhead is way too high for the limits to make sense, so all you’re left with is the clowns.

This is like complaining that your new EV doesn’t have a large enough gasoline tank.

Haveno is something much better than federated: it is decentralized.

Anything that you “can access on your browser” can and will be shut down.

Browsers and WebPKI are designed to guarantee this.

You’re gonna have to let go of your browser obsession. Or just not get what you want. One or the other.

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?

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.

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,

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.

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.

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.

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.

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?

when/why was one ever required?

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.

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.

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.