ianmiers

This is inaccurate and in a hilarious way. Treasury is not coming after Bitcoin. There's an update in an ongoing rulemaking process that got reported here[0] as banning mixing and privacy tools. It may have been blown out of proportion[1], but I am not a lawyer, and certainly banning these tools would be bad. The thing is, Bitcoin's not private—every transaction is public for everyone to download. It's Twitter for your bank account. And that comes with serious privacy, safety, and boring commercial counterparty risks that should be addressed. These kinds of tools exist to mitigate that problem. The irony is that Bitcoin has largely refused to address this obvious issue, so no, Treasury isn't coming for Bitcoin. Indeed, there been years of people arguing Bitcoin would be just fine with no privacy protections. [0] https://www.therage.co/us-government-to-bring-patriot-act-to... [1] https://x.com/valkenburgh/status/1966174324701778071"

This is by no means a comprehensive analysis. This analysis misses the most major limitation with Monero's decoy based approach to transaction obfuscation: Eve-Alice-Eve attacks (also known as ABA attacks). It also misses an analysis of the possible insecurity of churning and a significant history of randomness implementation errors and flooding attacks specific to Monero. The exact consequences of some of these attacks remain an open question, but worthy of mention.

A simple and surprising limitation of Monero and any other decoy-based approach is that if you repeatedly withdraw money from one exchange and then deposit it to another, those transactions are not private (edit: even if we ignore payment value). This is a form of Eve-Alice-Eve attack.

Monero uses decoy transactions to obscure the transaction history on-chain, but it does not remove the history. There's a reason every other major privacy protocol (Zcash, Tornado Cash, Railgun, Aleo, Penumbra, etc.) does not use Monero's decoy-based approach, and even the Monero developers are moving to the standard zero-knowledge proof over an accumulator (IIRC a merkle tree like everyone else) based approach that they call Full Chain Anonymity Proofs.

As a meta-comment, this is one of a genre of Monero "privacy" analysis documents that are circulated as a way to claim there are no known actively used exploits. This is little better than the classic "my scheme is secure; here's a bounty for anyone who breaks it" form of cryptographic analysis we often see with flawed encryption schemes. Breaks will not always be public.

if you just sent Mick down the left path and he came out the right, then a video would conclusively show he knew the password.

And this is why "How to explain zero-knowledge protocols to your children" is probably the worst way to explain zero-knowledge protocols to anyone. Its not explaining what a zero-knowledge proof is or how it works. It's explaining what a simulator is when proving a protocol is zero-knowledge . Oh, and the explanation only works for interactive protocols.

Paying in cash, in addition to being a minor inconvenience that non-the-less outweighs most people's desire for privacy, does not work in online payments. It also doesn't work in businesses that get robbed.

The better question is, why do you need a new currency to get privacy? Why couldn't we have a private crypto currency backed by dollars or euros? There's no technical reason, indeed several groups are building this. What remains to be seen is if there's sufficient incentives to build anything around these or for any portion of the economy to move to them. Most purchases aren't sensitive, so for private payments to work, they need to be ubiquitous for non privacy reasons and just give people who need it the option for privacy. Much like cash does. But again, cash doesn't work online or increasingly offline

Fun fact, AMMs were considered well before cryptocurrency.

" The most popular automated market maker used in Internet prediction markets is Hanson’s logarithmic market scoring rule (LMSR), an automated market maker with particularly desirable properties [Hanson 2003, 2007]. The LMSR is used by a number of companies including Inkling Markets, Consensus Point, Yahoo!, Microsoft, and the large-scale non-commercial Gates Hillman Prediction Market at Carnegie Mellon [Othman and Sandholm 2010a]." From https://www.cs.cmu.edu/~sandholm/liquidity-sensitive%20autom...

Yeah, those papers are very dense. You might want try reading zerocoin[0] first, it was the starting point of all the zero-knowledge proofs for private payments on a blockchain. Then another academic paper, Pinocchio coin, had a proposal for zkSNARKs. And Zeorcash built the zksnark + merkle tree+ serial umber (later called a nullifiers ) approach.

[0] https://www.cs.umd.edu/~imiers/pdf/ZerocoinOakland.pdf

This is pretty cool. But you might want to update the credit for the zksnark +merkle tree + nullifier idea. It's from an academic paper, Zerocash in 2014. The approach is used in Zcash and then in Tornado.cash Though Tornado.cash is actually an odd hybrid between Zerocash's merkle tree+snark approach and an older academic paper, Zerocoin, which proposed a zk mix protocol as an add on to Bitcoin.

