6 ms·

Satoshi never had any "whitepaper spec" which proclaims "intended" behaviour. The protocol is whatever 100% of users agree with. It started with one implementat

Satoshi never had any "whitepaper spec" which proclaims "intended" behaviour. The protocol is whatever 100% of users agree with. It started with one implementation, today we have many of them. And we already had the protocol changed in a hard way ("hardfork") at least 4 times: 1. In 2009 when they fixed OP_RETURN and OP_CODESEPARATOR bug allowing to spend anyone's coins. 2. In 2010 when integer overflow created billions of BTC in one tx. 3. In 2012 when "OP_HASH160 <hash> OP_EQUAL" script was redefined to be interpreted as a hash of a script (see BIP16, Pay-to-Script-Hash aka "P2SH"). 4. In 2013 when v0.8/v0.7 difference in database engines caused half of the network mine parallel blockchain due to obscure limit on number of file handles. The fix which was gradually introduced after reverting "incompatible" (although, longer) chain, was changing the protocol in a hard way. The takeway from this: there's no parallel universe where a clearly defined spec in English is how all software operates to produce exactly the same blockchain. The most precise description would be a computer code itself running on the same hardware everyone uses. Anyone coming up with a "spec" of Bitcoin will only have a "description", not a "prescription".

gus_massa 13y ago
The protocol is whatever 51% of users agree with.
- deleted 13y ago
  [deleted]
- oleganza 13y ago
  No. If 51% of users fork off the blockchain for themselves, their forked coins will lose at least 49% of liquidity and value.
  - maxerickson 13y ago
    There is no concrete relationship between the number of users and the value implied by some portion of those users. (Ridiculous thought experiment: One user controls 75% of bitcoin and will buy and sell them only for $5. Given enough dollars desiring bitcoin he would quickly be reduced to 0% control, but in the meantime everyone else would have some difficulty selling for much more than $5.)
    - oleganza 13y ago
      You are right. What I mean is, if half of the coins will go with a forked blockchain, another half of the coins will not be able to participate on it. So for a guy who is about to receive a payment in a forked coin, the market would be roughly 2x less liquid. It's the same with altcoins: if I pay you in Litecoin, you'll get 11x less liquid object than BTC. Maybe it has the right price at the moment and is fine by you, but as it's less liquid, it's less certain to hold its value over the longer period of time.
      - maxerickson 13y ago
        Yeah, my objection was to the precision that your wording implied. (realistically, I think the outcome of an unpatched fork is the collapse of bitcoin and people becoming very wary of anything claiming bitcoin in its genealogy (or even inviting close comparison to bitcoin))
        oleganza 13y ago
        No, accidental fork will be reverted and people will go on with the previously working software. Bitcoin can collapse only when it's non-recoverable (e.g. ECDSA or SHA256 is completely broken). If it is recoverable (like in all cases mentioned above), then there will be just a short period of turbulence.
        maxerickson 13y ago
        I think there is some resiliency against glitch forks, I don't think it is obvious that the only outcome is 'just a short period of turbulence'. (mostly because there are lots of humans involved and they will act like humans)
- patio11 13y ago
  It's substantially more complicated than that. One: I think you understand "user" as mapping to hashpower-over-some-time-interval, but vanishingly few users of Bitcoin understand user to mean that. Two: if you control less than 50% of the hashpower over some time interval, you can with a certain probability and cost alter some rules of the protocol, and the consensus will back you. For example, there exists no rule amenable to 51% of Bitcoin hashpower currently that says "Transactions to addresses known to be controlled by Patio11 have a special property: they are not allowed on Tuesdays" but you can, in fact, impose that rule on the network without requiring 50% of the hashpower available on Tuesday. (It would be a pretty expensive thought experiment, depending on how certain you would want to be that the rule get adopted.)
patio11 13y ago
In 2013 when v0.8/v0.7 difference in database engines caused half of the network mine parallel blockchain due to obscure limit on number of file handles. Can I just highlight, for generic web developers who might not parse this sentence, that this is like saying "One of the ways we make sure all clients agree on HTTP is by making sure that all clients and servers stay on the same point release of Oracle DB because when they didn't for a few minutes the entire Internet died in fire. We put the fire out by reverting the Oracle DB version on a few big sites, telling everyone else to downgrade as well, and posting on an out of band channel that if you were doing anything important with the Internet you might want to stop for a few hours because there were going to be two separate and very mutually incompatible Internets and one of them was going to suddenly vanish a couple hours later and it sure would suck if your mail/web browsing/Dropbox/etc went into that one." Seriously. That actually happened.
- deleted 13y ago
  [deleted]
  - oleganza 13y ago
    "v1.0" is meaningless label. Bitcoin already works and cannot be changed willy-nilly in a glorious self-proclaimed version 1.0 of a single particular implementation.
  - simias 13y ago
    With the exception of the integer overflow none of these problem seem directly related to the language being used (and integer overflows are a problem in many languages besides C).
  - vezzy-fnord 13y ago
    bitcoind is C++.
