Hacker News new | past | comments | ask | show | jobs | submit | pclmulqdq's comments login

I hate to tell you, but even if you have never done 23 and me or anything similar, enough of your family has that your genetic data is already very readily accessible to the parties who need it.

One major point of the presentation here is that it's not making real progress. People are still publishing papers, but they have done nothing with an effect outside their little community. It's been in roughly the same state for the last 10 years. For a minimum of 30 years, there have been promises of amazing things coming in the next decade in QC. After how many decades should those predictions lose credibility?

There is real opportunity cost to doing this stuff, and real money getting sucked up by these grifters that could be spent on real problems. There are real PhD students getting sucked down this rabbit hole instead of doing something that actually does make progress. There is a real cost to screwing around and making promises of "next decade."


> One major point of the presentation here is that it's not making real progress.

How are you measuring "real progress"?

> People are still publishing papers, but they have done nothing with an effect outside their little community.

Having an effect outside the research community is essentially a Heaviside function. Before the field is mature enough, there is no effect outside, but once the field is mature enough, there is an effect outside. Makes it hard to judge if there is any progress or not.


The field has had 40 years of maturing. Experimentation on QC started in the 1980's. At what point are we going to be factoring numbers or (more realistically) simulating chemical interactions?

Real progress in this field is very easy to measure. It's based on number of effective qbits of computation. That is just a metric where QC is failing to deliver so badly that everyone in the field wants to deny its existence.

Unfortunately, the level of investment in QC is very much outsized compared to the level of progress. These things should rise at the same time. More promising areas of science can get the investment that is otherwise being sucked into QC.

> Having an effect outside the research community is essentially a Heaviside function.

This is something that people like to say but is never true. Impact on the outside world for new technologies is almost always a sigmoid function, not a heavyside function. You should see some residual beneficial effects at the leading edge if you have something real.


> Real progress in this field is very easy to measure. It's based on number of effective qbits of computation.

Plenty more progress measures (decoherence, gate fidelity/error rates) to use that we have made significant progress in over the last 10 years.


I agree! People who predicted QC soon over the last few decades should lose credibility. They were wrong and they were wrong for no good reason. There is a real opportunity cost to focusing on the wrong thing. There are definitely grifters in the space. Responsible QC researchers should call it out (e.g. Scott Aaronson).

But it doesn't necessarily follow that you can dismiss the actual underlying field. Within the last five years alone we've gone from the quantum supremacy experiment to multiple groups using multiple technologies to claim QEC code implementations with improved error rates over the underlying qubits. People don't have to be interested in these results, they are rather niche (a little community as you put it), but you shouldn't be uninterested and then write a presentation titled 'Why Quantum Cryptanalysis is Bollocks'.


Well, when the little community circles the wagons around the grifters instead of excising them, the rest of us get to ask questions about that community. The cold fusion community did the same thing for several decades, too.

And by the way, about 0.01% of the grifters in the QC space are getting called out right now.


Yes, but it can also be like EUV.

Not working for years upon years, and suddenly it works, and if it does it can be a huge problem. I don't know if I trust PQC though, but that only means that more research on it is needed.


Yeah, I don't think anyone told him about WindsorGreen, the RSA-cracking supercomputer that IBM built for the NSA. RSA-1024 probably should be assumed unsafe at this point.

You are describing something that is practically more like a computer algebra system than a number system. To go infinite without infinite storage, you need to store the information required to compute the trailing digits of the number. That is possible with things like pi, which have recursive formulas to compute, but it's not easy for arbitrary numbers.

> That is possible with things like pi, which have recursive formulas to compute, but it's not easy for arbitrary numbers.

It is possible for pretty much all the numbers you could care about. I'm not claiming it is possible for all real numbers though (notice my wording with "express" and "represent"). In fact since this creates an equivalence between real numbers and functions on natural numbers, and not all functions are computable, it follows that some real numbers are not representable because they correspond to non-computable functions. Those that are representable are instead called computable numbers.


How would you get those numbers into the computer anyway? It seems like this would be a practical system to deal with numbers that can be represented exactly in that way, and numbers you can get at from there.

The way every other weird number gets into a computer: through math operations. For example, sqrt(7) is irrational. If you subtract something very close to sqrt(7) from it, then you need to keep making digits.

I am the last person to be defending NAT, but the benefit of NAT is that it sets up a really good default: incoming connections are not routable by default, and it's very hard to accidentally change this. There are many good ways to have "not routable by default" with IPv6, but you have to do that at the software level, while NAT forces it at a protocol level.

> incoming connections are not routable by default, and it's very hard to accidentally change this

Not just difficult, but impossible, even in principle, because there are more than one device sharing the same IP so at most one host would be vulnerable. Not the same as with IPv6, where screwing up the defaults leaves your entire network vulnerable.


You can forward all ports to a device, pretty common feature.

Right but that only leaves that device vulnerable. The other devices are not.

In practice, that makes the entire network vulnerable.

Yeah, server-side NAT + use of a reverse proxy makes hosting many websites from one IPv4 a possibility, albeit a relatively difficult one. You are only really in trouble if two consumers want raw TCP/UDP on one port.

