jschlatter

> We originally built Claude Code on Ink, a React renderer for the terminal. [...] Over the past few months, we've rewritten our rendering system from scratch (while still using React).

They have less control than you may think.

Any ethereum miners (or proof-of-stake validators) who block some class of transactions immediately become vulnerable to denial of service attacks.

This came up back in 2016 with the DAO hack on ethereum[1]. Some ethereum miners considered blocking transactions that moved the stolen funds, but then realized that this was infeasible: if you block such transactions, then the DAO hacker can spam you with them. Such spam on ethereum is usually prevented by requiring the sender to spend money on each transaction (ie pay gas fees). But that fee is only charged when the transaction is included in a block -- if you refuse to include it, then the spammer pays nothing. The kicker is that, by Rice's theorem, there is no way in general to distinguish "malicious" transactions from non-malicious ones (for _any_ definition of "malicious") short of just executing them to see what they do.

So if you as an ethereum miner (or validator) try to block certain transactions, you can be forced to do unbounded amounts of work for free, ie DoS'd.

I was encouraged today to discover that youtube has a report history page that lets you know the outcome of your reports. Most of the videos I've reported have been removed, including most of the ones I've reported in the last 12 hours. So at least _something_ is being done about them, even though the current effort is not sufficient against the unending inflow of new scam videos.

  >>> pause all
  All goroutines paused
  >>> show goroutines
  1: foo.go:16
  2: foo.go:24
  3. bar.go:10 [current]
  >>> next
  -> // some code from goroutine 3
  >>> goroutine 2
  Now tracing goroutine 2. Current location:
  /*
     Code listing from goroutine 2's current location
  */
  >>> next
  -> // some code from goroutine 2

Two cases I have thought of are stack traces and logging that inspects the stack. In the former case, if you get a stack trace while debugging it will not mean much because the lines do not match those of your code. In the latter case, logging statements may print the wrong things if they depend on being called a certain number of stack frames below user code. glog does this, for example[1]. I don't have solutions to either case yet, but I have some ideas of how to start. I think the utility the tool provides is well worth those two issues, and I'm hopeful that both can be fixed.