hdevalence

I don’t think Rust needs this; Rust has done great for the last decade with the coherence rules it has. I am glad to not have to worry about this, and to not have to worry about any of the downstream problems (like linker errors) that coherence structurally eliminates.

> you're arguing semantics here

Yes, semantics — what do things mean, exactly? — is the subject of the discussion here and is actually quite important in general.

It’s odd that the article identifies Apple’s hardware as a limitation for AI. I don’t think this is the case. If anything it’s the opposite, and makes Apple’s lack of execution more mysterious.

I was running Stable Diffusion on my iPhone two years ago. You can get quite good open weights models running on-device today. What’s going on over there?

The example you are discussing starts with the following user query:

<example> <user>how should recent semiconductor export restrictions affect our investment strategy in tech companies? make a report</user> <response>

Finding out where the user works is in response to an under specified query (what is “our”?) and checking for internal analysis is a prerequisite to analyzing “our investment strategy”. It’s not like they’re telling Claude to randomly look through users’ documents, come on.

Yes, I would

> We don’t know who placed the trades. We don’t know what they knew.

Actually, “we”, collectively, do know, because the SEC maintains an “XKEYSCORE for equities” called CAT.

If there was interest, the government could know exactly who placed these trades. But the call (options) are coming from inside the house.

When the government is acting badly, yeah

This is a bad solution because now method resolution is suddenly unpredictable and can change out from under you based on changes to remote crates

Rust just doesn’t really have linker errors.

After 8 years of programming ~exclusively in Rust it’s easy for me to take this for granted by forgetting that linker errors even exist — until I am rudely reminded by occasional issues with C/C++ code that ends up in the dep tree.

This property is downstream of the orphan rules, and given the benefit I wouldn’t give them up.

This article lists international money transfers as a non-useful application of blockchains. USDT on Tron alone is now settling 1.25T$ (1/3 of Visa’s annual settlement volume).

Clearly some people do find them useful.

That seems like a them problem?

If you don’t live in the EU why are you concerned about the application of European law? Why would it apply to you?

> by mitming the bus between the iris scanner and the rest of the unit, and making it report fresh unique scans

Hmm, I wonder if the worldcoin team also thought of that possibility?

(Yes, they did, the iris processing is done inside a hardware enclave so that the obvious attack is not possible)

https://whitepaper.worldcoin.org/technical-implementation

I am broadly anti-Worldcoin but it is reasonably competently executed at a technical level. It would be good to understand what they actually did before declaring it to be impossible.

I can’t recommend that anyone would be Dan’s student.

I haven't paid close attention recently but that doesn't seem that far off of performance available via (hardware accelerated) AES?

Looking at https://eprint.iacr.org/2018/392.pdf , it seems like:

