Monero Is Less Untraceable Than It Seems - <AUTHOR> https://www.wired.com/story/monero-privacy/ <comment><USER2> I hate how everyone always stresses the illegal uses of Monero in these conversations about traceability. Monero has a lot of legal uses, many of which are listed here:

[https://www.monero.how/why-monero-vs-bitcoin](https://www.monero.how/why- monero-vs-bitcoin)

The big one for me is privacy:

"The most critical flaw in Bitcoin is its lack of privacy. If you give me your Bitcoin wallet address so that I can send you a payment, you immediately compromise your privacy. I can see as a matter of public record how much money you have in your Bitcoin wallet "

I don't want other people to know how much money I have when I pay them for goods and services or how much I have paid to others in the past. This wouldn't happen with a bank account but could happen with bitcoin.

I don't necessarily want people I am negotiating a contract with to know my hand. It potentially gives them an unfair advantage.

If my Monero transaction history can be figured out by a government agency with lots of resources but not the average business, that doesn't necessarily invalidate Monero for my use cases.

<comment><USER3> To me this feels like concern without regard for the full differences. With bank accounts you usually have the restriction of "as many accounts as you can afford" where with bitcoin addresses you can have countless. So someone could just as easily watch you drive up to the bank and know you bank there. Keep your private addresses private, duh.

<comment><USER4> Yeah, but lets say you make a website and want to accept donations using bitcoins. What you generally do is put "donations welcome at <bitcoin address>!" (I see this all over the place). Are you saying that webmasters should write a script that generates these public/private keys on every page hit, and then somehow stores all of those millions of private keys... somewhere? On your server? Or do you have to build an entire infrastructure of key exchanges to some safe place just so you can accept bitcoin donations privately?

<comment><USER5> Why would it have to be "donations welcome at <bitcoin address>!"? There's plenty of ways to ask for donations and it doesn't always require to have a single address shown. You can have a "Donate" button that when clicked, ask for a generated wallet (all from the same private key but that would be a different wallet still) and show it with a QR code in bonus.

<comment><USER4> Look, I'm not making this up. Lots of people and projects do exactly this. Tails, the super-secure privacy-focused version of Linux asks for donations in exactly this way [1] (and if you go to blockchain.info you can see a full wonderful list of all the bitcoin addresses who have donated to them [2]). It's a totally reasonable way to set up bitcoin donations (hell, it's even recommended by the bitcoin wiki! [3]) and it's a significant weakness of bitcoin that these transactions are not private.

It is absurd defense of bitcoin to say "well, it COULD just be as private as these other things, if you only jump through ten more technical hoops and not use bitcoin as intended". Clearly, these other cryptocurrencies offer something that bitcoin doesn't.

[1]: [https://tails.boum.org/donate/?r=contribute](https://tails.boum.org/donate/?r=contribute)

[2]: [https://blockchain.info/address/1BvBMSEYstWetqTFn5Au4m4GFg7x...](https://blockchain.info/address/1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2)

[3]: [https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin](https://en.bitcoin.it/wiki/Receiving_donations_with_bitcoin)

</comment></comment></comment></comment></comment><comment><USER6> I'm on the Monero Research Lab team. This article, like most media coverage of academic research, ignores much of the subtlety behind the research. The likelihood that a particular output is positively identified depends heavily on its age relative to our regular protocol upgrades. And it's not like we aren't actively working on ways to improve anonymity. We're in the process of updating the way we choose our fake outputs and discussing best practices for handling very old outputs. I always appreciate research into ways to improve Monero, but I don't think this article does the research justice.

<comment><USER7> I'm not involved with any cryptocurrencies, so I have no dog in this fight. I am curious, however. Whenever ZCash comes up Monero is mentioned as "also providing" anonymity.

Being on the Monero team, can you comment on the differences between the privacy guarantees provided by the two platforms?

<comment><USER8> I'm a user who picked the Monero side of things. Here's the short run down on the difference and why I ultimately sided with Monero.

Monero uses ring signatures to prove that one out of n people signed a transaction without revealing which one of the n. Over the course of k steps the possible transaction history might be in any of n^k states. Typically n=5.

Zcash uses Zero-Knowledge-Proofs for anonymity. Any private zcash tx may have gone to or come from any other private zcash tx.

Here are the problems with Zcash as I see them

1) trusted setup. There is some toxic seed data that needed to be destroyed at the time Zcash was created. With that seed you could inflate the coin as much as you want. There was an elaborate ceremony of 6 people (5 of them Zcash employees) showing the seed was destroyed. But elaborate ceremony isn't cryptographic proof.

2) privacy is optional. If a transaction goes from non-private address, to private address, to non-private address it is traceable. The Zcash anonymity set is actually very small.

3) Zcash is a company. I consider the political structure of a coin (or lack thereof) as an attackable surface. A government can force Zcash to back-door their software (hi NSA). There is no head of Monero.

<comment><USER9> On 2: Monero is almost the same. ShapeShift does 7-15% of all tx at least. How many transactions are actually private after you consider hacks or LE warrants? Those TX are what you depend on to get false spends.

On 3: How many people must agree in order to change something in Monero such as HF parameters like ringsize? There is not a single company but it looks [to an outsider like me] as a similar position.

I chose Monero too for similar reasons inc ZCash people openly saying they support backdoors for LE [but promising ZCash would never have them]. And taking 20% of block reward and not doing anything useful with it [for millions I expect really polished clients and some quick upgrades].

But the low ringsize is weak [hence going from 3 to 5 to now 7]. All ring members are not equal to n^k is very naive. Fee, ringsize, payment ID, in/out count are all metadata that distinguish on-blockchain. Let alone off- blockchain such as keys being hacked/warranted.

Given this and Monero's lack of disclaimer or warning at all about how to use it safely... a paranoid person might suspect ill-motives. [Consider: MyMonero, the Monero 'lead' Web Wallet, goes out of its way to suggest users use a few higher ringsizes to get better privacy, when we know this makes their TX stand out. This is something that presumably he could change with 1 or 2 lines of code but has not.]

<comment><USER8> >On 2: ...How many transactions are actually private after you consider hacks or LE warrants?

That's actually a difficult question. I won't try to estimate here. But IIRC something like 95% of ZCash tx are non-private by user opt in, and the remaining 5% are also vulnerable to things like warrants at the exchange and timing attacks. So the bar is set really low for Monero to have the best anonymity set of all privacy tokens.

>On 3: How many people must agree in order to change something in Monero such as HF parameters like ringsize? There is not a single company but it looks [to an outsider like me] as a similar position.

I think Monero is in a similar-but-better position. True the core team _can_ be compromised and true the core team _is_ more powerful than others. But I view this as a necessary centralization to get the ball rolling. I want the Monero core team to eventually be more hands off. Spagini's "I'm not a CEO" statement inspires confidence.

>But the low ringsize is weak [hence going from 3 to 5 to now 7].

can't wait for bulletproofs!

>All ring members are not equal to n^k is very naive.

I was intentionally very cautious with my words here. What I actually said was "Over the course of k steps the possible transaction history might be in any of n^k states". I did not say that all n^k states are equally likely. The actual amount of entropy in the Monero blockchain is much harder to explain/estimate so I used n^k as an upper bound.

<comment><USER9> >and the remaining 5% are also vulnerable to things like warrants at the exchange and timing attacks

I was under the impression that no exchanges handle shielded transactions. What do you mean by timing? I would assume you go t-z-t and leave it quite a while as shielded.

>can't wait for bulletproofs!

Bulletproofs do not help verification time which is why we have low ring size. Going from 5 to 21 ringsize only increases size 8%. 15 is even less, a reasonable compromise on size. There is an unspecified perf target that must be met on verification.

<comment><USER8> >I would assume you go t-z-t and leave it quite a while as shielded.

Many people skip the "leave it a while" step.

Also you can look at things like x-amount left this exchange and y-amount entered this exchange.

</comment></comment></comment></comment></comment></comment></comment><comment><USER10> This was a well-known design choice where the user could balance between transaction size and privacy--people who preferred faster/cheaper transactions chose to sacrifice untraceability. Nowadays, the default option enforces higher untraceability.

Also, some of the authors of the research paper mentioned in the article are part of the competitor Zcash group who sensationalise common knowledge to undermine Monero. Zcash is a US-based company that has a trusted setup which was possibly backdoored [1], one of their scientists and inventor of Zerocoin protocol publicly supported backdoors [2], and their CEO and cofounder suggested backdoors as well [3].

I would read more about Monero before dismissing it, as it's one of the very few legitimate groups in the space besides Bitcoin.

[1] [https://twitter.com/peterktodd/status/793584540891643906](https://twitter.com/peterktodd/status/793584540891643906)

[2] [https://www.newscientist.com/blogs/onepercent/2013/03/bitcoi...](https://www.newscientist.com/blogs/onepercent/2013/03/bitcoin- zerocoin.html)

[3] [https://twitter.com/zooko/status/863202798883577856](https://twitter.com/zooko/status/863202798883577856)

<comment><USER11> It's fine if you want to defend monero's technology, but attacking the researchers credibility because of their association with a competing project? That's some weak sauce in my opinion.

One side is actually doing the work and publishing attacks, even if they are against zcash (shielding/deshielding). The other has some questionable twitter conversations about a hypothetical backdoor. Zcash zk-snarks are backdoored? Proof of concept or GTFO is the law of the land, my dude.

<comment><USER10> Oh, and I forgot to mention they were also sponsored by DARPA. You can pretend these are all irrelevant arguments and wait for your proof, but the reality is that reasonable doubt and ad hominem are sometimes appropriate, especially when dealing with privacy. It's on them to prove their trusted setup can be trusted, and everything they've done is antithetic to trust.

<comment><USER9> Trusted setup only compromises the supply integrity not privacy. I am not a fan of Zooko or the Green comments on backdoors and LE but do not misrepresent trusted setup.

<comment><USER10> >only compromises the supply integrity

Conveniently, it's impossible to audit whether more coins are being minted right now to add to the developer tax already imposed on block rewards.

Don't think I misrepresented trusted setup--only warning others about the reputation of Zcash. Anonymity for some can be a critical issue, so I don't think everyone can afford to wait for "proof of backdoor" before making their decision.

<comment><USER12> Deanonymizing zcash's shielded transactions requires breaking the preimage resistance of sha256.

<comment><USER13> Technically, you could also break the encryption used in the memo field. But thats bog standard cryptography

</comment></comment></comment></comment></comment></comment></comment><comment><USER14> I think GNU Taler[1] solves the untracabilty problem in a way that most people should be happy with. Consumers have all of their transactions private from everyone (the seller cannot tell how much money they have, what other transactions they've made, or where the money comes from; a government cannot tell what transactions a person has made). But seller transactions can be audited for tax reasons, to avoid tax fraud.

And best of all, it's not yet another cryptocurrency. It's a payment system that works over any currency (traditional VISA, or crypto-currencies). Of course, this means that Taler "tokens" cannot be used as a store of value, other than as a proxy for the underlying store of value. So you would only hold Taler tokens like you would cash in your wallet.

They even have really nice easy integrations into browsers and backend processing.

(I don't work on GNU Taler, I've just been saddened that such an interesting project has gotten so little press outside of GNU circles.)

[1]: [https://taler.net/](https://taler.net/)

<comment><USER15> GNU Taler wants to give the government a backdoor. That's privacy in the same way the Clipper chip in the 1990s was privacy.

<comment><USER14> This is a misunderstanding of GNU Taler, unless you're using a completely new definition of the word "backdoor". Customer transactions are completely anonymous -- that's the anonymity guarantee provided by GNU Taler. Mints are auditable (the amount of coins they've given out and received, and that they haven't given money to people who didn't have the associated coins). And thus how much money a particular merchant has traded to the mint for real currency can be figured out. There is no reasonable analogy between this (which has a given set of privacy guarantees, but not others) and the clipper chip (which was an attempt to remove all privacy guarantees from all cryptography).

The only way you can consider this to be a backdoor is if you think that allowing a government to know how much money a business has made (something that you are legally required to declare for tax purposes) is a bad thing. This seems like an immature view to me -- taxes are very important for a country to continue functioning.

<comment><USER15> According to the website, GNU Taler gives governments an exclusive view of all of a merchant's private transactions:

[https://taler.net/en/governments.html](https://taler.net/en/governments.html)

"With Taler, the receiver of any form of payment is easily identified by the government, and the merchant can be compelled to provide the contract that was accepted by the customer. Governments can use this data to tax businesses and individuals based on their income, making tax evasion and black markets less viable.

Thus, despite offering anonymity for citizens spending digital cash to buy goods and services, Taler also ensures that the state can observe incoming funds. This can be used to ensure businesses engage only in legal activities, and do not evade income tax, sales tax or value-added tax."

It's not a backdoor in exactly the same way the Clipper chip was, but it's a backdoor nonetheless.

The fact that the government is the gatekeeper in GNU Taler means that it would have been unable to empower people to get around the financial blockade against Wikileaks the way cryptocurrency did.

That's a practical consequence of giving up privacy and decentralization.

>>This seems like an immature view to me -- taxes are very important for a country to continue functioning.

It's not immature to point out that this gives the government a backdoor to monitor private transactions.

You think this reduction in privacy is necessary to levy sales/income taxes. That's a value judgment, not a refutation of the fact that this is a backdoor.

Something doesn't stop being a [negatively associated noun] because you think its effect is positive.

Speaking the truth instead of sugar coating it for ideological reasons is not immature.

<comment><USER14> > That's a practical consequence of giving up privacy and decentralization.

(Most) cryptocurrencies don't have privacy (quite the opposite). The reason why the government couldn't stop cryptocurrency transactions is that they were decentralised.

However, I also believe you're wrong in this case. Anybody can set up a mint, and so it would be entirely possible for a Bitcoin mint to exist (in fact I believe several already do). People could buy Taler tokens from the mint and then send them to Wikileaks. When Wikileaks cashes in the tokens, they are sent (using Bitcoin) to Wikileaks. While the government would be able to tell how much money Wikileaks received, they would not be able to stop the underlying funds transfer (through Bitcoin). Yes, they may be able to try to punish the mint for permitting such transactions, but this would be the same as punishing Coinbase for allowing people to send those transactions as well.

But if you're running a business and you don't want the government to know how much revenue you've made (which means you're running an illegal business from a tax perspective) then yes, you wouldn't be able to use GNU Taler. This is a benefit, because creating a system that encourages tax fraud is one of the easiest ways to have the government ban that system's usage.

> but it's a backdoor nonetheless. [...] not a refutation of the fact that > this is a backdoor [...] Something doesn't stop being a [negatively > associated noun] because you think its effect is positive.

You are using the term "backdoor". The only reasonable definition of this term is "a method (often secret) to allow an entity to bypass authentication or encryption of a particular system" (which is the common usage of the word).

This does not apply to GNU Taler, because no encryption or privacy guarantee is being bypassed. When you use GNU Taler as a merchant you are aware that your transactions are audiable by the government for tax purposes -- if you don't want that to be the case then you can choose not to use it. Almost all legitimate businesses would not have an issue with this, because they have to declare revenue anyway.

A backdoor would be if Monero had a way to deanonymise transactions, so that governments can figure out what people spent money on. In that case, a privacy guarantee of the system has been subverted.

<comment><USER15> >>(Most) cryptocurrencies don't have privacy (quite the opposite). The reason why the government couldn't stop cryptocurrency transactions is that they were decentralised.

They can be used in ways that give the user privacy. They're pseudonymous. But yes, a big part of why they can't be stopped is that they're decentralized.

But that decentralization only works if users have some degree of privacy. If governments knew every participant's address, that decentralization would effectively vanish.

>>Yes, they may be able to try to punish the mint for permitting such transactions, but this would be the same as punishing Coinbase for allowing people to send those transactions as well.

Coinbase would not allow transactions to Wikileaks if the financial blockade were reimposed on it.

GNU Taler states that it is designed to prevent illegal use, and if it is accurate in its claim, then it will prevent Wikileaks from using it during a financial blockade.

A technology's susceptibility to government control doesn't discriminate based on the moral justification for the government wanting to exert that control.

That's why one has to acknowledge that there's a trade off to be made, and decide which trade off is more conducive to a functional society.

I personally think empowering individuals rather the surveillance state is the better trade-off.

>>This does not apply to GNU Taler, because no encryption or privacy guarantee is being bypassed.

The Clipper chip did not give any privacy guarantee against government monitoring, yet this channel for monitoring was commonly called a backdoor.

</comment></comment></comment></comment></comment></comment><comment><USER16> > That shouldn't just worry anyone trying to stealthily spend Monero today. It > also means evidence of earlier not-quite-untraceable payments remain carved > into Monero's blockchain for years to come, visible for any snoop that cares > to look.

This is the key point from the article and it applies to every cryptocurrency. Just because a crypto seems anonymous now, does not mean it will be forever, and all the transactions from "now" will still be on the blockchain "forever." Almost ironically, scrutiny of a currency increases with its usage, so you're probably better off just not using cryptocurrencies to commit crimes.

P.S. Anyone got the link to the paper? Can't believe wired didn't even link to it

<comment><USER17> [https://arxiv.org/pdf/1704.04299/](https://arxiv.org/pdf/1704.04299/)

</comment></comment><comment><USER18> Every single time something seems to claim to be untraceable or anonymous, it seems to hold for a while, and then there's a "<X> is not as safe as we thought" headline.

Seems to be a good rule to just not trust anything.

<comment><USER19> Or assume the government has unlimited resources to throw at a problem, and not commit crimes.

Most of these headlines describe something that would require nation-state resources to crack. If you wanna hide paying for something legal, it's probably still sufficient.

<comment><USER20> "Not commit crimes" is a good maxim when you're living in a liberal democracy (and even then …). It's less easy when the state outlaws things unjustly. Like being gay. Or being (a)religious. And to give just two examples that apply to (otherwise) liberal democracies, most people would include "personal, recreational drug use" in the same category. And there are Western democracies that outlaw certain sexual acts between consenting adults (e.g. Germany, which outlaws _any_ incest, even between consenting adult siblings), which also rubs many people the wrong way.

In sum, "not [committing] crimes" isn't always straightforward.

<comment><USER21> I was with you every step of the way, then suddenly you were defending incest and I was like "how the hell did I end up here?"

Also, while "many" is a subjective term, I don't think you're using it correctly here. The idea that you should not regulate sex between consenting adults _in general_ is very popular, but most countries carve out exceptions for sex work. Not saying they should, but _many_ do. And I definitely think the incest legalization lobby must be very, very small, even though it probably has a sympathizer in the Oval Office.

<comment><USER20> > then suddenly you were defending incest and I was like "how the hell did I > end up here?"

… Which nicely illustrates what different people find acceptable. But I agree that sex work would have been a better example. Either way, you felt it necessary to add the qualifier "in general", and many (…) people, though certainly a relative minority, would fundamentally disagree with this qualifier (while talking about consenting adult without power imbalance in their relationship).

</comment></comment></comment></comment></comment><comment><USER22> Who would've thought cryptocurrency guys would inflate whatever valid claims they might have had?

> After more recent changes to how Monero chooses its mixins, that trick now > can spot the real coin just 45 percent of the time—but still narrows down > the real coin to about two possibilities, far fewer than most Monero users > would like.

Note that this is still a break, because quick Googling says that there are usually 4 mixins, so random chance would be 20 %.

<comment><USER23> Even more recent changes have made this better too. The research in the paper only goes up to Apr. 2017 or so. Since then, the "recent zone" has been a) reduced from 5 days to 3 days, and b) more recent zone mixins are included. We haven't quantified what improvement that makes, but it should help.

</comment></comment><comment><USER24> Cryptocurrency: hi, im a distributed, permanent record of all the transactions you make. Dark web: ooh look, anonymity!

<comment><USER25> I have often wondered about the sanity of people who are using a blockchain based currency across tor. Admittedly, I haven't fully checked my assumptions here, but my initial thoughts on the matter have always been that I'd be amazed if it was a good idea from a security perspective.

</comment></comment><comment><USER26> What about zcash? As I understand it has much stronger privacy, but almost nobody understands it so people are skeptical. I'm surprised it doesn't get more attention.

<comment><USER27> This isn't really true. Zcash isn't private by default, which weakens the concept for anyone who wants to use the privacy features. If not many people are using them then analysis of the transactions that are meant to be private becomes easier.

Zcash is also not trustless because it requires the trusted setup. You have to trust that the developers completely deleted the "toxic waste" during the setup, and that their machines were not compromised (which is totally possible given Meltdown, etc). Recovery of this toxic waste can lead to unlimited coin minting. Another problem with this is that future changes to some properties of the currency require another trusted setup.

<comment><USER9> Private-by-default is semi-dishonest. Many tx on Monero are owned by a few entities that are friendly with LE or may get hacked. Thus all those exchange tx or payment gateway tx that are on the blockchain are in practice transparent to the right people or with time. With Monero they give you a false sense of security with ZCash they are open that those tx are not going to help you.

[ShapeShift does 7-15% at least of Monero tx. Add in BitFinex Binance CoinPayments and some others and where we at?]

</comment></comment></comment><comment><USER28> I think that the timing issues are related to the problems with mixnets for anonymity: it turns out a global passive adversary can observe all messages sent and received and eventually determine which parties are talking to one another, within certain probability bounds. It sounds like a similar issue is at play with cryptocurrency.

The solution with anonymity is to send cover & real messages through the network in such a way that traffic analysis fails. One approach would be to saturate a network link, sending random cover data until there's real data to send, then returning to cover data. There are more bandwidth-friendly schemes as well.

Might a similar scheme for cryptocurrency be to constantly (or stochastically, based on some probability distribution) send money to one's own other addresses? Obviously there's an issue with transfer fees, but maybe this could be a tunable, based on how important your privacy is.

</comment><comment><USER29> well, there are others, I would say, younger and more private and secure currencies than Monero - for example Sumokoin ([https://www.sumokoin.org](https://www.sumokoin.org)), setting Ring Confidential Transactions (RingCT) with minimum ringsize (mixin) of 12 to conceal sources/amounts transferred and make it high resistance to blockchain analysis (Monero does have 4 or something, even I have read devs are planning to increase it?)or even younger Ombre ([https://www.ombre.io](https://www.ombre.io))....

add "illegal only" topic - well, that depends on point of view, for me personally there is always benefit to have real privacy for what are you paying for.. which you dont have with "fiat" currencies or less secure/private crypto currencies..

</comment><comment><USER12> Very good article, doesn't go far enough - monero is not anonymous at all. It misses the biggest issue - that analyzing agencies can spam transactions, generating thousands of inputs daily. A big fraction of other transactions is transparent (shapeshift or other exchanges) to state agencies anyway. As monero has almost no use, cross-chain mixing with bitcoin/ethereum is way, way more anonymous than monero, and in addition can be done in a way that maintains plausible deniability.

Monero is the worst instance of false security in crypto. Unfortunately, at least in my experience, monero users are impervious to these facts, so darknet busts with ridiculous parallel construction narratives aren't going to stop anytime soon. It's not like fbi is ever going to publicly say that monero isn't anonymous to them.

</comment><comment><USER30> Another day, another bunch of irresponsible reporting in the cryptocurrency world.

Wired fails to disclose that the first mentioned correspondent is Andrew Miller of the Zcash foundation. He previously published a blog containing much the same content about Monero.

[https://z.cash.foundation/about/](https://z.cash.foundation/about/)

[http://hackingdistributed.com/2017/04/19/monero- linkability/](http://hackingdistributed.com/2017/04/19/monero-linkability/)

So how much money are some people making today on Monero shorts and Zcash longs thanks to a front page Wired article?

</comment><comment><USER31> Arguably off topic, but do any cryptocurrency experts here know of any studies on the potential economic effects of a truly (or even effectively) untraceable digital currency?

Just off the top of my head I would expect two immediate effects if such a thing really caught on:

1) An increase in many types of illegal commerce.

2) A huge downturn in industries used for money laundering and tax evasion.

These might be highly localized, e.g. a bunch of bars might close in City A because that's how the locals wash money; while in City B there might be a surge in "Anonymero" wealth because they make cocaine and are good at shipping it.

</comment><comment><USER9> Monero has some real issues! These papers are OK but I am not sure if they focus on current practical issues:

Main issue: Ringsize is small. Used to be 3 [why??] got bumped to 5 because 3 is obviously useless. Now getting bumped to 7. The team is taking a very aggressive approach here. Aggressive approaches with security tend not to work. They should be conservative and set the ringsize high then back off later once they have done the research to support a small ringsize.

Users cannot just increase their ringsize. Doing so makes their transactions stick out: different metadata. If you always use, example, ringsize 21: then your tx look different on-blockchain. Despite this, BOTH wallets in common use have features that encourage users to make this mistake. It is like sabotage. The official GUI provides a slider that goes to 26 and says more privacy [you see a good number of of ringsize 26 tx]. The 'official' Web Wallet run by the Monero lead offers a 4-setting: 5 [default], 11 21 & 41\. You see a good number of 11 21 41 ringsize tx because of this.

It has been known for a long time that picking and forcing one ringsize is a good idea yet both wallets insist on encouraging the user to mess up. Not good. No warnings in the wallet, either. We need higher ringsize because the privacy of your transaction going forward depends on other users picking your output as a decoy in their own rings.

Now the small ringsize is made worse by the fact that a single entity, ShapeShift.io, runs 7-15% at least of the network by tx volume! That means with one hack or warrant an attacker will be able to eliminate many fake decoys from other tx rings! How much will a few other exchanges or payment processors make up of the network? 50%? More? Despite this the ringsize stays very small.

The response to all this is 'churn'. This is sending coins to yourself [looks same as sending to other people] so that you obfuscate the connection over time. But despite that this is a core feature of Monero they have provided zero research zero guide on how to do so. They spend money and time researching fancy new maths and this is great. Yet the core functionality to answer the question: How anonymous am I, how mixed in am I, this remains unanswered.

Despite this they refuse to provide any sort of disclaimer. Contrast to Tor Project which makes a big deal of telling users they can hurt themselves and Tor is not some magic. In comparison Monero just claims untraceable & private with no caveat whatsoever. This is irresponsible & reckless, damaging to users and not justified. Only when users start thinking and asking questions are they told oh of course you need to churn but no one knows what this is.

That is the core issue. Other issues:

1\. Unencrypted transactions. Your ISP or NSA may easily monitor which tx you broadcast. This let them link your IP to a tx as well as link your tx across time. Even though HTTP is used thus adding TLS [unauthenticated but at least preventing passive snooping] would be an obvious step. On the other hand... traffic analysis might break this anyway. Tor is needed to really protect but see below.

2\. Wallet leaks information. When connecting, it requests block info from the last block it has. This allows tracking that user over time. The obvious solution of having the wallet always request fixed number of blocks back in history is not implemented. This is simple engineering fixing, not fancy math.

3\. The height leak is very damaging for users attempting to churn. In that case they connect, sync, broadcast, disconnect, repeat. Every time they connect they are indicating approximately where they left off. This means when they broadcast again ... one only need to look at the tx to see if there is a ring member near where the wallet connected. If so, you have linked TX.

4\. The wallet will ask to confirm transactions sometimes... AFTER it has send the ring to the remote node! If you cancel tx then try again, you have sent 2 rings to the remote node but in each ring the real input is the same. Congrats, tx linked or ownership of output now shown.

5\. Wallet and network does not support Tor. Despite using HTTP they do not have proxy support. On Linux they suggest hooking syscall to force proxy [torsocks]. On Windows they scorn users and tell them to use Linux. At the Monero network level only IP addresses are accepted meaning we cannot have Tor-to-Tor.

6\. Tor is downplayed because they are writing-from-scratch a new I2P implementation in C++ named Kovri. Instead of using Tor today they provide no sort of IP hiding while everyone must wait for a new I2P impl. This is bad engineering and means few people can properly submit tx over Tor.

7\. All TX are not the same. There is no solution to joining bad outputs. When you make a multi-in transaction you provide strong linkage if an attacker knows or suspects multiple outputs are yours. Example: you accept donations or are a darknet dealer. Attacker sends many small outputs to you. Attacker will know when you make a move because they will see a multi-input transaction containing one of their known outputs in each ring. This is useful for LE: send small money then know when money is moved. From that point trace forward and see if descendants of that TX end up at known exchange. Now you have a short list of suspects.

8\. A lot of metadata per TX. Each TX can have a payment ID [old style], payment ID [new style] or none. Each tx has a fee, and fee is one of 4 levels [0.25x, 1x, and 2 large x]. But the default is 1x. This encourages smart or big users to change from default to 0.25x to save money. But now their tx look different from common users. Exchanges in particular may do this.

9\. Probably other things I am not thinking off of the top of my head.

In short I think that Monero practical privacy for users that have something to hide [darknet] and may find themselves against a LEA might find themselves in a bad position. Compounding this is Monero's total refusal to warn users and provide self-sabotaging options. A Tor-style warning is absolutely required given the state of things. More paranoid people might think the lack of warning and some of these issues are intentional.

Edit: I still support Monero and think it is the best project. Despite ZCash looking better on paper the team makes me nervous and I avoid it. [Their wallet software is even worse despite them having many millions to fix it] ... I just want Monero stronger as it will help our users overall and that is good for my business.

<comment><USER32> > Main issue: Ringsize is small. Used to be 3 [why??] got bumped to 5 because > 3 is obviously useless. Now getting bumped to 7. The team is taking a very > aggressive approach here. Aggressive approaches with security tend not to > work. They should be conservative and set the ringsize high then back off > later once they have done the research to support a small ringsize.

This is a balancing act. Will the anonymity set actually lower if transaction fees double?

> Despite this they refuse to provide any sort of disclaimer. Contrast to Tor > Project which makes a big deal of telling users they can hurt themselves and > Tor is not some magic. In comparison Monero just claims untraceable & > private with no caveat whatsoever. This is irresponsible & reckless, > damaging to users and not justified. Only when users start thinking and > asking questions are they told oh of course you need to churn but no one > knows what this is.

> The response to all this is 'churn'. This is sending coins to yourself > [looks same as sending to other people] so that you obfuscate the connection > over time. But despite that this is a core feature of Monero they have > provided zero research zero guide on how to do so. They spend money and time > researching fancy new maths and this is great. Yet the core functionality to > answer the question: How anonymous am I, how mixed in am I, this remains > unanswered.

> Despite this they refuse to provide any sort of disclaimer. Contrast to Tor > Project which makes a big deal of telling users they can hurt themselves and > Tor is not some magic. In comparison Monero just claims untraceable & > private with no caveat whatsoever. This is irresponsible & reckless, > damaging to users and not justified. Only when users start thinking and > asking questions are they told oh of course you need to churn but no one > knows what this is.

I think thus is a fair concern, but no one has "refuse[d] to provide any sort of disclaimer." I think it's totally fair to write one up. Add it to a certain portion of the website.

For churning, research has been ongoing. Specifically for EAE scenarios.

> 1\. Unencrypted transactions. Your ISP or NSA may easily monitor which tx > you broadcast. This let them link your IP to a tx as well as link your tx > across time. Even though HTTP is used thus adding TLS [unauthenticated but > at least preventing passive snooping] would be an obvious step. On the other > hand... traffic analysis might break this anyway. Tor is needed to really > protect but see below.

Kovri will include encrypted connections. Monero community members have never claimed to provide IP protection in the current state. If you are currently worried, use a public hotspot somewhere.

> 2\. Wallet leaks information. When connecting, it requests block info from > the last block it has. This allows tracking that user over time. The obvious > solution of having the wallet always request fixed number of blocks back in > history is not implemented. This is simple engineering fixing, not fancy > math.

This is an issue with remote nodes only. This can be mitigated at a cost of efficiency, and even if mitigated, it can still be relatively traceable if enough connections are made. If you are concerned about this risk, use your own node. There will always be privacy loss when using someone else's copy of the blockchain.

> 3\. The height leak is very damaging for users attempting to churn. In that > case they connect, sync, broadcast, disconnect, repeat. Every time they > connect they are indicating approximately where they left off. This means > when they broadcast again ... one only need to look at the tx to see if > there is a ring member near where the wallet connected. If so, you have > linked TX.

I argue that churning is absolutely outside the scope of users who are using remote nodes. It's extremely unlikely an advanced user who cares about their privacy will make a fundamental mistake in trusting someone else's node. This is outside the scope of protections. Just run your own node if your threat model even considers churning.

> 4\. The wallet will ask to confirm transactions sometimes... AFTER it has > send the ring to the remote node! If you cancel tx then try again, you have > sent 2 rings to the remote node but in each ring the real input is the same. > Congrats, tx linked or ownership of output now shown.

This was disclosed in HackerOne and has been patched.

> 5\. Wallet and network does not support Tor. Despite using HTTP they do not > have proxy support. On Linux they suggest hooking syscall to force proxy > [torsocks]. On Windows they scorn users and tell them to use Linux. At the > Monero network level only IP addresses are accepted meaning we cannot have > Tor-to-Tor.

Little effort has gone into this since the support is being designed for I2P.

> 6\. Tor is downplayed because they are writing-from-scratch a new I2P > implementation in C++ named Kovri. Instead of using Tor today they provide > no sort of IP hiding while everyone must wait for a new I2P impl. This is > bad engineering and means few people can properly submit tx over Tor.

There are other considerations when submitting transactions over Tor. I'm not an expert here, but fluffypony has been critical of this approach in the past.

> 7\. All TX are not the same. There is no solution to joining bad outputs. > When you make a multi-in transaction you provide strong linkage if an > attacker knows or suspects multiple outputs are yours. Example: you accept > donations or are a darknet dealer. Attacker sends many small outputs to you. > Attacker will know when you make a move because they will see a multi-input > transaction containing one of their known outputs in each ring. This is > useful for LE: send small money then know when money is moved. From that > point trace forward and see if descendants of that TX end up at known > exchange. Now you have a short list of suspects.

Each output is used in several transactions. While it does not completely mitigate the risk you describe, it means there is at least some plausible deniability in practice. If you are in a situation with a significant number of outputs, you definitely should not simply send a transaction with these to an exchange or similar.

> 8\. A lot of metadata per TX. Each TX can have a payment ID [old style], > payment ID [new style] or none. Each tx has a fee, and fee is one of 4 > levels [0.25x, 1x, and 2 large x]. But the default is 1x. This encourages > smart or big users to change from default to 0.25x to save money. But now > their tx look different from common users. Exchanges in particular may do > this.

There will always be some metadata, but based on how the system works, there will always need to have the fee. The multiplier is set to be more automatic in the latest version. The payment ID metadata has been improved to be encrypted, and to encourage use for all transactions with integrated addresses. Metadata for these two items is the least of our concerns since there is still a pretty large entropy set for normal situations, but of course there could be improvements.

> 9\. Probably other things I am not thinking off of the top of my head.

Me too :) Key image reuse attacks seemed to come out of nowhere, and we needed to respond to them.

> In short I think that Monero practical privacy for users that have something > to hide [darknet] and may find themselves against a LEA might find > themselves in a bad position. Compounding this is Monero's total refusal to > warn users and provide self-sabotaging options. A Tor-style warning is > absolutely required given the state of things. More paranoid people might > think the lack of warning and some of these issues are intentional.

I disagree with your tone here. Here I am, a community member, agreeing with many of your criticisms. The idea of a better warning guide has been discussed for quite some time, and I believe it has been relatively strongly received. If you were to start a project on Taiga to get this started I'm sure many people would respect you.

The best summary I can say is this: Monero is a tool that can provide significant privacy under a variety of use-cases. If your use-case is hiding your wallet balance and transactions from merchants, ad agencies, and most attackers, you can use Monero with little to no significant consideration for your privacy. If you are worried about colluding KYC exchanges, governments, and motivated attempts to target you specifically by powerful attackers, then the use-case for Monero needs to be better-defined. Monero will preserve privacy under some situations better than others. Given that it is relatively hard to understand, Monero will need to use a mix of education and default/mandatory functionality to encourage the correct behavior.

<comment><USER9> I will look up the complaints about Tor.

I apologize for my tone and do not mean to speak ill of the Monero team. I still choose Monero and feel it has the best benefits overall.

<comment><USER32> Thanks for being informed about some of the limitations! I highly appreciate having these conversations, and I look forward to working with you to improve Monero.

</comment></comment></comment></comment><comment><USER33> I've seen countless writings against monero yet the market still price it worthy [https://www.coingecko.com/en/price_charts/monero/usd](https://www.coingecko.com/en/price_charts/monero/usd) Can compare this to iota revelation?

</comment><comment><USER34> Side-channels are the gap between theory and reality; a gulf filled with information theory and tears.

As they point out, the public, consensual mutation-resistance of blockchain makes it rather hard to walk back mistakes.

</comment><comment><USER35> I only ever hear of Monero in a negative light. Has anything positive come from it?

<comment><USER36> It can't be that both affirmations have negative connotation:

"Monero can be 100% anonymous, so it's the preferred coin of criminals"

"Monero is not 100% anonymous, so big time criminals can't use it."

<comment><USER6> Anonymity is not something you either have or don't have. It's always relative to an anonymity set. Mathematically, a ring signature provides a guarantee of anonymity within the ring.

</comment></comment></comment><comment><USER37> The SAFE project would have totally private coins. If they ever launch, I mean :)

</comment><comment><USER38> Next frontier: XSpectreCoin

[https://spectreproject.io](https://spectreproject.io)

<comment><USER38> Down votes but no explanation. XSpec's level of untraceability goes quite a bit beyond Monero's.

<comment><USER39> > _Down votes but no explanation_

Consider the obverse: a promotional link with no explanation. A short blurb about why XSpec is better than Monero might help your comment stand stronger on its own.

<comment><USER10> The difference is that Spectrecoin has no paper and no explanation how "stealth staking" works.</comment></comment></comment></comment>


Tour of Rust - <AUTHOR> https://tourofrust.com/ <comment><USER2> Maybe a bit offtopic, but two minor UX issues hit me the first 15 seconds of trying to open this; sharing in case someone who maintains this sees and hears similar minor feedback --

First when I saw the splash screen, and saw it say "Press to Continue", I well first was confused for a split second on "press what?", then assumed it meant "click", so I clicked my mouse, then when that didn't work assumed it meant "a key" so I hit a random key, then when that didn't work, summoned my conscious brain and figured "well I guess it means click specifically on top of this link text".

And then once on the next page, glancing at a long list of languages without really reading the text I said "ok I speak English, guess I should click on that", only to see the same exact page refresh. "Maybe it's broken?", so I clicked again. When it didn't work the second time, again, conscious brain again -- "OK, guess there's a next link somewhere here", and scrolled to the bottom.

<comment><USER3> I was caught out by the 2nd one too, I hit "English" expecting to be taken to the English version of the start of the Tour.

</comment></comment><comment><USER4> I'm not sure if I'm the only one that this happens to, but every couple of months I end up re-learning Rust, and because I don't really have any use of it in my day to day job (Python and Go, some C++) I end up un-learning it, and then the cycle continues.

What kind of projects are a best fit for Rust, for those who are experienced with it? Any recommendations for projects to make Rust stick?

Thanks!

<comment><USER5> > I don't really have any use of it in my day to day job (Python and Go, some > C++)

Find one of the most simple utility (probably a CLI) you have and rewrite it.

I have a lot, and find useful to turn some python stuff so is easier to ship (surely Go work here...)

<comment><USER6> Is it really that easy to write a dirty script with rust? It doesn't seem like something that's very forgiving nor allows rapidly testing concepts or prototyping.

Do you personally start writing Rust from the get-go or do you first write something in some scripting language and then transform it to rust once the basics work?

<comment><USER5> > Is it really that easy to write a dirty script with rust?

Eventually.

I struggle, a lot, for the first 3 months of Rust. Not each minute doing rust. I code in 2-3 other langs, but the slow was pretty obvious.

I think have worked in so many other langs (+12) actually hurt me most. I try to start with rust like all the rest: Go ahead coding, figure stuff along.

I stop doing like a idiot when I start looking at it as my FIRST lang ever: read a book, be slowly, PAY attention to what are the concepts "owned", "move", etc..

Also:

I try to learn with building a relational lang, and develop the routine to build very small rust projects of a single file. I have done dozens now, and I start to click to me, and can do a lot of stuff far faster and near python- speed (when simple and normal).

</comment></comment></comment></comment><comment><USER7> This is good, but the string handling stuff should be earlier in the tour, because Rust's strings are idiosyncratic (whole blog posts have been written about str vs. String, an issue that doesn't appear in most other languages). It'd be a nit, but handling strings is one of the most important things you usually need to know to be productive.

I'd love a version of this for people who know Rust that was just Rust idioms, similarly explained. I hang out in Slack channel with a bunch of Rust programmers (because I'm bumbling my way around in Rust as well) and it feels like there's a _lot_ of communally understood idioms that aren't super apparent from the Rust Book.

<comment><USER8> We learned the hard way with the Rust book that this is important: one of the biggest structural changes we made between the first and second editions was re-orienting the entire book around "how can we get to Strings quickly", and for exactly the reasons you state.

And yeah, the intermediate area is where things are worst now, for sure. It's sorely needed.

<comment><AUTHOR> I think the big difference between Tour of Rust and the Book is my example sizes were meant to be as small as possible to demonstrate one concept at a time. Most of the concepts require no strings at all to explain. Particularly through the procedural programming chapters.

<comment><USER8> Sure. The issue is, it's something that people run into very early when they try to actually write code. They won't go through the whole Tour before trying to do so. They certainly don't with the book :)

Anyway the author should do whatever they want. I'm glad folks other than me are writing docs! I haven't managed to actually go through the Tour yet myself, this is just a riff on the observation made in my parent's comment.

</comment></comment></comment></comment><comment><USER9> Every time I try to learn more about Rust, I keep hitting a wall around OOP. I know Rust takes the stance that composition is better then inheritance, but I've never found the examples to be very convincing. How do rust developers deal with complex structs that contain lots of properties and features. For instance, if I need to create "CustomButton" that means I have to implement all the Traits from Button, which maybe requires Traits from LayoutView, which requires Traits from View, etc.... Additionally I need to maintain duplicate properties of those objects in my Custom Button rather then inheriting from a Button struct. It sounds like a headache to maintain.

<comment><USER10> You can do almost everything with a combination of traits (for interface inheritance), simple composition and the Deref trait (to auto-forward unimplemented functions to the contained class). The one feature you're missing compared to actual OOP inheritance is open recursion, which is a big footgun more than anything (see: the "fragile base class" problem).

The Rust docs include an in-depth explanation of how Rust relates to traditional OOP: [https://doc.rust- lang.org/book/ch17-00-oop.html](https://doc.rust- lang.org/book/ch17-00-oop.html)

</comment></comment><comment><USER11> rust doesn't look like it has a steep learning curve. not to me at least. the discouraging thing is the "weird" syntax. i feel like rust is the result of diverging ways of looking at things.

not saying it's a bad. just wish some effort were put into making a consistent syntax.

seems weird to me that whoever decided on the function keyword "fn" would write the "Option" type. they would have written "Opt". but no, it's "Option".

consistency is very underrated. and these things just look odd to me but the rust community think it's okay, so, oh well...

<comment><USER12> The general wisdom of language/library design is that abbreviations should be used only for very common things, and only when those abbreviations are unambiguous in context. Prehistoric Rust had a rule that all keywords could be no longer than five characters (in defiance of Javascript's `function`), but forums (including HN) endlessly complained about `ret`, hence today it's `return`. :P (I admit that I wanted to Rust to change its `fn` to `func` once Swift showed its hand, but such is life.)

Meanwhile, in 2020 `Option` might be on its way to becoming a widely-accepted concept in language design, but back in 2011 it was still a radical idea that Rust was trying to smuggle over the border from functional languages, against the will of people used to languages with pervasive nullity. The language that eventually supplants Rust someday might call it `Opt` (in the same way that Rust turned C++'s `vector` into `Vec`), but back then `Option` needed all the lubrication it could get without having to get bogged down in the abbreviation bikeshedding.

<comment><USER10> The thing is that 'return' is not very common either, because Rust has shorthand for returning at the end of a function :-P

I think the standard library ought to use slightly longer names since it's far less strictly bounded than the set of language keywords, so I'm fine with 'Option'. 'Vec' is a bit awkward from that POV, but then again 'Vector' would be a lot worse. 'Box' is also awkward in the same way but thinking about it, it's not easy to convey the notion "this value is behind a pointer" so you might as well use a conventional name and get it over with.

<comment><USER13> Why not call it Pointer or Point?

<comment><USER14> A Box is _not_ a pointer. It is an object with regular one-owner, no copies semantics. Semantically, it just breaks the object out so that it isn't "internal" to whatever contains it (useful for keeping individual objects small or working around the requirement that a type have a known, finite size).

A pointer and a heap allocation are the obvious choice for implementing this, but the semantics are notably different than just being a pointer. Rust also does have pointer types which represent true pointers.

<comment><USER15> AFAICT, Box has exactly the same semantics as C++'s unique_ptr.

<comment><USER16> Where it _can_ have the same semantics, yes. But if you look at the details, not exactly. For example Box is not nullable, but a not-nullable C++ equivalent is hard to do given the rest of the language.

<comment><USER15> Good point on the nullability; yes, that is indeed different from std::unique_ptr.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER17> Unfortunately for me, they don't mention macros in this tour of rust. Even after reading the official book, I'm still not comfortable with macro and macro syntax. Do you have any recommendations?

<comment><USER12> Note that I wouldn't expect a beginner to Rust to care about writing macros at all. Macros are something that you might introduce to a project eventually in order to abstract over some project-specific boilerplate (and only as a last resort; there are usually better abstractions to reach for first).

I say this because someone coming from a functional language might be betrayed by their instincts here: it is relatively rare for Rust users to write macros themselves, and macro-heavy Rust code would generally be regarded as peculiar/unidiomatic.

<comment><USER18> It's true that writing macros is out of scope for an intro guide, but the first "hello world" example uses the println! macro so you have to understand how to use them right from the start. They're all over the standard library. I struggled with explaining this when writing my own guide to Rust - do you dive straight into explaining macro syntax in the first chapter, or just explain how this one macro works and move on? Or don't explain it at all, which is the (sensible) choice that this tour takes.

Unfortunately the language documentation isn't helpful either, looking at the docs for println! [0] doesn't explain the arguments that it takes (other than referring to format!, which is another macro [1]...) or what the return value of the macro is.

[0] [https://doc.rust-lang.org/std/macro.println.html](https://doc.rust- lang.org/std/macro.println.html) [1] [https://doc.rust- lang.org/std/macro.format.html](https://doc.rust- lang.org/std/macro.format.html)

<comment><USER19> > the first "hello world" example uses the println! macro so you have to > understand how to use them right from the start

You don't "have to" understand the `println!` implementation in order to use it. It certainly helps like it does for any other API, but it can be treated as a blackbox, and still be able to use it.

<comment><USER20> This is the essence of teaching: planning out what to gloss over and explain later.

I see many tech:nerd people explain this bottom-up instead of bottom-down because they can't imagine skipping details for later. The reality is that students are intrigued by "I'll explain what that means later" and it builds interest.

I explain how our website works by first telling a big lie: your computer requests a webpage and we have one big computer that replied with the answer. I then explain that I just lied. I then break it down: a web page requires many elements. Each requested individually. I then explain we don't have one big computer but a cluster behind a load balancer. I then explain the many benefits of a load balancer. Then I explain that the web cluster depends on databases and other services.

All-in-all I expose 5-6 "lies" as I break down each component.

I've gotten positive feedback from both non-developers, entry-level developers, and expert developers.

I've also seen people give a bottom up description and everyone was confused at the end.

Why do top-down descriptions work better even though they initially gloss over (lie) To the audience?

Because the high level description gives The audience a mental roadmap to follow. Then we back up and walk through that roadmap in more detail. Then we walk through again in even more detail.

The entire time the audience understands where we are going and fits each bit of new information into their mental model, expanding it as we go.

Here's how it feels to be explained to in a bottom-up manner: imagine I spent an hour with you listing out left and right turns. At the end of the hour I tell you "and that's how You drive from NYC fo San Francisco". JFC, Tom, couldn't you have started with that!?!?

Don't be that guy.

An explanation isn't a murder-mystery novel with a surprise ending. Start with "these butler did it" and work backwards from there.

At Bell Labs we had a saying about presentations: "first show us your conclusion slide. If we disagree, rewind to the first slide and show us your talk. You have our interest. If we agree, stop. We can all go to lunch early."

<comment><USER21> I second this. I see too many people start with a bottom up explanation , which causes people to sour on the topic. It's a mountain of information up front.

Some topics, this can't be helped with as much, but in most cases, starting high level and progressively peeling back layers is a lot more effective.

That's how most education is presented as well. It's usually only domain experts who DON'T teach that think every little detail is valuable up front.

</comment></comment></comment></comment></comment></comment><comment><USER22> As a skeptic of Rust I really appreciate this. I was very pleased to find the ASM option in the drop-down menu specifically. Coming from C/C++ I've found it difficult to understand how and why Rust generates the code that it does. Rust appears slightly less direct in its description of programs than C++ as it's shed the hardware-driven abstraction of memory and physical layout. My comfort level with seriously considering Rust for a next project is proportional to my understanding of what it's doing under the hood.

Thanks! Looks great.

<comment><USER8> The Compiler Explorer supports Rust as well, and is very good at this kind of thing. You may want to check it out if you don't already use it for C++ stuff.

</comment></comment><comment><USER23> The playground is rather slow, is it possible to run this locally much like how go's tour can?

<comment><USER24> From what I've heared, Go compiles much faster than Rust. But I'm only experienced in Go...

[Edit] I mean you could just install Rust, copy the samples and run them locally?

<comment><USER25> Yes, I've noticed the Rust compiler does fancy stuff like check for similarly named constants, check constants have uppercase names, do static analysis to check that I've kept my immutable variables immutable, check that a semicolon is always at the end, and so on. I've never found those necessary in Go...

<comment><USER26> Last I heard, the biggest source of compile time in rustc is emitting absolutely enormous amounts of LLVM IR and leaning on aggressive low-level LLVM optimisation passes to clean things up. There are efforts to make most of these optimisations earlier that have been landing in recent releases, but I'm not sure what the overall state of it is.

<comment><USER27> I they have started doing work on that? I can't recall what it was exactly, but there was one constant or number (I'm so good at being specific) related one that did the optimization on the rust side instead of on LLVM's side.

<comment><USER8> [https://blog.rust-lang.org/inside-rust/2019/12/02/const- prop...](https://blog.rust-lang.org/inside-rust/2019/12/02/const-prop-on-by- default.html)

</comment></comment></comment></comment></comment></comment><comment><USER28> I think this tour of Scala should interest rustaceans as many discover in rust their interest for advanced type system/functional features. And Scala in this aspect represent what rust should be in the next decade! [http://dcapwell.github.io/scala- tour/Partial%20Function.html](http://dcapwell.github.io/scala- tour/Partial%20Function.html)

<comment><USER29> > When building apis that are given PartialFunctions, its your responsibility > to make sure the given input is proper for the function.

That's not exactly the first 'feature' I'd want Rust to get.

</comment></comment><comment><USER30> > With so much difficulty in working with Unicode, Rust offers a way to > retrieve a sequence of utf-8 bytes as a vector of characters of type char.

> A char is always 4 bytes long (allowing for efficient lookup of individual > characters).

Please fix this! A 4-byte char is NOT a character but a _codepoint_.

</comment><comment><USER31> Sorry, off-topic, but something interesting I just went through: in the first page, where it offers you multiple languages to choose from, one of the options is "Interlingue". I've never seen it before, I didn't realize it was a conlang. Anyway, I used my google-translate addon to select a couple sentences, while having that lang selected... and it gave a comprehensible translation... and recognized original lang as Spanish. I selected the next sentence, it gave a comprehensible English translation, but recognized original lang as Romanian! Another sentence: good output, but French! Another sentence: again, perfectly good translation offered, but input lang recognized as Corsican! Truly a bizarre experience.

</comment><comment><USER32> Pushing this language and Go as required, responsible, NG languages is another one of the foibles of the cloud/web and it's owners. For those of us in HPC and scientific compute where is the practical reason to switch from C/Python and the unix toolset?

<comment><USER33> I'm in the web field generally. Those I've spoken to outside of that field find Rust a much faster way to develop safe and stable programs that would have otherwise been written in C. Feel free to take this with a grin of salt. I suspect the C devs who don't like Rust haven't taken the time to discuss it with me.

</comment></comment><comment><USER34> Is the naming inspired by Stroustrup's "A Tour of C++"? [0]

[0] [https://www.amazon.com/Tour-2nd-Depth-Bjarne- Stroustrup/dp/0...](https://www.amazon.com/Tour-2nd-Depth-Bjarne- Stroustrup/dp/0134997832)

<comment><USER35> This looks very much like the Go tour: [https://tour.golang.org/welcome/1](https://tour.golang.org/welcome/1)

<comment><USER36> Thanks for the link. It was great to read them side by side. I had my suspicions, but I think I'm more of a Go person than a Rust person.

</comment></comment></comment><comment><USER37> Off topic. Asking seriously, will there be any point learning some language other than rust in coming days? Will rust be ubiquitous in future?

<comment><USER38> It's important to understand that hackernews, reddit or stackoverflow are very small parts of the software universe. At my workplace less then 10% of the devs are hanging around at hackernews or reddit. Some don't even visit stackoverflow but just read the Java docs!

Rust is extremly popular here at hackernews and at reddit. It's a brilliant language. I learned it and actually wanted to use it for some services at work, but the team chose Go.

The impression of the spread of Rust one might get following hackenews or reddit is far off. In the industry Rust is not even at 0.1%. Probably less. The amount of Java, C and C++ projects is immense. That's at least what I can tell from my almost 20 years of experience as dev.

Rust is 10 years old. It's not new. There must be reasons why it's not already ubiquitous. And it's not the lack of language features or the lack of promotion :-).

The reason is simple: The choice of the programming language itself is not that important. How else can the world be full of extremly successful projects written in PHP, Python, Ruby, Java, C#, C, C++, Go, JS, ...

I don't like to write code without algebraic types and pattern matching. I don't want to check for null. But with Java or Go I have to and to be honest: It doesn't matter. A good development process is essential for successful projects. Language and tools ergonomics, matureness and stability come second.

That's why so many large projects are still on Java 8. They get the job done. The same can be said from C++ and C. If C++ was so harmful, why did Mozilla not port all of Firefox to Rust?

Rust could be a greater success in the industry. They just have to look at Go. Go gets a lot right: Standard lib and stability. Generics don't really matter if you want to build a successful product. I want it but I don't need it. A large and stable standard lib does matter. The xml package in Go's standard lib is embarrassing slow. But you can rely on it.

Rust needs a large company as patreon. It needs a more comprehensive standard lib. It needs one async runtime in the standard lib and a http server and client, crypto, etc.

<comment><USER39> > Rust is 10 years old.

Rust didn't have any pick up in adoption (understandably) until 1.0 in May 2015, as a consequence of breakneck speed changes before then as the developers understandably wanted freedom to break things until then. Also, 1.0 wasn't a "feature complete" release, it was a "we promise not to break your current code" release. It was an MVP. I would say it took a few releases before it was useful enough without having to rely on nightly features. All this to say is that saying that it is 10 years old, when code from 6 years ago would be completely alien and not compilable today, is misleading by omission.

> It needs a more comprehensive standard lib.

Reasonable people can disagree. There's a difference between having a fat stdlib that has the same cadence as the compiler, and having a "blessed" crate ecosystem that can evolve on its own. Doing it that way can let people update either their compiler or their dependencies independently of each other (modulo minimum version bumps on libraries) and opens the door to more aggressive deprecation schedules that the stdlib can never consider.

Your points about the actual popularity of the language are very true: Rust is niche now and will likely continue to be so for a while, but I don't think it will _remain_ niche.

<comment><USER40> > deprecation schedules that the stdlib can never consider.

This is utter fantasy.

You can have a standard library that doesn't get deprecated often, or no "standard" libraries at all.

Oh, I mean, sure, you can call it a "blessed crate ecosystem", but that's just a label. A name. You can call it Bob's Best Bits, or the Stevens Standard Set, or whatever you want, but _inevitably_ it'll be either:

a) Difficult to change because so many other libraries depend on it, _because_ it is the established standard.

b) Easy to change because it's _not_ the established standard and hence nobody cares if it breaks the handful of things that depend on it.

Everyone wants option (c), where an established standard is magically easy to change. But there's no such thing. Putting libraries outside the "std" namespace doesn't help in any way.

<comment><USER39> In Rust you can have multiple versions of the same crate in your project. This let's you update you your dependencies almost whenever you want _, even if their transitive dependencies require different versions of the same crate. You can 't have multiple versions of the stdlib (the way that things are set up today).

_ Some crates re-export typed from their dependencies, and to use those you have to match in the right crate version. This is an anti-pattern, but it happens.

</comment></comment></comment></comment></comment><comment><USER41> I think much of the official "rust-by-example" would benefit from using the rust playground instead of the printed examples.

<comment><USER42> All code blocks in rust by examples can be edited and have a play button.

<comment><USER43> And most of that cannot be run on playground because of incomplete source code, missing dependency or wrong configuration.

<comment><USER8> That has to do with the contents, not the playground.

Also, many examples have hidden context that if you open the example in the playground, you'll see and will make compile.

</comment></comment></comment></comment><comment><USER44> This site can actually be used on mobile, cool!

</comment><comment><USER45> > _Execution operation failed: Compiler execution took longer than 12000 ms_

Are my privacy add-ons too strict or is the server overloaded at the moment?

<comment><USER46> Probably getting the good old HN hug right now. Might want to try later.

</comment></comment><comment><USER47> Did anyone else notice Interlingue in the language options? Maybe we could get a Tour of Rust written in Esperanto :)

<comment><AUTHOR> Tour of Rust english author here, David [https://github.com/Dhghomon/](https://github.com/Dhghomon/) our Interlingue writer was one of our most passionate translators. We'd be happy to have Esperanto.

</comment></comment><comment><USER48> Why does the compile debug information get printed to the standard error area?

</comment><comment><USER49> Tour de Rust? No? OK, I'll show myself out...

</comment><comment><USER50> Too bad mr crabs isn't the guide.

<comment><USER51> He asked for too much money</comment></comment>


Just polished off JavaScript array compression to string algo, would love feedback :) - <AUTHOR> https://github.com/sirrodgepodge/arrayCompress <comment><USER2> I get weird results:

      input: [12,85,75,57,86,45,31,76,57,60,28,87,54,28,43,53,53,69,0,39]

      output: "32|60=4,12=4,75=NaN,57=NaN,86=NaN,45=NaN,31=NaN,76=NaN,85=NaN,28=NaN,87=NaN,54=NaN,43=NaN,53=NaN,69=NaN,0=NaN,39=NaN|%undefinedundefinedundefinedundefinedundefinedundefinedundefinedundefined!undefinedundefinedundefinedundefinedundefinedundefinedundefinedundefinedundefined"

edit: this only seems to happen when there are more than 10 unique values in the input.</comment>


YouWeb, Billion-Dollar Incubator? - <AUTHOR> http://blogs.forbes.com/oliverchiang/2010/11/18/exclusive-youweb-billion-dollar-incubator/ <comment><USER2> "He founded and led two companies, Webvan Group and Business Signatures, which were both sold."

Bringing up Webvan and only saying that it sold is like bringing up Ted Kaczynski and only saying that he went to Harvard.

This is written like the author is trying to play up YouWeb, but I don't know why he would be motivated to do that.

<comment><USER3> I don't know Peter, but thats a horrible comparison. While the article may be biased, people here on the Y Combinator board should show some respect. Just because he has a different model doesn't make it a threat to Y Combinator.

<comment><USER4> The OP was talking about omission, not Peter directly. Webvan was a _spectacular_ , legendary failure that destroyed almost a billion dollars of investor wealth, mainly through incompetently aping Amazon's business model without fully understanding it. Not even bothering to _hint_ at that when talking about someone who led the company is a huge omission bordering on a lie.

Wikipedia: "Webvan tried to embrace a total customer satisfaction model involving a 30 minute window delivery without considering that many working customers would like their groceries delivered at home at night."

</comment></comment></comment><comment><USER5> "But basically, if you go by YouWeb's comparison estimates, Relan has turned $700,000 into around $1 billion in value in just three years, and created close to 200 jobs in the process. To be sure, the $1 billion isn't all YouWeb's — Relan didn't disclose the amount of equity the incubator has in each of its startups."

But basically, he hasn't turned "$700,000 into around $1 billion".

</comment><comment><USER6> _"Whereas an incubator like Y Combinator looks for applicants who already have a strong startup idea in mind, YouWeb prefers those who don't. "I'm not looking for the next Facebook, Microsoft or Google," he says. Instead, Relan is decidedly people-focused. He wants "brilliant technical developers" who are not necessarily passionate about one concept or idea, but about the bigger industry in general. YouWeb then works with young, unproven entrepreneurs to target markets that are "interesting" and create the idea and the company."_

I thought YC stresses that it's decisions aren't idea-driven?

</comment><comment><USER7> i notice that their $1 billion dollar valuation is based entirely on things in the game sector.

and $100 million dollar valuation for an iPad app seems crazy...ditto for the $100 million valuation for the sibblingz...I dunno their numbers, but their alexa rank is close to 2 million, which is like 5 visits a day.

same for the crowdstar and openfeint...sure those are successful, but not $400 million valuation successful.

this article sounds like a puff piece to get people interested in youweb.

</comment><comment><USER8> They estimate CrowdStar is worth around $400 to $500 million and OpenFeint around $400 million (using Playfish's and ngmoco's acquistions, each for $400M, as comparables).

Are there any YC companies that have similar valuation estimates?</comment>


Sketch2UI: Upload Your Wireframes, Download a Complete UI Design - <AUTHOR> <comment><USER2> I think you might have forgotten to include a link -- wrong submission type?

<comment><AUTHOR> I did. I'll trip load thanks</comment></comment>


High-Speed Traders Are Taking Over Bitcoin - <AUTHOR> https://www.bloomberg.com/news/articles/2017-01-16/high-speed-traders-are-taking-over-bitcoin-as-easy-money-beckons <comment><USER2> I am one of those traders, and I'll happily share my observations.

(Before you ask -- no, there are no any good books and tutorials on HFT trading. You need to grokk it on your own, or receive the knowledge by direct transmission if you are an employee of HFT firm. However, there is "The Problem of HFT" by Haim Bodek, which contains some nice essays from the insider perspective and even some basic examples, though too specific within US equity markets).

1) Bitcoin exchanges are the perfect playground to learn the basics of HFT. All trading data is free and public, most traders are not sophisticated enough, you can start as small as you like (being small is an advantage in HFT), lots of low-hanging fruit are to be picked. HFT proliferation and arms race is barely started on most exchanges.

2) The algorithms themselves are simpler than most people think. HFT trading is mostly unrelated to arbitrage (inter-exchange arbitrage is much slower, and it is a different discipline).

3) The engineering issues are _harder_ than most people think. Even more so with inter-exchange arbitrage.

4) Bitcoin markets are small, and HFT potential capacity is quite limited. Most algorithms I came up with work perfectly well on small scale (and running successfully in production), but I am not making any riches out of it yet.

<comment><USER3> I wrote a bot but could never make money due to the transaction fees. I wanted to make 15-20 trades per day. Instead, had to limit it to 3 or 4, meaning a lot more burden on each trade to be right.

The funnest part of writing a bot is using all the historical data to observe how the bot would have done during that period. I ended up checking thousands of permutations of parameters by brute force to determine the best ones, but in the end transaction fees killed me. I didn't have the confidence to do it at a large enough scale to make money I guess.

<comment><USER4> Same experience here, several years ago. I'd love to know how professionals manage to avoid problems with transaction fees. I guess it is just taken into account during prediction, but it does seem to limit the number of tentative transactions you can make, even if you cancel them.

<comment><USER5> It's actually fairly simple: basically change the metric of a trade worth taking from "one with expected profit > 0" to "one with expected profit > expected fee". It does limit the number of potential profitable trades, and hence fees are sometimes used as a way for exchanges to reduce trading volume. Or to divert it; some Chinese (non-bitcoin) exchanges for instance charge greater fees for intraday trading, to discourage speculation.

</comment></comment></comment></comment><comment><USER6> Others here are missing the point. Until platforms like Bitfinex allowed margin trading, arbitrage was impossible because the exchanges are extremely risk averse. In order to arbitrage you would have had to buy on one exchange, then wait for 3 confirmations (~40 minutes?) before the receiving exchange would take the risk that the bitcoin was actually transferred. Now with short selling it looks like you can instantly borrow a bitcoin on the exchange that's inflated, then sell it immediately. You don't need to transfer between exchanges - all done completely on internal paper transfers inside the exchange.

<comment><USER7> If you can immediately buy and sell between exchanges it should quickly level the prices. Something like that is easy to automate, so any slight margin that appears will be almost instantly leveled.

<comment><USER8> The buying and selling is fast and easy to automate.

The difficult part is in transferring non-bitcoin currency to and from the exchanges.

If you for example buy bitcoin in the US and sell in China, then you end up with a surplus of CNY on a Chinese exchange's account. Getting this converted and transferred back to the US will incur exchange and transfer fees. The transfers might also take weeks - which will limit you to cycling small amounts of money slowly, or risking a lot of money at once if the exchange "has banking issues".

In the end, even a 5% or 10% price difference might not be worth running the arbitrage cycle on difficult to deal with exchanges in strange countries.

<comment><USER9> the article is about doing this on a dozen chinese exchanges. no currency conversion necessary when it is all CNY

</comment></comment></comment></comment><comment><USER10> > while the increasing dominance of sophisticated traders begs the question of > how long the juiciest arbitrage opportunities will last.

 _Raises_ the question, not begs it. Begging the question would be to say, 'Bitcoin always generates profit, therefor it will always generate a profit.' Begging the question is assuming the consequent of the argument; raising a question is, well … raising one.

<comment><USER11> I have, in nearly 35 years of using English, come across exactly 1 "correct" usage of "begs the question" outside of comments like yours correcting people.

In other words: You're fighting a lost battle. I suspect if you put the two common uses of it to a representative sample of people, that the majority won't even know the original usage at this point.

<comment><USER12> The problem is that "begs the question" is a poor textual representation for what it means. "Assumes the conclusion" is a better affordance.

</comment></comment></comment><comment><USER13> "Taking over" is sensationalism.

High-speed trader's are taking advantage of arbitrage on zero fee digital currency exchanges.

<comment><USER14> Yep, plus arbitrage isn't "taking over", no more than "retail is taking over the manufacturing". It's just a characteristic of healthy stock exchanges.

Is there a cap on the growth of the blockchain? Since every transaction is saved and every actor has all of the blockchain (Am I correct?), if HFT made it double it size every week, will it reach an unmanageable size after a few terabytes?

<comment><USER15> Trading is done off-blockchain on exchanges.

</comment></comment></comment><comment><USER16> Here's an economics question that I used to think about when I was trading bitcoin:

Does volatility of an asset itself create value? It seems like the more volatile the price is, the more opportunities there are to make big profits trading the swings using a 'reversion to mean' strategy. Which would mean more people trading it, which would mean that over time, the 'mean' price would keep trending upwards, until that volatility reduced to the point where the strategy was no longer profitable.

Does that make any sense at all? I'm sure there's a broken link in that chain of logic somewhere.

<comment><USER17> Volatility usually is considered bad. Why would you want to invest in something whose day to day price can change 20%? For day-traders and HFT volatility is good, since they can (as you have said) ride the swings.

There's the value of a bitcoin, and the value that bitcoin brings to the market. And those are two different things.

The value bitcoin brings is anonymous currency transactions and anonymous speculation.

Now ask yourself what is the value of one bitcoin? It's not based on a physical scarce resource like coal or oil. It's not based upon an actual currency either (either gold backed or fiat). In fact the only value people have in it is that other people invest in it. So speculation has created value.

Volatility in this case is just a side effect of speculation.

<comment><USER5> In some cases volatility is categorically good, e.g. if you have a put option that's in the money. Volatility increases the chance of it either going far into the money (so you profit) or far out of the money (in which case you can just choose not to exercise the option): it increases potential reward without increasing potential loss (you'll never lose more than the premium you paid for the option).

</comment></comment></comment><comment><USER18> This was evident on Coinbase a couple of years ago. You could sit there and watch the bids and asks move up and down in a regular fashion on a Saturday night. Probably super amateur HFT but HFT nonetheless.

</comment><comment><USER19> There's nothing in this article that wasn't true in 2012...

<comment><USER20> >But for Zhou, a 35-year-old

That wasn't true in 2012. :-)

<comment><USER21> Kapow!

</comment></comment></comment><comment><USER22> Which exchange doesn't take transaction fees? I checked BitMEX, GDAX and OKCoin - all have takers fees. When I post an order that gets filled immediately, I have to pay takers fee. Is my understanding correct that if I post a limit order that incidentally is filled immediately, I pay the takers fee ? Which exchanges only take commission on paying funds in/out ?

Does maker/taker distinction ignore the side of the transaction (ie. does it matter whether an order is a bid or an ask to be considered a maker )?

<comment><USER23> Taker fees are assessed on the party that removes liquidity from a market. If one places a market order, you are removing liquidity either on the bid or ask side and are assessed a fee. If you place a limit order, you are providing liquidity and are not assessed a taker fee.

</comment></comment><comment><USER24> I heard somewhere that increasing HFT volume actually decreases overall volatility as the arbitrage windows get smaller & smaller. is this the case? is bitcoin any different in this regard?

</comment><comment><USER25> High-speed trading on a "market" that allows ~10 transactions/second max?

<comment><USER26> Just like high frequency trading in the gold market doesn't require physically handing bars of gold for physical dollar bills at high speed, neither does high frequency trading bitcoin require any high speed blockchain transactions.

<comment><USER27> Great analogy.

</comment></comment></comment><comment><USER28> Is it possible to do HFT with bitcoin, given it has a 7 transactions-per- second maximum rate?

<comment><USER29> They aren't trading possession on the blockchain in most cases. Generally, the BTC is in an exchange's wallet and the exchange maintains the accounts of the traders until the traders withdraw their assets.

edit: Some cross exchange trades (i.e. buy BTC on one exchange and sell on another) would still require a move across the chain, but it all really depends on what the exact mechanics of the trade are.

</comment></comment><comment><USER30> what exchanges are people using for this?

</comment><comment><USER31> There are no HFT exchanges in the bitcoin world. All these trades are done over the internet using HTTP. Hardly HFT.

<comment><USER2> Most exchanges support real-time Websocket and some even FIX protocol. Even HTTP-only for order entry is doable with advanced HTTP client frameworks (I use Akka-http).

HFT is when you are faster than most other traders. ;)

<comment><USER32> I saw your other top-level comment as well. Are you using Akka Websockets to interface with exchanges as well? Would love to share. See: [https://github.com/blbradley/kafka- cryptocoin](https://github.com/blbradley/kafka-cryptocoin)

<comment><USER2> Looks nice! My own code is much messier (currently rewriting with akka- streams). Yes, I'm using WS client from akka-http.

Liked how you pattern match directly on JSON messages, I should di it more. :)

<comment><USER32> Thanks! Feel free to continue the conversation through my listed GitHub e-mail.</comment></comment></comment></comment></comment>


Ext JS 3.0 RC1 released (Samples) - <AUTHOR> http://extjs.com/deploy/ext-3.0-rc1/examples/

<comment><USER2> It's $289 to use this?

<http://extjs.com/store/extjs/>

<comment><USER3> The core library is available under the MIT license: <http://extjs.com/products/extcore/download.php>

<comment><USER2> Please excuse my ignorance - why do they have both a commercial license and an MIT license? I'm confused. If I want to use it on my commercial site, don't I have to pay for a commercial license? If so, why should I care whether they have an MIT license also? Sorry, licensing is something I never really looked into.

<comment><USER4> Dual licensing is not mysterious. I'm not sure why folks find it so hard to imagine that a product can be had under multiple terms, depending on your preference and requirements.

The MIT license is a couple steps up from public domain (and far more liberal than the GPL). Ext Core can be used under those terms. ExtJS (not the same as Ext Core) has different terms (I think it's a modified GPL and a commercial license).

You do not need a commercial license to use Ext Core in any circumstance. You can use it on a commercial site, you can distribute it in commercial (or Open Source) products, and you can make modified versions without returning changes to the maintainers. The MIT license does have some clauses about IP (like trademarks) and indemnity (i.e. they provide none).

<comment><USER2> Thanks. Had no idea.</comment></comment></comment></comment></comment>


Art Thru Browser Elements  - <AUTHOR> http://www.the389.com/

<comment><USER2> That's very cool. I particularly like the waves of scroll bars (<http://www.the389.com/works/scrollbars/>) and using checkboxes as pixels (<http://www.the389.com/works/drops/>).</comment>


It's all about the timing, baby - <AUTHOR> https://medium.com/@TomPJacobs/startups-they-re-all-about-the-timing-83b1ef5f38c5

<comment><AUTHOR> Pick the title reference</comment>


Ask HN: What are the best resources for learning data visualization techniques? - <AUTHOR> <comment><USER2> Really depends on what you want to do, what tools are available to you, and how theoretically you want to get.

For theory based academic papers, take a look through previous IEEE Vis conferences to see what's currently being presented -> [http://ieeevis.org/year/2018/welcome](http://ieeevis.org/year/2018/welcome)

For books on techniques and thinking of it, Nadieh Bremer (D3 and Data Art extraordinaire) has some good reviews -> [https://www.visualcinnamon.com/resources/learning-data- visua...](https://www.visualcinnamon.com/resources/learning-data- visualization/books)

For what's possible using D3 take a look at [https://bl.ocks.org/mbostock](https://bl.ocks.org/mbostock)

For other avenues / tools, feel free to email me at email@example.com and I can fill you in. It's what I do for a living (for the past ~6 years) and I've been visualizing data online since about 2008 so I have tons of links and resources to share. Just let me know what's helpful.</comment>