6 ms·

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 be

by CVE-2018-17144 8y ago

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_clarence 8y ago
For what is worth, Ethereum main clients are developed in Go and Rust, their security stance is even more impressive imo.
- CVE-2018-17144 8y ago
  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.
  - woah 8y ago
    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.
  - derefr 8y ago
    > 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.)
- jacquesm 8y ago
  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.
village-idiot 8y ago
Personally I believe that those altcoins trading despite serious consensus issues is a sign that we’re in an asset bubble of some sorts. In a healthy market, assets that do not deliver on their most basic premise should trade down to zero eventually.
- CVE-2018-17144 8y ago
  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).
- nostrademons 8y ago
  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.
  - village-idiot 8y ago
    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_clarence 8y ago

For what is worth, Ethereum main clients are developed in Go and Rust, their security stance is even more impressive imo.

CVE-2018-17144 8y ago
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.
- woah 8y ago
  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.
- derefr 8y ago
  > 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.)
jacquesm 8y ago
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.

village-idiot 8y ago

Personally I believe that those altcoins trading despite serious consensus issues is a sign that we’re in an asset bubble of some sorts. In a healthy market, assets that do not deliver on their most basic premise should trade down to zero eventually.

CVE-2018-17144 8y ago
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).
nostrademons 8y ago
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.
- village-idiot 8y ago
  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.