- oleganza 13y ago
  Early days of exciting new tech are early. And, yes, Blockchain compatibility requirement is a new phenomenon, unlike HTTP or even TCP/IP, so your comparison is not very relevant (although useful to highlight possible difficulties). We have to get used to it and learn how to deal with the risk of unintentional forks, or stay away from the game.
jacquesm 13y ago
> The protocol is whatever 100% of users agree with. This is not correct, it is what half-plus-one of the users agree to. 100% is not a requirement.

gus_massa 13y ago

The protocol is whatever 51% of users agree with.

deleted 13y ago
[deleted]
oleganza 13y ago
No. If 51% of users fork off the blockchain for themselves, their forked coins will lose at least 49% of liquidity and value.
- maxerickson 13y ago
  There is no concrete relationship between the number of users and the value implied by some portion of those users. (Ridiculous thought experiment: One user controls 75% of bitcoin and will buy and sell them only for $5. Given enough dollars desiring bitcoin he would quickly be reduced to 0% control, but in the meantime everyone else would have some difficulty selling for much more than $5.)
  - oleganza 13y ago
    You are right. What I mean is, if half of the coins will go with a forked blockchain, another half of the coins will not be able to participate on it. So for a guy who is about to receive a payment in a forked coin, the market would be roughly 2x less liquid. It's the same with altcoins: if I pay you in Litecoin, you'll get 11x less liquid object than BTC. Maybe it has the right price at the moment and is fine by you, but as it's less liquid, it's less certain to hold its value over the longer period of time.
    - maxerickson 13y ago
      Yeah, my objection was to the precision that your wording implied. (realistically, I think the outcome of an unpatched fork is the collapse of bitcoin and people becoming very wary of anything claiming bitcoin in its genealogy (or even inviting close comparison to bitcoin))
      - oleganza 13y ago
        No, accidental fork will be reverted and people will go on with the previously working software. Bitcoin can collapse only when it's non-recoverable (e.g. ECDSA or SHA256 is completely broken). If it is recoverable (like in all cases mentioned above), then there will be just a short period of turbulence.
        maxerickson 13y ago
        I think there is some resiliency against glitch forks, I don't think it is obvious that the only outcome is 'just a short period of turbulence'. (mostly because there are lots of humans involved and they will act like humans)
patio11 13y ago
It's substantially more complicated than that. One: I think you understand "user" as mapping to hashpower-over-some-time-interval, but vanishingly few users of Bitcoin understand user to mean that. Two: if you control less than 50% of the hashpower over some time interval, you can with a certain probability and cost alter some rules of the protocol, and the consensus will back you. For example, there exists no rule amenable to 51% of Bitcoin hashpower currently that says "Transactions to addresses known to be controlled by Patio11 have a special property: they are not allowed on Tuesdays" but you can, in fact, impose that rule on the network without requiring 50% of the hashpower available on Tuesday. (It would be a pretty expensive thought experiment, depending on how certain you would want to be that the rule get adopted.)

patio11 13y ago

In 2013 when v0.8/v0.7 difference in database engines caused half of the network mine parallel blockchain due to obscure limit on number of file handles. Can I just highlight, for generic web developers who might not parse this sentence, that this is like saying "One of the ways we make sure all clients agree on HTTP is by making sure that all clients and servers stay on the same point release of Oracle DB because when they didn't for a few minutes the entire Internet died in fire. We put the fire out by reverting the Oracle DB version on a few big sites, telling everyone else to downgrade as well, and posting on an out of band channel that if you were doing anything important with the Internet you might want to stop for a few hours because there were going to be two separate and very mutually incompatible Internets and one of them was going to suddenly vanish a couple hours later and it sure would suck if your mail/web browsing/Dropbox/etc went into that one." Seriously. That actually happened.

deleted 13y ago
[deleted]
- oleganza 13y ago
  "v1.0" is meaningless label. Bitcoin already works and cannot be changed willy-nilly in a glorious self-proclaimed version 1.0 of a single particular implementation.
- simias 13y ago
  With the exception of the integer overflow none of these problem seem directly related to the language being used (and integer overflows are a problem in many languages besides C).
- vezzy-fnord 13y ago
  bitcoind is C++.
oleganza 13y ago
Early days of exciting new tech are early. And, yes, Blockchain compatibility requirement is a new phenomenon, unlike HTTP or even TCP/IP, so your comparison is not very relevant (although useful to highlight possible difficulties). We have to get used to it and learn how to deal with the risk of unintentional forks, or stay away from the game.

jacquesm 13y ago

> The protocol is whatever 100% of users agree with. This is not correct, it is what half-plus-one of the users agree to. 100% is not a requirement.