- Intel CPUs can use AESNI to do AES at 0.64 cpb - AMD Zen cores have two AESNI cores and can achieve 0.31 cpb - Vectorized AES instructions (supposed to ship in Ice Lake five years ago, but maybe a casualty of Intel's AVX512 mishaps) were expected to bring it down to 0.16 cpb

In some sense this isn't a "fair" comparison in that it's fast because there's hardware acceleration, but that doesn't really matter, the hardware is there so it might as well be used.

A lot of discussion about async Rust assumes that the reason one would want to use async/Futures is for performance and scalability reasons.

Personally, though, I would strongly prefer to use async rather than explicit threading even for cases where performance wasn’t the highest priority. The conceptual model is just better. Futures allow you to cleanly express composition of sub-tasks in a way that explicit threading doesn’t:

https://monkey.org/~marius/futures-arent-ersatz-threads.html

Yes, that’s exactly the issue. You trade that friction for not having the friction of type errors in queries at runtime. Whether that tradeoff is a good one depends on your situation and preferences.

(You can also check in the results of the database queries, so you only need the db in the build stack when you touch db-related code).

Is Fastly planning to make their OHTTP service generally available (rather than just to specific deals)?

I wrote it while waiting to board in the airport, sorry

One use case for generating group elements with verifiably unknown discrete logs is for a commitment scheme, like a Pedersen commitment.

In a Pedersen commitment, you have two generators, let’s call them G_value and G_blinding. To commit to a value v, you choose a random blinding factor v_blinding and form the commitment C_v as

C_v = v * G_value + v_blinding * G_blinding

Later, you can publish (v, v_blinding) to open the commitment.

Pedersen commitments are really useful because they’re homomorphic: adding commitments produces a commitment to the sum of the values. So you can use them to do a limited form of computation on hidden data.

Where does the verifiable generation come in? Since G_value and G_blinding are both in the same prime-order group, there exists _some_ value r so that G_value = r * G_blinding. If someone knew this relation r, they could forge commitments, for instance

C_v = (v+1) * G_value + (v_blinding - r) * G_blinding

and claim that C_v is a commitment to the value v+1 instead, because knowledge of the relation r lets them “slide value” between the “basis vectors”.

So Pedersen commitments are only _computationally_ binding: finding r requires solving the discrete logarithm problem, which we assume is hard, as long as the generators G_value and G_blinding were generated through some verifiable procedure.

On the other hand, though, they’re perfectly hiding, since knowing r lets you find a valid blinding factor for _any_ value, so even an infinitely computationally powerful adversary can’t determine which value was used after the fact.

I’m a coauthor of Ristretto.

There is a much more concise explanation than in the linked post: in Ristretto, the encoding of group elements was constructed so that the encoding of the identity (zero) element of the group is the all-zero byte string. So it’s not surprising that the all-zero byte string has a known private key: it’s the all-zero secret key.

This aspect of the encoding makes it very easy to check whether a provided group element is the identity element, because “zero means zero”.

What the questioner seems to be looking for is a way to generate “burn addresses”, public keys with the property that everyone can be sure that no one else knows the secret key to. This is actually kind of hard: if I just give you a public key, how do you know I didn’t generate it from a secret key I know?

The correct answer to this “nothing-up-my-sleeve” problem is to have a group-valued hash function, which Ristretto provides. Then public keys can be specified as the outputs of the hash function.

It’s not strange at all. The “all zero public key” is the encoding of the zero element (identity element) of the group. Finding the private key corresponding to a public key A is finding the number a so that A = a*B. When A = 0, this is really easy: a = 0.

Correct, there’s no actual problem here, just a potential performance pitfall, but that pitfall is no worse than a naive synchronous implementation would be.

There’s no big problem here, just write code and run it. If it is a really big problem it will show up in a profiler (if you care enough about performance to care about this issue, you are using a profiler, right… right?)

> If yall want everyone to use Tokio then tell me why … it's the de-facto community standard. > I want some group with authority to bless a core async runtime implementation…

Hmm, if Tokio is the de-facto community standard, isn’t that saying that the authority of “people who write and run async code for actual production systems” is blessing it as a preferred option?

> The reality is that the goal is not realized because Rust has not done the work to enable everyone to simply bring their own runtime

Or, another possibility is that it hasn’t been realized because building a robust, production-ready, well-maintained runtime is itself a lot of work, and Tokio is the only project that has actually done it.

Unfortunately for those who care about noise reduction, LL patented the design, preventing its widespread use.

I don’t know about the nature paper’s assumptions, but supercharging provides far more power than could possibly be supplied to the grid via V2G — for instance, a 100A home service can draw at most 24kW (AC), while supercharging draws up to 250kW (DC). V2G would use the car’s onboard AC/DC converter, which usually tops out at 10-12kW, so it would be relatively slow discharge from the car’s perspective.

Edit: from the paper:

> We assume the home charging power as 1.92, 6.6, 22, and 1.92 kW for small, mid-size, large BEV, and PHEV, respectively

I don’t think the 22kW assumption is reasonable, but the others are comfortably within current L2 AC charging rates.

The 2 cent figure is per kWh, not per cycle. Multiplying by the 75kWh pack size gives $1.50.

What about the remaining 10X? The calculation you’re doing isn’t the right one, because the battery wear isn’t directly related to miles driven; Tesla’s battery warranty is pricing in a “full stack” picture of battery degradation while actually driving.

Your computation implies that the battery has 0 value after ~1000 cycles, but battery manufacturers commonly warranty 3,000-5,000. In addition, cycle count is only one variable affecting degradation, others include the depth of discharge, the charging and discharging profiles, the thermal management, etc.

(This is one reason why a 10-year-old Tesla has noticeably different battery degradation than, say, a 10-year old Nissan Leaf, which has no thermal management and a very poor BMS)

Finally, even when battery degradation occurs, it doesn’t remove the battery’s entire capacity, so degraded batteries can still be used for stationary storage applications. While an extreme degradation like 50% is very bad for an automotive application, it doesn’t matter so much for small-scale grid storage, since space is usually not the limiting factor.

Yes, but for this reason, the Bluetooth implementation is on physically separate, untrusted hardware that has no access to the buttons or screen other than by communication with the secure element (see [0] for the Nano X; I’m assuming the Stax will be basically similar).

So this isn’t really different from having a USB cable: in either case, some untrusted messages arrive at the secure element over some wires, and get processed there. The only difference is that the wires come from another chip on-device rather than from an external cable.

[0]: https://www.ledger.com/ledger-nano-x-bluetooth-security-mode...

No, the attacker still needs physical access to the device, because signing requires on-device approval.

The security model already assumes that the entity requesting authorization is untrusted, so the security model is basically unchanged. An attacker who can forge BT packets to submit bad data for approval is not really different from an attacker who compromises the laptop/phone/etc to submit bad data for approval.

If your secure hardware doesn’t have a display, how do you know what you’re signing?

You can’t, so you’re forced to trust that the software talking to the HSM isn’t lying to you about what data it’s asking to be signed, and at that point you’re only marginally more secure than not using an HSM at all. (Sure, it’s harder to steal the long-term key material, but if I compromise your software, I get a signing oracle, and that might be good enough.)

This is actually something that the blockchain ecosystem gets right: every hardware wallet has a secure display of some kind, to avoid blind signing, because it’s a context where security actually matters (unlike, e.g., “signing git commits with a yubikey”, which nobody cares enough about to attack).