8 ms·

There's a number of things in that which aren't totally correct. > No, seriously, the decentralized nobody-needs-to-trust-anybody payments network was shut dow

by 0xFEED 11y ago

There's a number of things in that which aren't totally correct. > No, seriously, the decentralized nobody-needs-to-trust-anybody payments network was shut down by an IRC channel's consensus* for 8 hrs.* It wasn't "shut down" in any sense of the word, the network kept working (in duplicate, no less). It was the decision of two pool owners with extraordinary hashrates to sacrifice their chain (which was actually the "correct" one as far as intentions go), rather than the core developers. Nobody has some magic key to shut down the network (though originally, Satoshi's alert key did enable a "safe mode", this is long gone) > Bitcoin is not a protocol in any meaningful sense of word. It is a single C++ codebase that you have to be bug-for-bug compatible with. That's the reality of distributed consensus. Matching it bug for bug is completely foolhardy (and many have failed at the task), you should be just linking in the consensus library which is currently being broken out of the bitcoin core source. > Most advantages of Bitcoin which matter are captured by, and improved upon by, a LAMP app which simply holds account balances. Except for the key one, that a LAMP setup running on a shared host isn't a distributed consensus. You could replace your car with a hamster wheel and it would still go round and round, but it's missing the core function of getting you to work. > Bitcoin presently costs on the order of $6.5k per megabyte of data added to the block chain. Which is why signatures are made with ECDSA, a very compact signature system compared with lamport or RSA. You don't want to be storing data in the block chain, and it's never been posited to be good for this (quite the opposite). > Time between Bitcoin blocks is not guaranteed (follows a Poisson distribution). Sometimes all pending transactions just stop for a while This isn't at all surprising, if they were regular then Bitcoin wouldn't be a functioning distributed consensus. You can get near instant, low trust "confirmations" by using a multisignature oracle which promises not to sign double spends. There's at least one company doing this at the moment, though it hasn't seen huge adoption.

swombat 11y ago
Would be interesting to see Patrick's answer to the above, particularly the first point... I pinged the tweetstorm to a friend of mine who's knowledgeable about Bitcoin and he seemed to feel Patrick was, erm, not particularly believable on this topic. For example, on the first point: this is akin to saying the bit torrent foundation closed down bit torrent! waah! it's impossible once they released the reference implementation, it was out of their hands this is the beauty of open sourced and decentralised technology, once it's out there it's difficult to control the analogy would be Linus going batshit mad and deciding to include binary blob drivers provided by the NSA in the kernel mainline, fine - nobody will use it, business continues as usual using a fork before that and he becomes irrelevant
- maxerickson 11y ago
  They are right, there is no way to shut it down. At the limit a single node can accept and verify transactions (it probably wouldn't mean anything, and would probably take some extra time to complete). The network can enter a state where people that are familiar with it decide to tell people to not use it until it is fixed, and that did happen.
- patio11 11y ago
  http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/11 http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/11 http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12 http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12 The incident begins at 22:11. If you don't trust my summary of it, and you consider yourself very, very well-briefed on what Bitcoin is doing under the hood and who the players are in the Bitcoin community, just read the next ~12 hours of logs. It's absolutely riveting. My summary: The Bitcoin protocol doesn't exist. The only protocol which matters is the actual behavior of the Bitcoin Core client -- the one originally coded by Satoshi, which forms a supermajority of the network. Bitcoin Core released version 0.8 on or about March 11, 2013. This differed from Bitcoin Core 0.7 in at least one respect, which was that 0.7 used Berkeley DB and 0.8 did not. BDB has a configuration issue, specifying the maximum number of locks it can use at once. If you attempt to use more, it returns an error. Here's one reason I say the Bitcoin Protocol doesn't exist: No sane person says "An important feature of the Bitcoin Protocol is that conforming clients MUST REJECT any Bitcoin transaction which would exhaust the default number of locks available to the Berkeley DB." Someone submitted a Bitcoin transaction which did, in fact, exhaust the number of locks available to the Berkeley DB. It was conformant with all the rules that Bitcoiners believe transactions have to be conformant with except that bit about the lock limit in the Berkeley DB. This transaction was accepted by a miner running the 0.8 software. Let's, for convenience, call the blockchain as it existed prior to that block being mined Blockchain B. The blockchain with that block in it is B'. Bitcoin Core 0.7 rejected the authenticity of B'. Accordingly, when 0.8 nodes said "I have a new block to publish! It checks out and builds off of the-present-head-of-B'", 0.7 nodes said "I don't know what that nonsense you're spouting is, but it sure isn't Bitcoin." Bitcoin Core 0.7 nodes and miners continued talking amongst themselves and building B up. Bitcoin Core 0.8 nodes accept the authenticity of B' and all blocks chained on top of it. If you presented them with a block chained off of the head of B, they would say "Oops, sorry, sucks to be you -- someone already has a longer chain. You've created a blockchain, but by the writ of Satoshi, we only do business with the longest compliant blockchain, which is B'." This is called a network split. And it is, in laymen's terms, utterly cataclysmic. Here's why: Suppose Mt. Gox runs on 0.7 and Coinbase runs on 0.8. I can create a transaction which spends some output(s) $COIN and have it accepted into a B' block. Perhaps that transaction deposits my $COIN into Coinbase. Since that transaction doesn't exist on B, I can then deposit the same $COIN into Mt. Gox. Both Mt. Gox and Coinbase believe themselves to be in possession of the same Bitcoin. And both of them are right. Which is why after that channel figures out what is happening that engineering gets real. After discussions between several core developers they ascertain that the Bitcoin mining cabal behind B' is small enough to get, well, both of them on Skype and convince them to throw away hours of history on B' (which is, again, built off the new-and-improved bug free version of Bitcoin) and instead start building off of B instead. Their history must die so that Bitcoin can live. This plan is executed. It works. Read the chat transcript if you don't understand this: Bitcoin was virtually unusable during the interim -- most of the merchants people cared about turned off transactions entirely because they were, sensibly, scared shitless. Several hours of transactional history got wiped out. One security researcher successfully executed a ~$10,000 double spend attack against a merchant -- he gave the money back afterwards. Now, you tell me: how do you rate my credibility here versus your friend? My assessment of this event is "Bitcoin has an identifiable governance structure. You can fit them into an IRC channel +/- a few Skype sessions. They can independently decide to change the rules of the 'Bitcoin protocol' a) at will b) retroactively. I cannot reconcile this with claims that Bitcoin is 'does not require trust' or is 'decentralized.'"
maxerickson 11y ago
I realize there is no one that speaks for bitcoin, but here you have someone announcing to merchants to not process transactions until the fork was resolved (the post refers to a discussion on #bitcoin-dev): https://bitcointalk.org/index.php?topic=152030.0 https://bitcointalk.org/index.php?topic=152030.0 If you're a merchant: please stop processing transactions until the chains converge. So there is room to argue about how patio11 phrased that, but it seems fair enough to say that advice from the insiders was to stop using it for a while (and given that the fork was resolved in keeping with the results of the discussion, I think it is fair to say that there really are insiders). Saying not to use the network has pretty much all the same problems as making it unavailable (and the additional problem that it is confusing for the bad state to be available but not recommended for use).
deleted 11y ago
[deleted]
- 0xFEED 11y ago
  > Weren't all transactions made on the v0.8 blockchain eventually rendered null and void? No they were not null and void, there's no lasting records of what happened but they would have either existed on both chains (likely), or been returned to the memory pools of miners when they were reorganized out (likely). There was only one recorded instance of double spend during the event which was intentional, it and any descendant transactions would have been invalidated on the chain that did not win. > Please explain why all of the above does not count as the network being "shut down" in any sense of the word. Well "shut down" implies that nothing was operational, the network was perfectly functional it just happened to have fragmented due to an oversight in the way the underlying database in 0.7 was configured (you could non deterministically run out of locks, 0.8 didn't have the same failure but wasn't wide spread at the time). It might not have been safe to rely on untrusted transactions from outside sources during the event but anybody not doing this had zero risk whatsoever. The main losers in this event were the miners who threw away their block reward to speed up the resolution of the fork, which were re compensated at a later time anyway. > and also that any transactions that you did on the v0.8 block might need to be re-broadcast? The client handles this automatically.

by 0xFEED 11y ago

swombat 11y ago

Would be interesting to see Patrick's answer to the above, particularly the first point... I pinged the tweetstorm to a friend of mine who's knowledgeable about Bitcoin and he seemed to feel Patrick was, erm, not particularly believable on this topic. For example, on the first point: this is akin to saying the bit torrent foundation closed down bit torrent! waah! it's impossible once they released the reference implementation, it was out of their hands this is the beauty of open sourced and decentralised technology, once it's out there it's difficult to control the analogy would be Linus going batshit mad and deciding to include binary blob drivers provided by the NSA in the kernel mainline, fine - nobody will use it, business continues as usual using a fork before that and he becomes irrelevant

maxerickson 11y ago
They are right, there is no way to shut it down. At the limit a single node can accept and verify transactions (it probably wouldn't mean anything, and would probably take some extra time to complete). The network can enter a state where people that are familiar with it decide to tell people to not use it until it is fixed, and that did happen.
patio11 11y ago
http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/11 http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/11 http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12 http://bitcoinstats.com/irc/bitcoin-dev/logs/2013/03/12 The incident begins at 22:11. If you don't trust my summary of it, and you consider yourself very, very well-briefed on what Bitcoin is doing under the hood and who the players are in the Bitcoin community, just read the next ~12 hours of logs. It's absolutely riveting. My summary: The Bitcoin protocol doesn't exist. The only protocol which matters is the actual behavior of the Bitcoin Core client -- the one originally coded by Satoshi, which forms a supermajority of the network. Bitcoin Core released version 0.8 on or about March 11, 2013. This differed from Bitcoin Core 0.7 in at least one respect, which was that 0.7 used Berkeley DB and 0.8 did not. BDB has a configuration issue, specifying the maximum number of locks it can use at once. If you attempt to use more, it returns an error. Here's one reason I say the Bitcoin Protocol doesn't exist: No sane person says "An important feature of the Bitcoin Protocol is that conforming clients MUST REJECT any Bitcoin transaction which would exhaust the default number of locks available to the Berkeley DB." Someone submitted a Bitcoin transaction which did, in fact, exhaust the number of locks available to the Berkeley DB. It was conformant with all the rules that Bitcoiners believe transactions have to be conformant with except that bit about the lock limit in the Berkeley DB. This transaction was accepted by a miner running the 0.8 software. Let's, for convenience, call the blockchain as it existed prior to that block being mined Blockchain B. The blockchain with that block in it is B'. Bitcoin Core 0.7 rejected the authenticity of B'. Accordingly, when 0.8 nodes said "I have a new block to publish! It checks out and builds off of the-present-head-of-B'", 0.7 nodes said "I don't know what that nonsense you're spouting is, but it sure isn't Bitcoin." Bitcoin Core 0.7 nodes and miners continued talking amongst themselves and building B up. Bitcoin Core 0.8 nodes accept the authenticity of B' and all blocks chained on top of it. If you presented them with a block chained off of the head of B, they would say "Oops, sorry, sucks to be you -- someone already has a longer chain. You've created a blockchain, but by the writ of Satoshi, we only do business with the longest compliant blockchain, which is B'." This is called a network split. And it is, in laymen's terms, utterly cataclysmic. Here's why: Suppose Mt. Gox runs on 0.7 and Coinbase runs on 0.8. I can create a transaction which spends some output(s) $COIN and have it accepted into a B' block. Perhaps that transaction deposits my $COIN into Coinbase. Since that transaction doesn't exist on B, I can then deposit the same $COIN into Mt. Gox. Both Mt. Gox and Coinbase believe themselves to be in possession of the same Bitcoin. And both of them are right. Which is why after that channel figures out what is happening that engineering gets real. After discussions between several core developers they ascertain that the Bitcoin mining cabal behind B' is small enough to get, well, both of them on Skype and convince them to throw away hours of history on B' (which is, again, built off the new-and-improved bug free version of Bitcoin) and instead start building off of B instead. Their history must die so that Bitcoin can live. This plan is executed. It works. Read the chat transcript if you don't understand this: Bitcoin was virtually unusable during the interim -- most of the merchants people cared about turned off transactions entirely because they were, sensibly, scared shitless. Several hours of transactional history got wiped out. One security researcher successfully executed a ~$10,000 double spend attack against a merchant -- he gave the money back afterwards. Now, you tell me: how do you rate my credibility here versus your friend? My assessment of this event is "Bitcoin has an identifiable governance structure. You can fit them into an IRC channel +/- a few Skype sessions. They can independently decide to change the rules of the 'Bitcoin protocol' a) at will b) retroactively. I cannot reconcile this with claims that Bitcoin is 'does not require trust' or is 'decentralized.'"

maxerickson 11y ago

I realize there is no one that speaks for bitcoin, but here you have someone announcing to merchants to not process transactions until the fork was resolved (the post refers to a discussion on #bitcoin-dev): https://bitcointalk.org/index.php?topic=152030.0 https://bitcointalk.org/index.php?topic=152030.0 If you're a merchant: please stop processing transactions until the chains converge. So there is room to argue about how patio11 phrased that, but it seems fair enough to say that advice from the insiders was to stop using it for a while (and given that the fork was resolved in keeping with the results of the discussion, I think it is fair to say that there really are insiders). Saying not to use the network has pretty much all the same problems as making it unavailable (and the additional problem that it is confusing for the bad state to be available but not recommended for use).

deleted 11y ago

[deleted]

0xFEED 11y ago
> Weren't all transactions made on the v0.8 blockchain eventually rendered null and void? No they were not null and void, there's no lasting records of what happened but they would have either existed on both chains (likely), or been returned to the memory pools of miners when they were reorganized out (likely). There was only one recorded instance of double spend during the event which was intentional, it and any descendant transactions would have been invalidated on the chain that did not win. > Please explain why all of the above does not count as the network being "shut down" in any sense of the word. Well "shut down" implies that nothing was operational, the network was perfectly functional it just happened to have fragmented due to an oversight in the way the underlying database in 0.7 was configured (you could non deterministically run out of locks, 0.8 didn't have the same failure but wasn't wide spread at the time). It might not have been safe to rely on untrusted transactions from outside sources during the event but anybody not doing this had zero risk whatsoever. The main losers in this event were the miners who threw away their block reward to speed up the resolution of the fork, which were re compensated at a later time anyway. > and also that any transactions that you did on the v0.8 block might need to be re-broadcast? The client handles this automatically.