> incoming connections are not routable by default

Tons of firewalls ship with this as a default logic, it doesn't require NAT in the slightest.


Parent poster is making the (good and underrated) point that NAT makes this logic failsafe: Turn an IPv6 firewall off and you’ve got all incoming connections allowed. Turn IPv4 NAT off and you’ve got no connectivity at all

So gate it behind a "here be dragons" option or hide it in the GUI entirely for the basic home version.

Turning off the firewall could just as easily be a unnoticed configuration error that causes it to die on startup

Or make the "turned off" state block all traffic, just like closing a water valve, or a road gate. I never understood why network firewalls did not default to this.

How are you gonna get the IPv6s of your targets? Can’t scan a /64, and with ephemeral ”security” addresses used for outbound conns, an adversary won’t be able to guess the address anyway. At least that’s my understanding. So I guess my question is: is this a real threat?


This reminds me of a company where the admin used public routable IPs for the internal subnet. The gap is always the human in the loop.

There's nothing wrong with this, and it's common at universities that have large IPv4 allocations.

The subnet that he used internally was "officially" used and owned by oracle and our printers regularly send traffic falsely to Silicon Valley.

This was the norm for most of the 90's and earlier. NAT was supposed to be the exception, but it became the rule. Now we have an entire generation that doesn't understand that the Internet was always supposed to support end-to-end connectivity.

Plus too many of that generation see NAT as a "security feature" not an "IP bug" and can't seem to (re-)imagine traditional firewall/router design from the time before NAT. "end-to-end connectivity" is not the same thing as "open and unsecured connectivity", we have the security tools to deal with that and they are not and have never been named "NAT".

To say NAT has nothing to do with "security" is a lie. The most common NAT (PAT) configurations are basically acting as stateful firewalls with a default deny policy for all unsolicited inbound traffic to a private, non-routeable network.

They aren't doing that though. The most common NAT (PAT) configurations don't deny unsolicited inbound traffic.

They are of course commonly deployed together with a firewall that does deny that traffic, but claiming that NAT blocks connections because it's usually deployed together with a different technology that handles all of the blocking would also be lying.


> The most common NAT (PAT) configurations don't deny unsolicited inbound traffic

That doesn’t make sense.

If I have a single routable IPv4 addresses and 100 machines behind it with RFC1918 addresses, how can any possible router “allow by default” say, port 22? Which machine would it route it to? Would it pick the first one? Randomly select one?

Of course NAT has to drop incoming unsolicited packets. Unless you tell it which machine to route them too, it couldn’t possibly know how to “allow” them in the first place.


IP packets have a "destination IP" header field that specifies where the packet goes. The router reads that to figure out where to send the packet.

The only thing NAT does is rewrite the dst or src headers of packets. If there's no rule or state entry that applies to a packet, it doesn't drop the packet. It just leaves the original headers on it.


How would a packet with a destination IP of my internal RFC1918 address have landed on my WAN interface in the first place? It would require my ISP to have a routing rule that sends it to my router. Is that the threat model you’re thinking about?

He's assuming your non-routeable RFC1918 addresses are actually routed from the Internet, which won't be happening in the normal consumer use case.

Even if there's no blocking, using internal RFC-1918 addresses still adds a layer of security since they are not reachable globally.

> basically acting as stateful firewalls

Stateful Firewalls are the security tool. NATs being mediocre to somewhat alright stateful firewalls "out-of-the-box" before adding a real Firewall is the accident (and sometimes bug). Something doing security by accident (or as a bug) isn't a security tool (just like security through obscurity isn't a security tool). You can have Stateful Firewalls without NAT. Everyone saying that you "need" NAT to have Stateful Firewalls doesn't understand Firewalls or even possibly why "firewall" is and has always been a different word from "NAT". NAT has something to do with security, but that's being generally always paired with a good firewall, not being a mediocre firewall mostly by accident.


It doesn't help that the use of an IPv4 is a status symbol that indicates that you are willing to spend money on your infrastructure (and are thus not a spammer). If you attempt to run an email server on IPv6, you will see what I mean.

That's not what I am observing while running a number email servers which having both IPv4 and IPv6. Spam is only on IPv4 and about 80% of legitimate email is on IPv6.

Yes, but those facts don't reach the email filtering business: There, IPv4 IPs have some reputation, maybe good or bad. IPv6 "just doesn't exist" and has a universally bad reputation. Thus your IPv6-Emails will be filtered and dropped more often, even though you are correct that actually IPv6 is an indicator of non-spam. I've got quite a few transport rules to work around those kinds of braindead filters...

> IPv6 "just doesn't exist" and has a universally bad reputation.

I've been sending my mail via IPv6 for ages without issues… did you mean reputation or reputation?


> I've been sending my mail via IPv6 for ages without issues…

In most cases it does work and there are no problems. But especially medium-sized businesses who run their own email through some crappy mailfiltering middlebox file anything that comes from or through an IPv6 endpoint to spam.

> did you mean reputation or reputation?