I don't think tagging people as ex 8200 is very helpful. Israel has mandatory military service and at this point if you have aptitude or are in a high school computer club in Tel Aviv or a few other places, you probably end up in 8200 for your service. For that matter, half the people who say there were in 8200 were either 1) listening to telephone calls 2) relegated to writing memos about the data people did hack and get. Of course, there are things one could have done that would raise serious questions. See, e.g., the issues raised for the people we know who worked on DualEC_DRBG.

On the other hand, there are other sketchy things about express VPN.

This has already happened. A catholic newspaper bought commercial location and app data and used it to out a gay priest who was forced to resign. They broke the joke "privacy protections" by knowing his home, office, and a conference he went to. https://arstechnica.com/tech-policy/2021/07/catholic-priest-...

It's an important distinction. The fact that huge numbers of people rotate through the hacking side of 8200 (like the NSA, vast majority of 8200 members don't work on that) is what drives the supply.

Intelligence services typically have less turnover. Though that is changing, particularly for NSA, where people leave to go to contractors.

Also, frankly, describing NSO as ex Mossad just makes phone malware sound much more complicated than it is and much harder to stop. At the end of the day, its software, written by people in much the same way any software is written. It just exploits mistakes other software devs made so that it can run.

NSO group is ex unit 8200, which is military signals intelligence. So in American terms, it's the NSA not the CIA. The distinction is important in a country with mandatory military service. You get a large number of people who go through, get trained, and then leave because it never was a career. A number of them take their skills to the private sector.

Mossad, on the other hand, is a civilian intelligence service and I'm told there's a strong tradition that its members don't freelance their services after leaving.

Because Bitcoin is twitter for your bank account. It exposes everything you do to anyone who can download the blockchain.

You can argue that some gov/regulator should have access, though good luck finding one country everyone trusts. More realistically, and practically, you could require that, as many jurisdictions do with cash, we should have reporting requirements for when a merchant sells something for large amounts of cryptocurrency.

But its pretty hard to argue everyone should be financially naked and exposed to anyone who wants to look. To fix that, even if you're government surveillance friendly, you first need to make the blockchain zero-knowledge (which Monero actually isn't good at, but thats irrelevant here).

There are some Zcash forks with iffy dev support and no market traction. The problem is the kind of cryptography you need to do something like Zcash is very very very hard to get right. Zcash actually got the tech right and handled the issues they hit well. They just didn't do a good job with reputation outside of tech.

No one else as done the same tech yet themselves. A few things have launched and allegedly plan to add a privacy layer (Mina, Celo). But actually building that kind of tech is a lot harder than reputation management or standard blockchains.

It's still an open playing field.

I think the reddit user someone else linked to pretty clearly explained the Monero side. Zcash has a bad reputation with darknet markets and the like that use Monero. Some of it deserved. ( I say this as someone who wrote original Zerocash protocol) https://www.reddit.com/r/Monero/comments/oui6zj/zcash_vs_mon...

Also, Zcash has optional privacy.

On the other hand, the decoy based privacy protocols Monero uses are not really private at all. https://slideslive.com/38911785/satoshi-has-no-clothes-failu...

Its cryptocurrency, everything is tribal.

Partially, but it's also: you will pay for a phone number, you won't pay for icloud, etc. So, as a result a phone number is costs something like 10 cents for an attacker.

What happens if someone tries to coerce Apple into writing backdoor code? Engineers at Apple could resist, resign, slow roll the design and engineering process. They could leak it and it would get killed. Things would have to get very very bad for that kind of pressure to work.

On the other hand, once Apple has written a backdoor enthusiastically themselves, it's a lot easier to force someone to change how it can be used. The changes are small and compliance can be immediately verified and refusal punished. To take it to its logical extreme: you cannot really fire or execute people who delay something (especially if you lake the expertise to tell how long it should take). But you can fire or execute people who refuse to flip a switch.

This technology deeply erodes Apple and its engineers' ability to resist future pressure. And the important bit here is there adversary isn't all powerful. It can coerce you to do things in secret, but its power isn't unlimited. See what happened with yahoo.[0]

https://www.reuters.com/article/us-yahoo-nsa-exclusive/exclu...

> Our system involves both an on-device component where the voucher is created, but nothing is learned, and a server-side component, which is where that voucher is sent along with data coming to Apple service and processed across the account to learn if there are collections of illegal CSAM. That means that it is a service feature.

Neuenschwander seems to, maybe deliberately, be conflating : "Apple's servers have to be in the loop" and "the code can only look at photos on iCloud".

