5 ms·

"It's a protocol bug!" "It's not a protocol bug!" is sort of a moot point. Bitcoin is a protocol in the sense that the IE6 rendering engine is a protocol: yes,

by patio11 13y ago

"It's a protocol bug!" "It's not a protocol bug!" is sort of a moot point. Bitcoin is a protocol in the sense that the IE6 rendering engine is a protocol: yes, rigorously examining what the client monoculture does and does not emit does allow you to describe some set-of-rules. Trying to create another Bitcoin client which attempts to agree with that set of rules is, ahem, fraught. You have to be bug-for-bug compatible with the Satoshi client implementation, not with the Satoshi client's declared behavior, design intent, or whatever constellation of PDFs and Wiki posts that the Bitcoin community anoints as "the protocol."

oleganza 13y ago
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.
- 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.
panarky 13y ago
It's not only a moot point, it looks like intentional FUD to distract from the main issue: Mt. Gox isn't filling withdrawal requests. Mt. Gox could fix the issue themselves without a change to the protocol by tracking the entire transaction, not just the hash. If they don't do this, then we must ask why not? Could it be that they've lost so much Bitcoin to double-withdraws that they can't fill new withdrawal requests? Would Mt. Gox benefit from a steep decline in the price of Bitcoin, so they can fill the gap at a lower cost? What's a logical explanation of their behavior?

by patio11 13y ago

oleganza 13y ago

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.
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.

panarky 13y ago

It's not only a moot point, it looks like intentional FUD to distract from the main issue: Mt. Gox isn't filling withdrawal requests. Mt. Gox could fix the issue themselves without a change to the protocol by tracking the entire transaction, not just the hash. If they don't do this, then we must ask why not? Could it be that they've lost so much Bitcoin to double-withdraws that they can't fill new withdrawal requests? Would Mt. Gox benefit from a steep decline in the price of Bitcoin, so they can fill the gap at a lower cost? What's a logical explanation of their behavior?