4 ms·

" Many of these details do not appear in any speciﬁcations and were obtained by a careful analysis of the corresponding source code. This is especially true for

" Many of these details do not appear in any speciﬁcations and were obtained by a careful analysis of the corresponding source code. This is especially true for Bitcoin for which there exists no ofﬁcial documentation except for the original white paper [14] and Bitcoin Wiki[3]." Well that seems a bit odd.

patio11 12y ago
You have no idea how deep that rabbit hole goes. Bitcoin Core is referred to as a "reference implementation", which means "you should implement all bugs referenced by Bitcoin Core in transaction verification, or you have your choice of being kicked off the Bitcoin consensus immediately, which is bad, or at any point of an attacker's choosing, which is catastrophic."
- resolutionx 12y ago
  What a wonderful idea. /s Although I understand it to an extent. The core of software wouldn't be the core if it wasn't always used.
- 3pt14159 12y ago
  That's the way a blockchain works though. If there is a bug in the client that 99% of people use then of course you'll have forking blockchains. And all of this matters less anyway, because clients can fallback to blockchain.info if there is a fork detected, and just warn the user that the client may have a bug.
  - kanzure 12y ago
    > because clients can fallback to blockchain.info if there is a fork detected Unfortunately bc.i's implementation/instance is not immune to bugs, forking, lying or collusion. I don't know why you would expect it to be.
    - 3pt14159 12y ago
      The point is that it is a trusted enough party. If the client gets a suspicious block it can check against that party as a way of seeing if the client itself may have a bug.
  - psykovsky 12y ago
    The bitcoin client has a fallback to blockchain.info when it detects a fork? What? I'm not sure I understand what you're saying.
    - 3pt14159 12y ago
      A client, not, The client. Say you were writing a client in a different language or for another platform.
      - psykovsky 12y ago
        Saying I was writing a bitcoin client I would never use some 3rd party as a fallback. As soon as a blockchain fork is detected you stop all transactions and wait for it to be solved by the miners. No other way around it.
- kens 12y ago
  In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable. https://en.bitcoin.it/wiki/CVE-2010-5139 https://en.bitcoin.it/wiki/CVE-2010-5139 Another interesting case is when bitcoind 0.8 changed the underlying database from BerkeleyDB to LevelDB. Due to different database lock limits, bitcoind 0.7 couldn't process a block that bitcoind 0.8 could. For 6 hours, there was a fork where old clients were using a totally different blockchain than new clients, because of this single block they couldn't handle. This is what patio11 means, that you have to be bug-for-bug compatible with the reference implementation. http://bitcoinmagazine.com/3668/bitcoin-network-shaken-by-blockchain-fork/ http://bitcoinmagazine.com/3668/bitcoin-network-shaken-by-bl...
  - jerguismi 12y ago
    > In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable. That was in 2010. Most of the users take certain level of risk, also different kinds of people have different risk appetite. If you really think this is still a relevant risk, then probably you shouldn't use cryptocurrencies at all. Stay with the safe and proven almighty dollar.
- derefr 12y ago
  The right mindset to understand the requirements of Bitcoin client design is, I think, that of someone trying to clone an online game client (e.g. Starcraft) in a way that doesn't experience network state desynchronization. You can do whatever you like in your client UI-wise, but the "rules engine" of your implementation absolutely must reduce an incoming event stream into the same world state as the reference implementation. For this kind of problem, the easiest solution (when possible) is to extract the "rules engine" component of the reference implementation into a library, and then have every other client just use it (and maybe contribute to its development) instead of trying to write something bug-for-bug compatible with it. When you think about it, web browser rendering has much the same implementation-consensus problems as Bitcoin. And what do we see there? Everyone sort of converging toward just using the "rules engine" known as WebKit.
kanzure 12y ago
> Well that seems a bit odd. Everything known about Bitcoin comes from people directly reading the source code. That's all that was originally released next to the paper. Everything since then has been based on careful review of the source code and writing additional documentation from that understanding. Edit: the documentation (that your reply is referring to) exists now because people spent the time reading the source code. This documentation didn't exist originally.
- resolutionx 12y ago
  The part that seems odd to me is that with all these developers, students, researchers, and curious users nobody documented it according to the paper. Which as stated by another user doesn't seem to be the case.
  - mannykannot 12y ago
    Documentation produced that way is actually consistent with the statement you first quoted. I think what is happening here is that the researchers, being properly careful, verified what the software does, rather than trust to descriptions by others. If there had been a formal specification, I imagine they would have both analyzed the specification for vulnerabilities, and checked the code for correct implementation.
eric_bullington 12y ago
I'm not sure when they wrote this paper, but this is no longer true. There's some very nice official developer documentation up at: https://bitcoin.org/en/developer-documentation https://bitcoin.org/en/developer-documentation Also, the Bitcoin Wiki itself is a fairly comprehensive source of documentation (and covers most of the information in the "official" documentation). It even includes an informal protocol specification[1]. It's been around for a very long time. That said, the information they're referring to is Bitcoin's Tor support (like recognizing OnionCat addresses). I don't think there is much documentation on this specific topic. However, Bitcoin is an open source project and I'm sure any related documentation contributions would be welcome. 1. https://en.bitcoin.it/wiki/Protocol_specification https://en.bitcoin.it/wiki/Protocol_specification
- resolutionx 12y ago
  According to the site it was submitted Oct 22, 2014. So yesterday. It's still an interesting read and I'm sure it holds validity but this bothered me.