You are right, the problem is a "slippery slope," but Apple just built roller skates and there are governments trying to push us down it. Apple is in a far better position to resist those efforts if they say " we don't have this code, we will not build it, and there's no way for it to be safe for our users."

I'd say that's a little different than the slippery slope. Something more like (in)defense in depth.

yes, you can turn AV into the same thing. But no one has been advocating for that or passing laws that would make AV both mandatory and have to report you to the police.

This has been going on for CSAM scanning for a while now. The latest version was called the EARN IT act [0]

The argument is not this is a slippery slope where you might miss step. IF that was the case, yes AV would be analogous. Instead, its that people are actively trying to push you into the spikes at the bottom of the pit, don't build things at the edge of the pit where the handrail is a pinky promise not to let others push you.

[0] https://blog.cryptographyengineering.com/2020/03/06/earn-it-...

>The only thing stopping your phone from keylogging your password to a server in the NSA somewhere if it recognizes a specific trigger pattern is Apple's willingness and ability to resist pressure from the US, etc.

Think of what would happen if you tried to make your average Silicon Valley dev team design, implement, and test a surveillance system they didn't want to build and that was immoral. They'd resit in an infinite number of ways that would delay the project virtually for ever. Short of summary executions, I bet you could not get a nice, efficient, effective system.

On the other hand, once the dev team has enthusiastically built the system that scans for any image, it's entirely easy to say "Now, make it look for these images." They have no avenue for resistance other and a up front no. And a government that wants to do totalitarian things knows many ways to force a yes.

Yes, and even more ironically, thats precisely the problem. Because it makes mass sweeping of client side content viable --- both technically and morally--- in a way never possible before. The only thing stoping scanning of the entire phone for anything, now that Apple built the technical capability, is Apple's willingness and ability to resit pressure from the US, UK, China, and others to use it.

Factually, not yet. That will change and I will explain how in a moment. But first there's a major difference between doing it on device vs in the cloud. It changes how we think about privacy and builds a capability to scan phones (not particularly limited to iCloud) into the device. That's a capability no Western tech company could ever be forced to build for more illicit usages, but now it exists.

Second, Apple almost assuredly will encrypt iCloud after this. So now we have the precedent of scanning encrypted messages. And that will then feed legislation that congress has been attempting to pass for years to kill any right to meaningful end to end encryption for messaging. https://blog.cryptographyengineering.com/2020/03/06/earn-it-...

This is a harmful distraction from the massive issues with Apple's proposal. If you wanted to frame someone for possession of CSAM, similar stunts can be pulled with Google, Facebook, Instagram, and Microsoft today. Yes, the scope here is broader and some people don't use any of those, but ....It's silly, and it makes the tech community look like a fringe minority of screeching conspiracy theorists.

And this is a problem because Apple's proposal is really really awful. Apple is normalizing scanning your private phone for files and reporting them. They built the technical capability to do it for any photo, and they will be under enormous pressure to expand it both in the US and abroad. And the fact that they did it will be used to pressure other companies into doing the same and to legitimize laws that require scanning for any content the government can justify.

Apple built a surveillance mechanism that is incredibly powerful. One no government could ever force a company to design and build. But once it's built, the only thing stoping it from being abused is Apple's pinky promise they won't let it happen. If you believe that legal norms, big tech companies and some quasi governmental nonprofit like NCMEC will stop such an abuse if it happens .... where have you been living the past few years? Because it sure isn't the US, the UK, Turkey, or China.

Read the article and discussion here https://news.ycombinator.com/item?id=28118350. It makes the point pretty well.

>That, of course, is the rub: Apple controls the algorithm, both in terms of what it looks for, what bugs it may or may not have, and also the inputs, which in the case of CSAM scanning is the database from NCMEC. Apple has certainly worked hard to be a company that users trust, but we already know that that trust doesn’t extend everywhere: Apple has, under Chinese government pressure, put Chinese user iCloud data on state-owned enterprise servers, along with the encryption keys necessary to access it. What happens when China announces its version of the NCMEC, which not only includes the horrific imagery Apple’s system is meant to capture, but also images and memes the government deems illegal?

>The fundamental issue — and the first reason why I think Apple made a mistake here — is that there is a meaningful difference between capability and policy. One of the most powerful arguments in Apple’s favor in the 2016 San Bernardino case is that the company didn’t even have the means to break into the iPhone in question, and that to build the capability would open the company up to a multitude of requests that were far less pressing in nature, and weaken the company’s ability to stand up to foreign governments. In this case, though, Apple is building the capability, and the only thing holding the company back is policy.

