4 ms·

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 applicatio

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]. [1] https://bugs.chromium.org/p/oss-fuzz/issues/list?q=imagemagick https://bugs.chromium.org/p/oss-fuzz/issues/list?q=imagemagi... [2] https://github.com/btcsuite/btcd/issues/1287 https://github.com/btcsuite/btcd/issues/1287

simias 8y ago
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.
- 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.
- option_greek 8y ago
  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) :)
- derefr 8y ago
  > 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.
roasbeef 8y ago
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-423384745 https://github.com/btcsuite/btcd/issues/1287#issuecomment-42...

simias 8y ago

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.

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.
option_greek 8y ago
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) :)
derefr 8y ago
> 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.

roasbeef 8y ago

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-423384745 https://github.com/btcsuite/btcd/issues/1287#issuecomment-42...