Crippling DDoS vulnerability put the entire Bitcoin market at risk
thenextweb.com
thenextweb.com
Related, here's an unfixed btcd (Go Bitcoin client) DoS [2].
[1] https://bugs.chromium.org/p/oss-fuzz/issues/list?q=imagemagi...
The problem with Bitcoin is that any vulnerability can usually be exploited very easily for huge gains. You have a DDoS? Short BTC, run it, make millions. Remote code execution in the client? Steal funds, make millions. Easy and untraceable if you're careful. That's the whole drawback of the immutable ledger approach, if you get screwed the only solution is to convince everybody else to do a hardfork. If you're a bitcoin billionaire with relations in the big bitcoin shops you could get it to work, if you're a rando with a dozen bitcoins stolen from your account you're on your own.
Even something as bad as heartbleed seems almost benign in comparison since it's significantly harder to exploit, especially at a large scale.
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.
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.
So, I notice that a lot of people don't understand the motivation for this design decision. Here's a walk through:
• People interact with the blockchain. A person can notice when things happen at particular addresses (by e.g. looking on a website like Etherscan); and can then do arbitrary things in response.
• A person also can have an Ethereum wallet, containing private keys associated with addresses, allowing them to send {contract input, attached ether} messages from a given address.
• Put these two facts together, and you get a person who can observe an event occurring on (or off) the blockchain, and then respond by sending commands to an Ethereum node to submit a transaction coming "from" the address in the person's wallet. This person is functioning as an Ethereum "oracle."
• A bot can be an Ethereum oracle, just like a person can. The bot can listen to an Ethereum node (quite efficiently, through its API); and then, when it notices activity it cares about, can submit transactions back to the node through the same API. The bot oracle, like a human oracle, must have a wallet, because the transactions they submit must be "from" an address.
• Ethereum smart contracts, then, are just bot oracles that happen to be executed by Ethereum itself as a distributed system. The constraints of their execution substrate require these bots' programs to be deterministic when executed in different places at different times, which means they are limited to only looking at state that can't change (i.e. the blockchain); unlike other oracles, "smart contract" oracles can't interact with anything besides the blockchain. But in all other ways, they're interchangeable with a human or bot oracle.
• So, again, just like a human or a bot oracle, a smart-contract "oracle" must have a wallet, in order to have a private key with which to sign output messages to the blockchain. But, unlike a human or bot oracle, since they can only watch the blockchain, they must express their intent of what they want to watch. In the current implementation†, that means that they are limited to watching for messages incoming to their own private key's associated address. Putting those two facts together means that, in effect, a smart-contract oracle is mapped 1:1 to a particular address.
Ethereum doesn't namespace contract addresses from regular addresses, because contract addresses are regular addresses. Sending a message to a contract address (an address watched by a smart-contract oracle) is exactly the same as sending a message to an address watched by a bot oracle, or a human oracle. (In fact, if you distinguished them in any way, you'd probably break bot/human oracles, because they'd no longer be able to do everything smart-contract oracles can do, i.e. registering those special kinds of addresses for themselves.)
---
† If the system was built with slightly more consideration, I would imagine that—like the other kinds of oracle—smart-contract oracles could listen for messages sent to arbitrary addresses, rather than just their own; and maybe—like the other kinds of oracle—they would be able to have one or more associated addresses in their "wallet", rather than a single address. (It wouldn't make sense for them to have zero associated addresses in their wallet, though; then they wouldn't be able to do anything.)
First, smart contracts don't have a private key, at least not in the meaning of the word. They do the equivalent of signing by sending a message from their address to another address, or expose a function to indicate that a particular message is authorized by the contract code... but it's impossible to send some packet of data to a contract and (without external communication) have it verify "this data was provably sent by this contract"
Every other system I know of puts contract addresses in some other different namespace. Even looking at Bitcoin, they use the "3" address version for pay-to-scripthash, while "1" is for pay-to-pubkey. Internally Ethereum actually DOES namespace these two different address types implicitly. A normal address has no code and has a public key. A contract address has code and no public key. There are many many if-statements with this logic to handle the multitude of edge cases that come up from using the same address namespace for person-addresses and contracts... and beyond that, this has been the direct cause of several smart contract bugs because checking if a sender is person or contract is not trivial. Even for your purported benefit of being able to send coins to contracts in the same way as a person doesn't really work. You must attach some data when sending to a contract, whereas sending to a person should never contain data.
And for your idea of a contract having multiple addresses, what would be the purpose of this? Technically this is possible but not exposed today by making it so that an address contains both the location of a contract in the blockchain as well as encoding some data. Could be done simply by allowing an ethereum address to have more than 160 bits. The first 160 bits is contract address, the remaining is data to send to the contract.
I can understand Ethereum's design being not great. It was the first one to exist and the designers were not fully aware how it would be used.. but I will never understand the people that defend the design as "oh you just don't understand why this is a good thing"
That wasn't my intent at all. I don't think it's a good thing; I just think it's a predictable thing. I was trying to justify it like you'd justify the actions of someone with a mental illness, or like you'd justify an evolutionary adaptation. To "feel the flow of the causal process that resulted in this" (which isn't just the designers not being "fully aware of how it would be used.")
Most people, I find, who are put off by Ethereum's design, don't actively dislike the design; they just find it hard to understand the motivation for its design decisions, finding them obscure. That's what I was trying to help with, there.
It's perfectly okay to understand that motivation and then dislike Ethereum. I do too! (I haven't seen a genuinely good distributed-computation substrate yet, though. Have any recs?)
> There are many many if-statements with this logic to handle the multitude of edge cases that come up from using the same address namespace for person-addresses and contracts
Eh, that's more a fact of the implementations than the design, I think? You could theoretically treat every EVM CALL op as always executing bytecode, with regular addresses being wrapped in an ADT that, when asked for their bytecode, returns a zero-length string; and an EVM interpreter that, when asked to execute a zero-length bytecode string, does so successfully at a cost of zero gas. IIRC, there's nothing in the yellowpaper constraining them from writing the code this way. Whoever wrote the code is just a bunch of mooks who don't understand data-primacy and eliminating (cyclomatic) complexity.
> because checking if a sender is person or contract is not trivial
I'm not too familiar with what is and isn't exposed in Solidity, but at the EVM level, isn't that just 𝑒 ("the present depth of the message-call/contract-creation stack")? If 𝑒=0, a human (or a human/bot oracle) called you; if 𝑒>0, another contract called you.
> And for your idea of a contract having multiple addresses, what would be the purpose of this?
There really isn't a legitimate purpose in a contract having access to multiple [pretend-]signing identities, given that you can always construct a system of contracts that message one-another to accomplish the same task.
The point of my thought was to achieve parity between smart-contract oracles and human/bot oracles, insofar as human/bot oracles can sit there and do things in response to anything happening on the blockchain they're watching, not just something happening to an address they own. Theoretically, contracts could be allowed to subscribe to any log event stream that a node can subscribe to, such that, after any 𝑒=0 call which generated logs successfully returns, the EVM would then be required to run all contracts with active subscriptions that match the logs just written into a transaction receipt, with those contracts paying the gas out of their own accounts to run.
In a healthy market, assets that do not deliver on their most basic premise should trade down to zero eventually.
In theory, the value of a stock is the discounted value of all future cash flows, on the premise that all profits (in excess of debt servicing etc.) belong to the shareholders, and they have a legal claim on that cash.
In practice, have you ever known a company who, at the top of their product cycle, says "Welp, we got no idea what we could possibly spend all this money on that has a positive ROI in excess of what you could get elsewhere in the market, so here's your dividend, we'll keep raking in the cash for you as long people want to buy our products, and then we'll liquidate and return the cash to our equity holders"? Usually the death throes of a company involve them hiring a series of excessively overpriced turnaround CEOs, firing them with multi-million-$ severance packages, acquiring promising startups for lots of equity which they end up killing, and paying a large and disengaged workforce to search for other jobs.
They do eventually trade down to zero eventually, which proves your point, but the conclusion one could draw is that every individual stock is actually an asset bubble. They rarely, if ever, end up returning the company's profits to shareholders, but shareholders who exit when it looks like there will be a lot of profits in the future can make a lot of money at the expense of the shareholders they sell to.
Usually, if one person gets screwed (by no fault of their own), that means everyone else could also get screwed the same way, so it's not that hard to convince people to hard-fork.
https://github.com/bitcoin/bitcoin/pull/14249/files
checkTransaction is defined in verify.cpp:
https://github.com/bitcoin/bitcoin/blob/master/src/consensus...
The last argument, fCheckDuplicateInputs, causes inputs to be checked for duplicates. A comment inside this method notes:
// Check for duplicate inputs - note that this check is slow so we skip it in CheckBlock
To summarize, the fix appears to replace the faster call to checkTransaction in CheckBlock with the slower version that checks for duplicate inputs in each transaction of a new block. What's not clear to me yet is how failure to check for duplicate inputs in a block's transactions leads to DoS.
Many consider Bitcoin Core to define the Bitcoin protocol. If this is true, then the new release can be considered a soft fork update.
Previously, blocks containing transactions with duplicate inputs would have been considered valid. Now, such a block will be rejected by patched nodes.
This case is an excellent example of how difficult it is to determine what exactly the Bitcoin protocol actually requires.
We only gradually "discover" the protocol by exhaustively following every branch of the Bitcoin Core code base.
No, they would have crashed the node, they would not have been accepted as valid. This is not a soft fork.
A softfork is a change to the bitcoin protocol wherein only previously valid blocks/transactions are made invalid. ...
https://en.bitcoin.it/wiki/Softfork
It's not clear to me yet under what conditions a node would crash. With a single duplicate input? With dozens of duplicate inputs? Duplicate inputs spending segwit outputs?
If some duplicate inputs would have been permitted without crashing nodes then the update appears to fit the definition of soft fork.
edit: also, it appears the DoS vuln doesn't apply to pre-0.14 nodes. Either those nodes would have rejected dup-input blocks (making 0.14 a hard fork?) or the update just released could be seen as a soft fork.
If this were the case it would be a complete failure of the system, rather than a DoS.
Therefore fixing the crash is not a "soft fork* because nothing was accepted in the first place.
Yes, if it actually accepted the duplicate input, that would cause unlimited inflation, which is obviously a huge deal.
Or in other words. We got extremely lucky.
Do you have a source for where this was written up, or did you come up with this on your own?
I just want to be able to reference back to this in the future. So whenever you decide to publish, I'd love to check it out!
But I'd encourage you to do a bit more investigation.
According to Bitcoin core, there is an inflation vulnerability.
https://bitcoincore.org/en/2018/09/20/notice/
So maybe you weren't too far off from independently discovering the vulnerability yourself.
Edit: apparently you were credited in discovering the vulnerability yourself in the very discloser that I linked.
Congrats!
My comment was an early disclosure before I fully understood how sensitive the details were. Even without going into detail or providing any code it was very irresponsible of me to off hand just mention that possibility. It didn't click how sensitive things were until a bitcoin core dev confirmed it. Sorry anyone who sees this. I merely reported the exploit, David Jaenson is our genius security researcher that definitely should deserve all credit.
A state-actoru, could certainly burn that, and much more.
Some exchanges would probably have gone offline for a few hours.
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.
This flaw alone isn't likely enable such an attack. Furthermore, most nodes will upgrade very quickly, greatly reducing the attack surface.
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.
Someone else in the thread pointed out that there is a way to get around the crashing node assert check, and instead create infinite inflation.
The bug is significantly more network destroying than what was previously thought, if this claim is true.
As such invalid blocks need to be mined anyway, only those willing to disregard block reward of 12.5BTC ($80,000) could actually do any real damage.
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.
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).
Then it would be a total cost of ~$160k with the loss of potential revenue.
It's Bitcoin Cash.
https://medium.com/@jonaldfyookball/why-some-people-call-bit...
> While this certainly seems unlikely (barring any digital Tyler Durden-types wanting to destroy something beautiful), it does raise eyebrows. The great defence of Bitcoin is that it’s far too decentralized to be brought down by any single entity.
Generic turmoil of the platform could panic selling. $80K to cause mass disruption could pay off considerably for someone shorting either bitcoin or an altcoin.
The most notable is Ethereum, with the DAO hack and the subsequent bailout. Did lead to Ethereum Classic, which is a fork that gained some traction.
The traditional markets attempt to assign a value to the expected future value of all (public) companies. As technology advances, goods and services can be produced and delivered more efficiently, allowing $1 to buy more. Investing in the stock market is using your money to drive the improvements, and selling your stock is reaping those rewards.
Bitcoin is just a list of financial transactions that a couple of different computers agreed on the order of.
I don't see how they are comparable.