>Is there some evidence you have of this plan? Sounds like this is just a fear you have.

The EARN IT act. It may not be Apple's plan, Apple's plan, as you suggest, might only be for doing scanning on encrypted iCloud and excluding encrypted iMessage. But what Apple will be pushed to do after that is pretty clear.

Yep. That certainly is the next step. And then, once you are scanning encrypted data, iMessage is next whether you want it or not.

Apple's banned image reporting wont stay iCloud only.iMessage is next. Maybe all data on your phone. 1) phone scanning is overkill for pics already on their servers. You don't build this and take the PR flack for something you can already do server side 2) Even if it's somehow not Apple's plan, they will be forced to use it on iMessage. Congress has been trying to for years.See the EARN IT act[0].

Apple just erroneously said "it's safe" despite the fact that it clearly can be abused.

[0] https://blog.cryptographyengineering.com/2020/03/06/earn-it-...

Its a nuanced conversation, but there two fundamental points that Apple totally missed.:

1) Don't build a system for reporting what images people make, store, or send privately. That is just begging for someone to force you to abuse it for things that aren't CSAM. You shouldn't expect Apple to be able to resist pressure to abuse such a system. 1)they already caved to China by basically handing iCloud + iMessage key infra to a local company. 2) The entire reason you have encrypted systems(and make no mistake, this entire scheme only makes sense to scan encrypted content) is precisely for the day when the social and repetitional guarantees of "trust us" fail.

2) We need alternative ways to stop grooming and effectively get the major players who produce CSAM. And that's not going to come from scanning for CSAM NCMEC already knows about. Yes, resharing images harms the victim, but if you have a finite amount of resources, you go after the original image production and the people literally raping kids. And indeed, thats apparently what the FBI does and why they mostly ignore reports flagged by these systems.

From what I've seen in residential Tokyo, houses are usually one offs built when the owner buys the land. And look, at least superficially, to be similar construction methods to American construction rather than European: i.e. wood framing as opposed to masonry/concrete.

Maybe some of it is prefab, but given the narrowness of roads, I wonder.

Sure. Starting from the academic beginning and then going to commercial usage: Zerocash[0], a paper from 2014 (I'm an author on it), proposes using zksnarks to get a public ledger + privacy with no centralized parties. Instead of identifying the origin of your money on the blockchain and moving it to someone, you just prove in zero-knowledge your payment is correct. This showed strong privacy on a public blockchain was feasible. But slow (2 minutes per payment IIRC)

Three years and much work by others later, it takes ~2 to 3 seconds on a Pixel three to make a zk-proof for a payment. This can be optimized down to 1 second fairly easily (on that you have only my assertion currently)

This is commercially deployed in Zcash (the above mentioned coin with usability and adoption issues), a few other straight up forks, and a new coin called IronFish. And related protocols are in a few things on Ethereum (e.g., Aztec). If you want to test performance numbers, you can download one of these systems and try it yourself (Nighthawk is a decent mobile wallet for Zcash)

Current technical objections (again, beyond criticisms of Zcash as a coin itself) 1) Current ZK proofs require trusted setup. New ZK proofs developed by engineers at Zcash removed this[1]. So its not longer an issue for the technology (or for Zcash once it's deployed)

2) you have to scan the blockchain to get notified of payments. No, this happens to be how Zcash does it. As I said in a separate comment, it's easy to send payment notifications out of band.

3) Vague objections about "scale." Even though zksnarks take a second or two to prove, they are very fast to verify. So adding privacy doesn't make blockchain's scaling problems worse. And the privacy tech is agnostic to the underlying consensus layer, so if you ever get a blockchain to scale, you can put privacy on it.

4) Other approaches(Monero/RingCt/Coinjoin) are better. The major problem is these don't offer strong privacy, just obfuscation. See [2] if you want a 20 minute talk on the issues or [3] for a blog post covering the same

5) There's an inflation risk. Yes, once you hide the values of a payment, because you want privacy, if the crypto breaks, things can go wrong. This is true of any serious approach to privacy. So you want to very carefully vet the crypto design. But if you don't hide payment values, you get no privacy and your blockchain is twitter for your bank account.

[0] https://www.cs.umd.edu/~imiers/pdf/zerocash-oakland2014.pdf [1]https://electriccoin.co/blog/technical-explainer-halo-on-zca... [2]https://www.youtube.com/watch?v=9s3EbSKDA3o [3]https://www.zfnd.org/blog/blockchain-privacy/