> Additionally, we identified 13,319 Ethereum that was transferred to either invalid destination addresses

There is no such thing as an invalid Ethereum address.

Separately, what the researchers seem to miss is that the majority of these funds were stolen due to a far more traditional software exploit: the Go Ethereum client (geth) has a JSON-RPC interface. If the user:

  - enables the interface (it's disabled by default)
  - listening on a public address (it defaults to 127.0.0.1)
  - and unlocks their wallet (they are locked by default)

then anyone can send a request to the interface to sign a transaction transferring all funds in the account to another address.

If anyone cares enough, it's easy to set up an instance of geth with the first two conditions met and watch the transfer attempts coming in.

I don't follow your argument here - why would a thief, on finding an exploitable instance of Geth, transfer its funds to an address derived from a weak private key? Is that the only way this exploit works?

The thief would transfer it to an address of their choosing, which wouldn't have a guessable private key (and obviously be known by the thief).

That is what I thought, but in this case, the ether that are presumed to have been stolen are those that have shown up at addresses with weak keys and then moved to another address (one without a guessable key), often as soon as they show up at the first address. The authors tested this hypothesis by moving a dollar's worth of ether to one of these addresses, and it was immediately stolen from them. I do not see how one could conclude that these presumably-stolen coins were stolen through the Geth exploit.

> The Ethereum address 0x0000000000000000000000000000000000000000 (EthAddrNull) has had Ethereum erroneously transferred to it. It is all but certain that this was due to user or code error where a null destination address was provided.

True if the transfers were from external addresses, but transfers from contracts were likely intentional. Transferring to 0x0 is the standard way to burn ETH, and there are all sorts of reasons to do it, like destroying a bond as a penalty.

Some of the others were well-known issues in older clients, though I'm a bit surprised to see it's still happening. And of course brain wallets have been known to be vulnerable since early Bitcoin days.

why would anyone ever burns bond money as a penalty?

Bonds enforce good behavior. Sometimes you can send the bond money to whoever caught you behaving badly, but other times that's exploitable, so you just burn the money instead.

Things like this come up a lot in layer-2 scaling solutions, for example. It also plays a central role in proof of stake, though that's not live on Ethereum yet.

I don't have a good specific example handy, though.

> other times that's exploitable, so you just burn the money instead

I definitely see reasons to not pay a counterparty; a swear jar is a one-sided incentive to not swear, where paying the other people present would reward them for tricking you into swearing.

The usual solution to this sort of issue is just donating the money, though. (For instance, productivity apps that hold money in escrow and donate it if you fail to complete tasks.) Is "donating to charity with Ethereum bonds" just too obscure to bother with at the moment, or is there a structural reason the bonds need to specifically be burned?

Donating to a particular charity address is definitely a possibility. The tradeoff is that you're requiring users to trust the people running that charity, if there's an exploit that's damaging enough to be a concern. People also figure that by reducing the supply of ETH you're increasing increasing its price, so it's more of a global compensation to ETH holders than a net loss.

However, charitable donations aren't unknown. The ENS name registry, for example, is planning to require annual rents like DNS, and contribute the money to public goods (e.g. with grants to projects improving the ecosystem).