I don't understand your question. I meant IP address reputation, which is what many mail filtering systems use to estimate spam probability or outright reject email. See for example https://www.spamhaus.org/ip-reputation/


That does not match my experience either. In fact I don't see why any mail server would bother getting and configuring an IPv6, listen on it, just to drop all received messages.

Just don't listen on v6, that would achieve your goal, would prevent reputable dual-stack senders (like Google!) to send messages over v6 that you'll drop, and simplify your configuration.


> I don't understand your question. I meant IP address reputation, […]

There's reputation of the IP address(es) among spam filters, and there's reputation among human operators configuring mail servers. I was trying to riff on ambiguity with ambiguity, that wasn't particularly helpful, sorry.


I found an open email relay on IPv6 once, because nobody scans IPv6 and therefore nobody ever sent spam through it. (Apparently this was caused by a reverse proxy misconfiguration causing the server to think IPv6 connections were from localhost)

Also the surface area of IPv6 is huge, it just takes so much time to scan everything. It's not security, but it's a deterrent.

And yet scanning IPv6 is exactly what some people are doing.

IPv6 nodes aren't individual random addresses in a 128-bit address space. They are going to be grouped in subnets, so it makes sense to explore /64 ranges where you know there's already at least 1 address active. There's a pretty decent chance at least some addresses are going to be sequential - either due to manual configuration or DHCPv6 - so you can make a decent start by scanning those. For non-client devices, SLAAC usually generates a fixed address determined by the NIC's MAC address, which in turn has a large fixed component identifying the NIC's vendor. This leaves you with a 24-bit space to scan in order to find other devices using NICs made by that vendor - not exactly an unfair assumption in larger deployments. Much faster scanning can of course be done if you can use something like DNS records as source for potential targets, and it's game over once an attacker has compromised the first device and can do link-local discovery.

It's not going to be extremely fast or efficient, but IPv6 scanning isn't exactly impossible either. It's already happening in practice[0], and it's only going to get worse.

[0]: https://www.akamai.com/blog/security-research/vulnerability-...


Well, and the easiest way is some sort of web bug/tracker/log or traffic analysis.

See what address gets used, and blam.


In many situations it's a necessity. Ipv4 only devices can't connect to ipv6 only servers. So if you have ipv4 clients, your server has to support ipv4.

Get a front that binds a IPv4, with a loadbalancer or a wireguard tunnel.

IEEE 754 is what you get when you want numbers to have huge dynamic range, equal precision across the range, and fixed bit width. It balances speed and accuracy, and produces a result that is very close to the expected result 99.9999999% of the time. A competent numerical analyst can take something you want to do on paper and build a sequence of operations in floating point that compute that result almost exactly.

I don't think anyone who worked on IEEE 754 (and certainly nobody who currently works on it) contemplated calculators as an application, because a calculator is solving a fundamentally different problem. In a calculator, you can spend 10-100 ms doing one operation and people won't mind. In the applications for which IEEE 754 is made, you are expecting to do billions or trillions of operations per second.


William Kahan worked on both IEEE 754 and HP calculators. The speed gap between something like an 8087 and a calculator was not that big back then, either.

Billions or trillions of ops per second and 1987 don't really go together.


Good point! Side note: Cray-2 did not use IEE 754 floating point.

https://cray-history.net/2021/08/26/cray-floating-point-numb...


Yeah I mean they were surely too old to support it. But the designers of IEEE-754 must have been aware of these systems when they were making the standard.

Cray did use floating point. It didn't use IEEE standard floating point. Floating point arithmetic is older than the transistor.

Yeah I know. I linked the specs.

> equal precision across the range

What? Pretty sure there's more precision in [0-1] than there is in really big numbers.


Precision in numerics is usually considered in relative terms (eg significant figures). Every floating point number has an equal number of bits of precision. It is true, though, that half of the floats are between -1 and 1. That is because precision is equal across the range.

Only the normal floating point numbers have this property, the sub-normals do not.

In the single precision floats for example there is no 0.000000000000000000000000000000000000000000002 it goes straight from 0.000000000000000000000000000000000000000000001 to 0.000000000000000000000000000000000000000000003

So that's not even one whole digit of precision.


Yes, that is true. The subnormal numbers gradually lose precision going towards zero.

Subnormals are a dirty hack to squeeze a bit more breathing space around zero for people who really need it. They aren't even really supported in hardware. Using them in normal contexts is usually an error.

As of 2025, they finally have hardware support from Intel and AMD. IIRC it took until Zen 2 and Ice Lake to do this.

Oh joy! Just in time for all computation to move to GPUs running eight-bit "floats".

At some point, when I get a spare 5 years (and/or if people start paying for software again), I will start to work on a calculator application. Number system wrangling is quite fun and challenging, and I am hoping to incorporate units as a first-class citizen.

I'm curious, what aspects of AI music do you find specifically appealing?

It's Jane Street. If two people haven't played this game for $10,000, I would be very surprised.

Their version of Liar's Poker.

Join us for AI Startup School this June 16-17 in San Francisco!

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: