nehan

"While unlikely, we cannot rule out that de-identified data derived from their usage of our products helped improve our models."

I think they should be able to unravel whether or not any sessions by Tristan or Levent went into the training data for this model.

excellent point! I agree.

I can't think of heuristics available on the Bitcoin P2P network that would be helpful for this, but I'm curious if you have any in mind.

Sorry I wasn't clear there. Because most of the short-depth is controlled by centralized exchanges, there's a risk you won't be able to actualize your short (withdraw, either in crypto or to a bank account), even if it's successful -- they could just block you from withdrawing and/or report you for fraud.

The point is you can't distinguish transactions that are from an "attacker" when the underlying signature scheme is broken. The Bitcoin P2P network has some metrics to disconnect from nodes that might be trying to DoS you, but if a transaction has enough fees, is spending unspent coins, and has a valid signature, it's valid.

Also, LetsEncrypt is very cool! Thanks for working on it.

This work is important, and I'm looking forward to forming an opinion on it. Maybe a future post! For those who are interested, this is what I'm aware of:

- Tim Ruffing proved that Taproot's commitment scheme was quantum-resilient: https://eprint.iacr.org/2025/1307

- Jonas Nick and Mikhail Kudinov have proposed SHRINCS: https://delvingbitcoin.org/t/shrincs-324-byte-stateful-post-... and SHRIMPS: https://x.com/n1ckler/status/2038695067754328095.

two things:

1) Short markets in Bitcoin don't have unlimited depth, and the centralized ones are KYC'd so there's some risk there 2) What if it doesn't tank the price? One thing people have suggested is just burning all the vulnerable coins[1]; it reduces supply so maybe the price will... go up? The point is there's uncertainty.

[1] https://x.com/lostbutlucky/status/2040878873731080681

This isn't a proposal for a US CBDC. It's research on technical tradeoffs that might need to be addressed in a hypothetical CBDC.

No. In serializable mode it simply appears that one thing is happening at a time. You can touch unrelated data concurrently with no performance impact.

serializability != one giant lock around your database.

concurrency and serializability go together great. it's only if transactions actually read/write or write/write the same data that they are done one at a time (and even that's not exactly true, depending on the concurrency control algorithms). MVCC often provides better performance because read-only transactions will not block writers.

and achieving serializability across database nodes is DEFINITELY NOT impossible.

re: materialized views -- you can kind of fake them in PostgreSQL by creating a view, populating it, and then defining triggers on insert, delete, and updates to your source tables.

This -- you have to realize there are two different versions of you. You1 is ambitious and smart and wants to do awesome things. You1 should think things through, actually plan things out, and write things down. At a detailed level!

You2 is super lazy and won't do anything even slightly difficult unless you make it really obvious and clear. You2 needs commit to following You1's plan; this requires discipline, but also a really easy-to-follow plan.

All the lecture notes will be put online, and you are welcome to clone the code and do the labs. If your code passes the tests reliably, you would have gotten full credit.

I don't think you could do this without actually solving the labs the way we wanted you to.

I'm the TA for the class. The first lab was intended to get students up to speed with go; the rest of the labs are significantly harder. That said, the labs are completely new, so we're not exactly sure how hard they will be for students. It's a process.

Challenging social norms just for the sake of challenging them is not something to be lauded.

You would be taken more seriously if you provided a well-reasoned response based on facts rather than throwing out opinions like "for every woman that really experiences sexism, there are two that exaggerate their circumstances".

You are setting up a simplistic straw man and arguing that because you believe you have "seen some very average women programmers get hired into high positions just to fill diversity quotas" (how do you KNOW this, btw?) that reverse-sexism is rampant. You do not acknowledge that your understanding of their promotions could be limited, that they might have other skills besides simply programming, or what the position actually required.

Because of these things it's very hard to take you seriously, and if you have a habit of doing these things, I understand why someone would dismiss you as a troll.

It would be more interesting if you argued in a reasoned matter acknowledging the variety of experiences in the real world, instead of drawing generalizations from a few things you have seen.

thanks for the attribution!

Which is why I limited my response to the situation at your company.

I could hypothesize on why you don't feel uncomfortable in the other situations you described, but really it's your own personal experience, and there's no reason to assume your feelings would generalize to everyone in that experience. I see the analogy you're trying to make, but I do not think it applies to women in technology, because there are a lot of other factors (stereotypes of computer scientists, the "brogramming" culture, the fact that you are going to classes in the US [I assume] not in the Phillipines, meaning you are still part of the dominant majority, etc).

The lower bound for women is essentially zero, especially when considered in the context of an entire career (i believe a women could conceivably only be away from work for six weeks). Do you really think six weeks accounts for the difference in pay, prestige, etc between men and women's careers?

Women do often end up taking much more time off, but it is absolutely not clear that has anything to do with "breasts and uteri". I would argue it's cultural.