CVE-2018-17144

Yeah. I'd rather you hadn't done that personally.

> If some duplicate inputs would have been permitted without crashing nodes then the update appears to fit the definition of soft fork.

If this were the case it would be a complete failure of the system, rather than a DoS.

> Previously, blocks containing transactions with duplicate inputs would have been considered valid. Now, such a block will be rejected by patched nodes.

No, they would have crashed the node, they would not have been accepted as valid. This is not a soft fork.

> The cost of the attack would far exceed ~80k USD in bitcoin block rewards because it requires a substantial amount of hashing power to have a realistic chance of successfully producing a block that reaches consensus and is added to the canonical chain.

No, the cost is simply $80k on average to find a block, or around $5k for BCash. If the cost to produce a block exceeded its value substantially, it would be on a whole unprofitable for Bitcoin miners to continue existing at this point in time (network difficulty, bitcoin price).

I agree, essentially. It's actually fascinating how broken something can be and have multi million dollar a day trading volume. It shows a complete disconnect between what exists (the network), and what is being marketed (the product, the dream, the market).

You can walk the network and crash all nodes with listening sockets, this ruins pretty much everything. There's some non-public infrastructure that would perhaps make mining continue, but non-listening nodes can't exist without sockets, and neither can SPV nodes.

The ethereum network has substantial issues stemming from very poorly defined consensus rules, which manage to grow in complexity every time you look away. The sheer scale of the consensus critical code makes it review resistant. I've been in the room with proficient auditors and struggled to make heads or tails of exactly what some forms of the code are doing.

The scripting languages people use being compiled down into a very strange bytecode complicates matters even worse. The underlying type of the VM being 256 bit has caused the compilers to do heavy amounts of bit packing for efficiency, which makes reasoning about their behavior substantially harder than it should be. It's a struggle to call any of this system well designed with a straight face.

To all of this, I have sat with developers in exchanges who are at a complete loss how to deal with the poor RPC interfaces given. Simple tasks like receiving money as deposits from clients have a never ending stream of edge cases due to contracts and addresses being in the same name space, dealing with combining inputs using multiple transactions with some confirming and some not (leading to partial withdraws, or partial deposits), sequence number behavior driving everybody insane.

I can't speak to the hype around "building on ethereum" as I've never been a part of that, but on a basic level the tools presented are unusable, regardless of what language the client you have chosen to use are written in. The RPC interface in Bitcoin is at least straight forward, with primitives that largely make sense. It's not without fault and some things require kludges or result in head scratching, but it's not as crazy as Ethereum's.

> This article is wrong and plain ol' fearmongering. A coordinated denial of service on network nodes is theoretical at best, as it would require a series of further, orchestrated actions on the rest of the blocks to achieve it.

This requires no action other than pushing a specific binary to an unpatched node in order for it to crash.

The cost of producing the binary is one time, approximately $80k USD depending on luck.

> Nobody would have lost any money or bitcoins.

That's not entirely true. The current crop of Lightning Network nodes rely on their host being up for the safety of their channels. If their node is not contactable for more than 24 hours they risk having their money stolen.

Large changes in the network graph has been shown in Bitcoin to take quite a while to sort out, due to the way the rumoring network attempts to find stable and reliable peers. This is still a substantial problem now, as there's only a few thousand listening peers that can accept incoming connections out of over 10,000 total. If only those nodes were remaining online there would be substantially reduced capacity to relay blocks and transactions for a period.

Bitcoin Core has, from day one, been a remarkably safe code base generally speaking. The protocol is free (or used to be) of any string manipulation or other behavior that often leads to code execution. Many major issue causing features were added after the departure of Satoshi, and are generally considered to be mistakes for other reasons (BIP70 introduced a dependency on OpenSSL for the GUI wallet, which is being deprecated and is now a compile time option). For the most part any issues in the original code are to do with consensus level understanding of how the system operated, which is to be expected given that the entire construction was novel at the time of its creation. People often repeat a mantra that the Satoshi code was bad, when it was surprisingly problem free given the enormous amount it accomplishes.

I personally pondered if this particular issue would have any market effects and concluded that it would not substantially. This is based on fact that there's altcoins in existence with > 800 day consensus level failures disclosed privately, or publicly known, which still have reasonably active trading. Some altcoins manage to exist with almost no operational network at all, just a pool, a node or two run by the creator, and an exchange with substantial internal volume and not a lot else.

For altcoins in particular it's difficult to actually know if this is representative of what would happen in Bitcoin, some of the issues I'm aware of in altcoins simply haven't been exploited because there's not enough profit in it at the moment, even though the design decisions in these altcoins (eg, facets of proof of stake) are then used to justify the safety of other systems.

> Do the blocks need to be mined twice? Or do you just have to submit a garbage block for the second one?

No. One transaction included twice in a single block.