
The Ethereum network is currently undergoing a DoS attack - jrbedard
https://blog.ethereum.org/2016/09/22/ethereum-network-currently-undergoing-dos-attack/
======
fragsworth
My understanding is it works like this in Ethereum:

The miners can run any arbitrary code ("a contract") that you write, and this
code is verifiable and trusted by everyone once it's been uploaded to the
blockchain. The contracts can read/write arbitrary things in the blockchain
and send coins to anyone you want, determined by the code you write.

There's a "gas price" that you have to pay for each operation you tell the
miners to execute. However, the operation "EXTCODESIZE" evidently has too low
of a cost, allowing someone to pay to have it executed enough times to
noticeably slow the miners down for shits and giggles.

Someone correct me if I'm wrong?

~~~
zorked
Is there another angle? E.g. can the attacker have precomputed the results of
those operations and now he can mine faster than anybody else or something
like that?

~~~
valarauca1
Yes you can game the network by writing your own Ethereum Mining Client.
Introducing a ton of code. Selectively ignoring code. BUT this isn't smart.
You are devaluing the currency you are deriving profit hurting your profit
margin.

Furthermore you need to maintain plausible deniability. THIS IS HARD. If
Ethereum catches you, they'll just hard fork. So your average blocked claims
can't change by a large amount. So in reality you already need to 1st/2nd
sigma miner, then increase your profits by maybe 20-30%. This is a lot of
risk, and a ton of work.

Most likely it is just somebody doing it for the lulz

~~~
deegles
I'm disappointed that the devs established the precedent that if things go
south they'll hard-fork. It reduces the incentive to avoid risky behavior.
Having a centralized roll-back/bailout authority is what led to too-big-to-
fail banks.

------
Animats
Etherium is a first cut at a hard problem. The "smart contracts" problem is
interesting, but after the DAO debacle, it's clear that smart contracts
shouldn't be executable programs. It's too hard to predict their behavior, and
that's very bad when they're connected directly to money. Some human-readable
declarative notation is needed. I've suggested decision tables. Dealers need
enough expressive power to handle all the usual financial instruments, but
don't need or want Turing completeness.

Another advantage of a declarative notation is that compute time tends to be
bounded by a fairly low bound. That would put a lid on problems like this new
one, where the little programs are chewing up too much time.

We may see some smart contracts system with a better notation in the
derivatives business. It doesn't need to be a currency, just a blockchain with
enough identified independent players to prevent tampering. The need for
"mining" comes from the desire for anonymity; it's not inherent in smart
contracts.

------
ForHackernews
Isn't this the kind of thing that a decentralized network should be resilient
against? Maybe I just don't understand blockchains.

~~~
Karellen
From the article:

> miners and nodes need to spend a very long time processing some blocks. This
> is due to the EXTCODESIZE opcode, which has a fairly low gasprice but which
> requires nodes to read state information from disk;

AIUI, the data in the blockchain isn't just "data". It's actually small bits
of code that execute inside a VM, which each node needs to execute in order to
"understand" the blockchain. "EXTCODESIZE" would be one of the instructions in
this particular VM.

I think that most blockchains either have a complexity limit per
record/transaction, or have a complexity "cost", so that complex code is more
costly to insert into the blockchain.

However, in this case, it sounds like someone has figured out how to insert
some code that is actually more complex than the complexity-measuring code
thinks it is, and is therefore causing all miners (all users?) to perform
higher-than-expected amounts of computation to parse the blockchain, to the
point where they can't keep up with the network.

(Corrections welcome)

~~~
RexetBlell
The transactions are verified by all full nodes (which are basically all
users).

------
pmarreck
Trial by fire, I see...

------
soared
Who benefits from this?

~~~
themoon
The crypto-community is a pie whose size isn't changing much. Coin prices
fluctuate as investors move money from one coin to another, which causes price
fluctuations. Attacks like this one which make ethereum look bad are
beneficial to those other coins, who will expect prices to rise as a result of
people selling their ETH out of fear.

~~~
bfuller
And in the end, after the whale makes his profit in btc, he will probably
reinvest in eth because it is low, gaining a larger stake in an already
fragile economy, and will be able to exert more influence next time he tries
to move the market.

------
godzillabrennus
I wonder if this is related to what is going on with the folks at
[http://www.foundups.com](http://www.foundups.com) claiming they invented ETC
and are hosting their own conference around their own protocol.

------
cryptarch
Could individual miners change the cost they charge for individual opcodes, or
perhaps even disable specific opcodes alltogether?

~~~
RexetBlell
The developers were thinking of doing this at the beginning but decided
against it.

Currently, when you send a transaction, the transaction includes a gas price
that you are willing to pay for a unit of gas. The miners then decide if they
want to mine your transaction, or not. Each opcode in the Ethereum Virtual
Machine requires a different amount of gas, which is hard coded (look at this
spreadsheet:
[https://docs.google.com/spreadsheets/d/1m89CVujrQe5LAFJ8-YAU...](https://docs.google.com/spreadsheets/d/1m89CVujrQe5LAFJ8-YAUCcNK950dUzMQPMJBxRtGCqs/edit#gid=0)
the opcode that is causing trouble today is EXTCODESIZE which has a gas cost
of 20, which is apparently too low).

Initially, there were ideas where you could specify in the transaction the gas
price you are willing to pay for each opcode. But this would make transactions
very large (in terms of bytes).

