> The bug relates to its consensus code. It meant that some miners had the option to send transaction data twice, causing the Bitcoin network to crash when attempting to validate them.
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?
I spend a lot of time looking for bugs in cryptocurrency code. In spite of this finding, I'd say that Bitcoin Core is among the safest cryptocurrency applications. The average random C/C++ open source project suffers from far more potential issues, for example [1].
Related, here's an unfixed btcd (Go Bitcoin client) DoS [2].
You may be right about the relative security of Bitcoin (given that it's the oldest and one of the most audited codebases while also missing some of the more complex and potentially problematic features of other cryptocurrencies it seems like a reasonable assumption) however I'm not sure if it makes a lot of sense to compare it with other "random" open source projects.
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.
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.
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.
Bitcoin is not capable of running any complex code, so it’s not a good comparison. However, the issues you point out are definitely problems in ethereum. What ethereum has is a community of enthusiastic developers constantly discussing and programming on the platform despite its flaws. It’s like the JavaScript of cryptocurrency.
> a never ending stream of edge cases due to contracts and addresses being in the same name space
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.)
As a hater of the EVM and person directly trying to replace this shit, here is my rebuttal:
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"
> 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.
Security is rarely - if ever - purely determined by the languages in which a particular code base is created. Though it can have a positive effect if the right language is picked for a good reason.
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).
This is an interesting premise when applied to the stock market.
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.
One could make the argument that a dying company is just a very slow and inefficient exit scam, and that the shadiest of ICOs have just made the process much more efficient.
The points you mentioned is also why such vulnerabilities are relatively rare. BTC has a inbuilt bug bounty and no one has to even run it (although some one has to fix the bugs) :)
> 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.
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.
For your second, link, the PoC example there by passes the regular strict signature encoding checks. These are on by default, with some being policy, and some being consensus. As a result, this won't be hit in practice by regular nodes, but may be hit by developers using the library for other purposes: https://github.com/btcsuite/btcd/issues/1287#issuecomment-42...
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.
It also isn't entirely true the entire network is/was at risk. Not all nodes connect to all other nodes. So a malicious actor would have to waste the money and only bring down the nodes directly connected. Most nodes today aren't accepting new connections. Also it only affects full nodes not SPV. I think the best attack vector would be to crash competing nodes but remember they have to spend a block reward to do so and all they get in reward is a block reward. The miners have enlightened self interest to not do so. I think the risk has been blown out of proportion but they are being smart and showing an abundance of caution to make sure this does allow for use case they aren't considering or some other cascading failure.
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.
We're witnessing the maturation of crypto as these kinds of resolutions only make it stronger. It's going to be used as a flight-to-quality asset class after the traditional markets crack in a few months.
1. They always do. 2. We've been in the longest bull market in history 3. Black Swans exists 4. The 'message of the markets' in this case, the yield curve along with a few other related reliable predictors: https://fred.stlouisfed.org/series/T10Y3MM
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.
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 flaw alone isn't likely enable such an attack. Furthermore, most nodes will upgrade very quickly, greatly reducing the attack surface.
> 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.
Wouldn't the cost be significantly higher than $80k since the miner would have to keep his machines on for quite some time at a loss in order to mine a full 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.
> 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).
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.
> 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.
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.
There appears to be a workaround to bypass the assert check in Bitcoin Core 0.16 that allows one to mint new coins by using an input multiple times and it be accepted by the network without crashing. Probably will be waiting until the dust settles on this before publishing that test case though, since it's clearly much more severe than a DoS
Actually it only seems to be a side effect of our test environment. Using a more realistic environment makes it not effective, sorry for the false alarm
The credit is currently wrong, it should belong to one of the developers on my team, David Jaenson.
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.
Isn't the proof-of-work algorithm itself a DDoS? PoW requires all nodes in the network to see a consistent state of a transaction for it to be correct. By definition this violates the CAP theorem.
> 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.
> 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.
This has happened with other, much smaller, cryptocurrencies. The choice usually agreed upon by exchanges, developers, and community is to pick a known good block before the attack and fork the chain backwards from that point. It requires significant downtime and is of course very complicated, but several different cryptocurrencies have used this method and recovered to a functioning blockchain
Are these bitcoin exchanges just a gigantic implimentation of a pyramid scheme. I mean where is the added value coming from? Are they similar to “over unity” machines in physics?
62 comments
[ 0.24 ms ] story [ 136 ms ] threadAs 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.
Related, here's an unfixed btcd (Go Bitcoin client) DoS [2].
[1] https://bugs.chromium.org/p/oss-fuzz/issues/list?q=imagemagi...
[2] https://github.com/btcsuite/btcd/issues/1287
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.
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.
A state-actoru, could certainly burn that, and much more.
[1] https://www.bitcoinblockhalf.com/
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.
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.
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...
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.
> 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.