patio11 12y ago

You have no idea how deep that rabbit hole goes. Bitcoin Core is referred to as a "reference implementation", which means "you should implement all bugs referenced by Bitcoin Core in transaction verification, or you have your choice of being kicked off the Bitcoin consensus immediately, which is bad, or at any point of an attacker's choosing, which is catastrophic."

resolutionx 12y ago
What a wonderful idea. /s Although I understand it to an extent. The core of software wouldn't be the core if it wasn't always used.
3pt14159 12y ago
That's the way a blockchain works though. If there is a bug in the client that 99% of people use then of course you'll have forking blockchains. And all of this matters less anyway, because clients can fallback to blockchain.info if there is a fork detected, and just warn the user that the client may have a bug.
- kanzure 12y ago
  > because clients can fallback to blockchain.info if there is a fork detected Unfortunately bc.i's implementation/instance is not immune to bugs, forking, lying or collusion. I don't know why you would expect it to be.
  - 3pt14159 12y ago
    The point is that it is a trusted enough party. If the client gets a suspicious block it can check against that party as a way of seeing if the client itself may have a bug.
- psykovsky 12y ago
  The bitcoin client has a fallback to blockchain.info when it detects a fork? What? I'm not sure I understand what you're saying.
  - 3pt14159 12y ago
    A client, not, The client. Say you were writing a client in a different language or for another platform.
    - psykovsky 12y ago
      Saying I was writing a bitcoin client I would never use some 3rd party as a fallback. As soon as a blockchain fork is detected you stop all transactions and wait for it to be solved by the miners. No other way around it.
kens 12y ago
In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable. https://en.bitcoin.it/wiki/CVE-2010-5139 https://en.bitcoin.it/wiki/CVE-2010-5139 Another interesting case is when bitcoind 0.8 changed the underlying database from BerkeleyDB to LevelDB. Due to different database lock limits, bitcoind 0.7 couldn't process a block that bitcoind 0.8 could. For 6 hours, there was a fork where old clients were using a totally different blockchain than new clients, because of this single block they couldn't handle. This is what patio11 means, that you have to be bug-for-bug compatible with the reference implementation. http://bitcoinmagazine.com/3668/bitcoin-network-shaken-by-blockchain-fork/ http://bitcoinmagazine.com/3668/bitcoin-network-shaken-by-bl...
- jerguismi 12y ago
  > In case you think that's theoretical, a bug with integer overflow let an attacker creating 184 billion bitcoins out of thin air. To fix this, a new implementation was pushed out, which ended orphaning more than 8 hours of transactions. In other words, even after 8 hours you can't be certain that Bitcoin transactions are durable. That was in 2010. Most of the users take certain level of risk, also different kinds of people have different risk appetite. If you really think this is still a relevant risk, then probably you shouldn't use cryptocurrencies at all. Stay with the safe and proven almighty dollar.
derefr 12y ago
The right mindset to understand the requirements of Bitcoin client design is, I think, that of someone trying to clone an online game client (e.g. Starcraft) in a way that doesn't experience network state desynchronization. You can do whatever you like in your client UI-wise, but the "rules engine" of your implementation absolutely must reduce an incoming event stream into the same world state as the reference implementation. For this kind of problem, the easiest solution (when possible) is to extract the "rules engine" component of the reference implementation into a library, and then have every other client just use it (and maybe contribute to its development) instead of trying to write something bug-for-bug compatible with it. When you think about it, web browser rendering has much the same implementation-consensus problems as Bitcoin. And what do we see there? Everyone sort of converging toward just using the "rules engine" known as WebKit.

kanzure 12y ago

> Well that seems a bit odd. Everything known about Bitcoin comes from people directly reading the source code. That's all that was originally released next to the paper. Everything since then has been based on careful review of the source code and writing additional documentation from that understanding. Edit: the documentation (that your reply is referring to) exists now because people spent the time reading the source code. This documentation didn't exist originally.

resolutionx 12y ago
The part that seems odd to me is that with all these developers, students, researchers, and curious users nobody documented it according to the paper. Which as stated by another user doesn't seem to be the case.
- mannykannot 12y ago
  Documentation produced that way is actually consistent with the statement you first quoted. I think what is happening here is that the researchers, being properly careful, verified what the software does, rather than trust to descriptions by others. If there had been a formal specification, I imagine they would have both analyzed the specification for vulnerabilities, and checked the code for correct implementation.

eric_bullington 12y ago

I'm not sure when they wrote this paper, but this is no longer true. There's some very nice official developer documentation up at: https://bitcoin.org/en/developer-documentation https://bitcoin.org/en/developer-documentation Also, the Bitcoin Wiki itself is a fairly comprehensive source of documentation (and covers most of the information in the "official" documentation). It even includes an informal protocol specification[1]. It's been around for a very long time. That said, the information they're referring to is Bitcoin's Tor support (like recognizing OnionCat addresses). I don't think there is much documentation on this specific topic. However, Bitcoin is an open source project and I'm sure any related documentation contributions would be welcome. 1. https://en.bitcoin.it/wiki/Protocol_specification https://en.bitcoin.it/wiki/Protocol_specification

resolutionx 12y ago
According to the site it was submitted Oct 22, 2014. So yesterday. It's still an interesting read and I'm sure it holds validity but this bothered me.