Bitcoin blockchain issue - Mt Gox Bitcoin deposits temporarily suspended - <AUTHOR> https://mtgox.zendesk.com/entries/21477395-Bitcoin-blockchain-issue-bitcoin-deposits-temporarily-suspended <comment><USER3> Ok, here's what happened and what it means. Bitcoin is built on a chain of blocks, each of which contains a set of transactions, the hash of the previous block, and a cryptographic proof-of-work which takes a lot of computing power to construct. Whichever block-chain is highest (that is, has the most total computing power invested in it) is considered valid, and has more blocks added to it by miners. People "mine" by taking outstanding transactions, writing them into a block together with the hash of the current highest-numbered block, performing cryptographic proof-of-work and publishing their new block.

A block was mined (by the Slush mining pool) which is accepted as valid by 0.8 clients, but rejected by 0.7 clients. More than half of the mining power was on 0.8, so the longest chain includes this block - but the 0.7 clients reject it, and have built a side-chain. The developers have asked all miners and mining pools to switch from 0.8 to 0.7, so that the 0.7 chain will grow to be longer than the 0.8 chain; once this happens, all Bitcoin clients will agree that it is the real one. In the meantime, however, merchants running Bitcoin 0.8 may be targeted by double-spend attacks: if they receive money in a transaction that exists only in the 0.8 blockchain, the same money is spent in a different way on the 0.7 blockchain so the transaction can't just be copied over, and they act on the receipt of money by sending goods before the situation is resolved, then they could lose money. This is why MtGox has suspended Bitcoin deposits. (This can only happen if the coins were sent by someone who is using malicious, nonstandard software; transactions made by honest users will be copied to the 0.7 fork and mined without any issue.)

The height of the two chains can be monitored at <https://coinbase.com/network/blocks> . Currently the 0.7 chain is 13 blocks behind, which (since the normal mining rate is 6 blocks per hour) sets a lower bound of about two hours on resolution - assuming everyone switches their mining power immediately - but realistically it will probably be more like 6-12 hours.

<comment><USER4> "The developers have asked all miners and mining pools to switch..."

In the grand scheme of things, how much control over bitcoin do the developers have? My understanding of bitcoin is that there is no central authority controlling it like a central bank, but this statement almost implies that the developers have some kind of control, or influence at least, over bitcoin.

<comment><USER5> The developers have influence in that they are relied upon to a massive extent to keep bitcoin running.

As far as I can tell this sort of centralisation of influence is a common emergent property in most anarchic human systems.

Luckily if something particularly egregious occurs in this case, the community can easily fork the codebase and start a rival blockchain.

<comment><USER4> Would they need to start a rival block chain? Or do they just need 51% of the current community to run their clients to take over the current block chain? (as suggested by a comment above)

<comment><USER6> Technically speaking, getting 51% of the community to switch is still creating a rival block chain. You don't even need 51%. As was the case in this incident, if you have incompatible nodes, the block chain would fork itself naturally.

</comment></comment></comment></comment></comment><comment><USER7> From a Bitcoin core developer[1]:

> .7 and older nodes use BDB for storing the blockchain databases. It seems > this database has a limit on the size of the modification it can make > atomically to the database. With the larger blocks of the past days, it > seems to have triggered the limit. The result is that 0.7 (by default, it > can be tweaked manually) will not accept "too large" blocks (we don't yet > know what exactly causes it, but it is very likely caused by many > transactions in the block). Specifically, block > 000000000000015c50b165fcdd33556f8b44800c5298943ac70b112df480c023 > (height=225430) with >1700 transactions.

> However. 0.8 (which uses a different database system) has no such limit, and > happily accepts the block. As the majority of the hash power was on 0.8, the > longest chain ended up using this block, which is not accepted by older > nodes.

[1] [https://bitcointalk.org/index.php?topic=152030.msg1613200#ms...](https://bitcointalk.org/index.php?topic=152030.msg1613200#msg1613200)

<comment><USER8> I use BDB and I doubt they are actually running in to any kind of hard limit of the database. They are probably just running out of locks. Number of locks is a configuration option.

Each modified database page needs an allocated lock that is held during the database transaction until it is committed.

<comment><USER9> You might want to shoot Gavin an email on the off chance he doesn't know this.

<comment><USER10> This is well understood; Peter Wuille detailed this in his first e-mail about the issue. Thanks though!

</comment></comment></comment></comment><comment><USER11> I wasn't involved at all in the discussions, but the cryptopunk in me wonders if this isn't malice. Running out of DB entries in the client can be predicted with reasonable accuracy. "Accidentally" slip in this bug, and "fix" it in a future version. Then time a major transaction to coincide with the fork you know will happen, and bam! Engineered transaction reversal.

That would be one great hack. But my imagination is probably just getting the best of me.

<comment><USER6> Not to mention one giant hack that would be recorded in the publicly available block chain. Given how high-profile this bug is, I suspect that many people will check both chains to see how much double spending occured, and if any of them are suspicious.

</comment></comment><comment><USER12> Is there a sensible fashion by which two robust blockchain forks might merge?

Widespread use of the currency is troublesome if it's possible for _anyone_ to have reasonable odds of forking the chain. If it's possible for a mass panic to reverse transactions, it's not as reliable.

If Asia (4 billion people), banking institution (US federal debt = ~23% of world GDP), or a social group (Catholicism: 63% of the Americas) buys a bunch of stuff then decides, en masse, to revert to an earlier blockchain, it could drive instability. Large groups of people sometimes do unpredictable things (Gangnam Style: 1.4 billion views).

<comment><USER13> _"Is there a sensible fashion by which two robust blockchain forks might merge?"_

They will not merge, but transactions will homogeneize.

I have simulated this scenario, forking the Bitcoin chain on a private network 2 years ago. What happens is that if the chain is forked, and if a client unexpectedly sees that another chain (say chain B) suddenly replaces the chain it was following (say chain A), thereby reverting a bunch of transactions, then the client will automatically retransmits its transactions that it had saved in chain A, to have them saved again in chain B.

That is how a non-malicious client operates.

Of course, if you are a malicious person, you can actually kill the client and manually wipe out its cache of transactions before it has time to retransmit transactions for chain B (therefore recovering coins that you had spent on chain A).

<comment><USER14> I think this scenario is worse because in theory the transactions aren't going to get copied over from the 0.8 chain to the 0.7 chain until the 0.7 chain overtakes the 0.8 one. The two versions aren't database-compatible, so anyone who follows the advice and manually downgrades to get on the right chain is going to lose all the transactions from the previous chain whether they want to or not.

<comment><USER15> The fork was at the block level not transaction level.

The transactions are on both chains. While they may be in v0.8 blocks and still unconfirmed in the v0.7 fork they do exist in the v0.7 fork. The only transactions which couldn't exist in the v0.7 fork are those generated in "v0.8 only blocks" and those are hard locked by the protocol for 100 blocks.

Had both halves of the fork existed for more than 100 blocks that would have presented a more serious problem. This is why the stakeholders (exchanges, merchants, miners, and developers) moved quickly to halt transactions, warn users, and move to the v0.7 version of the chain BEFORE one chain got more than 100 blocks from the fork point.

</comment></comment></comment></comment><comment><USER16> The way the Bitcoin community handled this mornings fork in the bitcoin blockchain is nothing short of incredible. This event significantly increases my confidence in the Bitcoin ecosystem to thrive even when faced with critical issues.

If only the global finance institutions had a fraction of bitcoins capacity to resolve crises with the same unconditional transparency and full cooperation with all agents in the ecosystem.

<comment><USER17> "This event significantly increases my confidence in the Bitcoin ecosystem to thrive even when faced with critical issues."

It does the opposite for me, because it demonstrates that Bitcoin is _extremely_ vulnerable to double spending. Either everyone uses the same version of the software, or you have to deal with the possibility that this event will happen again. Worse still, an attacker might use some kind of malware to modify Bitcoin clients, until they are able to fork the network and double spend.

Yes, making cryptosystems that are secure against malicious majorities is difficult, and experts have published tons of papers and several books on the subject. If Bitcoin's developers want people to trust their system for anything non-trivial, they really need to fix this problem. To break David Chaum's digital cash systems, an attacker would have required exponential computing power in a security parameter that could be scaled arbitrarily, while the users only require polynomial computing power in that same parameter; to break Bitcoin, an attacker only requires a little more than half the sum of all the computing power in the Bitcoin network. The Germans learned the hard way that just because an attack seems too pricey for anyone to bother with does not mean that the attack actually is too pricey for anyone to bother with.

<comment><USER18> The ability for clients to erroneously or maliciously fork the chain can't be designed out whilst keeping the system open and decentralised. The blockchain is a distributed copy of a shared truth which takes time to propagate and has to be agreed upon by all participants. If the network is open, then me, or me and 500,000 friends, can join the network and attempt to propagate a different truth.

If you compare the way the Bitcoin community responded to this with the response you might have expected from even a very well run company, I think the Bitcoin community comes out ahead.

It would be useful and or interesting to compare the Bitcoin community response with a specific failure and response of a for-profit closed- technology company, but I'm not sure what case to use for comparison.

Maybe the recent cloudflare outage?

<comment><USER17> "The ability for clients to erroneously or maliciously fork the chain can't be designed out whilst keeping the system open and decentralised"

That is not true. Cryptographers have published many thousands of papers on securing multiparty computation against malicious participants over the past twenty years. Here is a very brief introduction:

<https://en.wikipedia.org/wiki/Secure_multi-party_computation>

The relevant citations in this field, like the relevant citations about digital cash protocols, are conspicuously absent from Satoshi's writeup about Bitcoin. This is one of the things that bugs me the most about the Bitcoin community: nobody seems to have done any background research at all. There is a _huge_ volume of work that has been done in this field, but little mention of it among Bitcoin's developers. The Bitcoin developers do not even seem to be worried about the fact that the work required to attack Bitcoin scales linearly with the work required to run the Bitcoin system:

[https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_...](https://en.bitcoin.it/wiki/Weaknesses#Attacker_has_a_lot_of_computing_power)

"If you compare the way the Bitcoin community responded to this with the response you might have expected from even a very well run company, I think the Bitcoin community comes out ahead."

OK, the community is great at admitting that there are bugs and finding workarounds. That does not count for much in a secure multiparty system, where subtle problems in a protocol can undermine the security of the entire system. Security in a system like Bitcoin is about more than just "avoid X, remember to do Y, and patch bugs quickly!" Malicious clients are going to have to be dealt with in Bitcoin, and they are going to have to be dealt with better than what we saw today.

<comment><USER19> The thing you must realize is that those previous systems didn't solve the problem Bitcoin solves. It's not quite obvious - I read the Bitcoin paper when it had pretty much just come out, didn't recognize the actual problem it was solving, and ignored it as yet another "contradictory-caveat" system (eg. paper title: "Anonymous Offline Payments!!@" ... later section: "identity escrow, merchant accounts, only offline for honest parties, etc"). It sucks that there's finally a widespread digital currency and it's non-anonymous, but that's not the problem Satoshi actually solved.

<https://news.ycombinator.com/item?id=4979732>

<comment><USER17> "The thing you must realize is that those previous systems didn't solve the problem Bitcoin solves"

That is not the point. Previous work in the field of digital cash and in multiparty computation is very much relevant to Bitcoin, even if Bitcoin addresses a modified problem. The failure to even mention that such work has been done, coupled with a woefully deficient analysis, indicates that the author of the Bitcoin paper had not done much background research.

What stands out the most is the security analysis for Bitcoin. First, the author makes the claim that the system is secure as long as the attacker controls less than half the sum of the computing power of all nodes in the system. This is not really a well-understood model of security; cryptography researchers usually speak of either "honest but curious" models i.e. everyone follows the protocol faithfully or "malicious" models i.e. some parties may deviate from the protocol in arbitrary ways. The idea of a party that can deviate, but only as long as their work is less than the sum of the work done by all other parties, is strange -- but this new security model is not discussed in any depth, nor is it even mentioned as being a new model of security. No time is spent actually proving the claim, which is unsurprising given that the security model itself is not even formalized.

Worse still, the security analysis that is presented only deals with a specific attack carried out in a specific way. The author proves in a somewhat-formal way that this particular attack cannot be carried out in the way he envisioned. No evidence is given that another method of carrying out the attack is impossible, nor is any evidence given that other attacks are impossible.

There is an old proverb in cryptography: anyone can come up with a cryptosystem they themselves cannot break. That is what you are seeing with Bitcoin, but even worse, because the developers know how to break it but do not believe that anyone would be willing to put in the effort. The German cryptographers were surprised to discover that the Allies were willing to build the code-breaking machine necessary to crack Enigma; they knew it had weaknesses but believed that the cost of exploiting those weaknesses was too high for anyone to justify.

My point is less about what problem Bitcoin solves, and more about whether or not Bitcoin's developers are aware of just how much work has been done on secure multiparty computation or digital cash systems.

<comment><USER19> I don't really disagree with anything you're saying. Bitcoin has a lack of rigor all around, and it's quite annoying to see the masses of people defending Bitcoin as being anonymous (etc) when they've no context to place it in.

What I am trying to point out is that Bitcoin has a design property that enables it to actually be adopted (no "bank" - something no other ecash system had, as they were mostly designed in an era when people still believed that banks would be interested in preserving their customers' privacy. lol). This is important if someone _is_ to ever build a better system.

I'm less familiar with recent MPC literature, but the general concept strikes me as more of an existence proof, given the actual efficiency of resulting implementations. Practical ZK/WI results seem to generally decompose larger domain-specific chunks of the problem into primitive operations, rather than one crypto op per generic logic gate. Which seems to be what Bitcoin is doing, in a bumbling sort of way. And I don't see too much of a philosophical leap between "majority of parties" and "majority of computation", given that the former is wishful thinking that admits Sybil attacks.

<comment><USER17> "What I am trying to point out is that Bitcoin has a design property that enables it to actually be adopted (no "bank" - something no other ecash system had, as they were mostly designed in an era when people still believed that banks would be interested in preserving their customers' privacy. lol). This is important if someone is to ever build a better system."

Keep in mind that there is more to digital cash than just maintaining customer privacy (and Bitcoin itself does not really give you anonymity, at least with any reliable guarantees). Banks benefits from digital cash because of the difficulty of committing fraud and (assuming offline transactions) the reduced load on their transaction processing systems. The real issue is not that banks have _no_ incentive to deploy such a system, but rather that their existence fraud-mitigation measures are more cost effective (in the short term). As my colleagues who have worked with banks have explained it to me, the banks only want to know what amount of fraud would occur; if your system can reduce that fraud more than it costs to deploy, then the bank will spend the money to deploy it.

The same design that has led to Bitcoin's adoption is also something of a liability for the system. Without any banks, converting Bitcoin to other currencies requires the use of an exchange, which carries increased costs and risks. The lack of stability in the price of Bitcoin relative to USD is a result of this issue. It is easy to forget that there is a source of demand for USD, one that is grounded in legal structures like the tax code, debt law, torts, etc. Even when people use Bitcoin for their business, they still need to eventually exchange Bitcoin for some national currency to pay taxes and repay debts (and perhaps to pay employees who lack the time or sophistication needed to use a Bitcoin exchange).

Another issue is more technical: there is no secure way to process an offline Bitcoin transaction. In one of his published papers, Chaum proved a property of offline digital cash systems that is as relevant to Bitcoin as it is to Chaum's design: the amount of information that needs to be exchanged in an offline transaction must grow linearly in the length of the offline transaction chain (imagine if a dollar bill became heavier every time it was given from one person to another). What this means is that either you need the ability to "refresh" the unit of value (e.g. reissuing the token in Chaum's system) or else your offline transactions are either insecure or not scalable. As there is nothing in Bitcoin that can "reissue" currency (which involves creating fresh units and destroying old units), Bitcoin is either insecure, insecure for offline transactions, or it does not scale (note that "secure" in this case refers to formal notions of security; Bitcoin does not actually meet that standard, so this point may be moot anyway).

"Practical ZK/WI results seem to generally decompose larger domain-specific chunks of the problem into primitive operations, rather than one crypto op per generic logic gate."

Right, and that is within the field of MPC research. General MPC using circuits or some other description of functions is much slower than special- purpose protocols, which are themselves usually slower than just using a trusted third party. You are correct that Bitcoin is an example of special- purpose protocol; the problem is that Bitcoin as it exists today would only be secure in a minutely stronger variant of the honest-but-curious model. Honest- but-curious is really just a research tool, a model that is used to give feasibility results or to test new designs, and it is certainly not the right security model for anything involving money (of any sort).

"I don't see too much of a philosophical leap between "majority of parties" and "majority of computation","

The leap is this: a single party might gather immense computing power without corrupting any other party. As a simple example, my research group has access to a supercomputer run by the University of Texas, which I could potentially run anything on (not necessarily legally). If you and I were going to use a two-party protocol of some kind, would you really want to use one that forced you to get access to a similarly powerful supercomputer just to be secure?

Worse still, you might not be aware of the computing resources available to other parties. The Germans were not aware of the Enigma-cracking effort until after the end of the war. In today's world, it is possible that your adversary has a botnet, a bunch of EC2 credits, or that you are dealing with the NSA. In all cases, you do not want to rely on a system that requires you to get equal computing power to remain secure.

Some MPC protocols are secure _unconditionally_ , meaning that even an attacker whose computing power is completely unbounded will not be able to violate the security property of the system. In such a case, controlling a majority of the computing power of all parties is not even a relevant detail, because increased computing power does not convey any advantage.

It is more common to assume some bound on the attacker's computing power and to use complexity theoretic arguments about security. Typically, the attacker is assumed to be able to scale their computing power up by some polynomial in the parameters of the system, which includes the participants. Again, it is because there are real-world adversaries who control large amounts of computing power, potentially in secret, that such models are used. The justification is intuitively this: if you have one desktop and your adversary requires a cluster of ten thousand desktops to break the security of the system, you can get a second desktop and double the work you need to do while forcing your adversary to find ten thousand clusters of ten thousand desktops (i.e. squaring his workload). Super-polynomial growth tends to "run away" at the second half of the chess board, so that a modest increase in the work done by honest parties can result in the attacker needing to keep working until the heat death of the sun.

On the other hand, a powerful adversary could potentially corrupt or control parties in the system. The Mafia is not going to buy NSA-level computers; they are going to find the participants and beat them with wrenches. A more real- world example would be the suspicious appearance of lots of highly-reliable anonymous remailers after the September 11th attacks. Having a lot of computing power does little to defeat the remailer system, but if you control all the remailers you can deanonymize anyone. Remailers have a nice security property: only one honest remailer is required to preserve your security (assuming you send your messages through all the remailers and that the remailer protocol itself has certain security properties which real-world remailers lack).

Sorry if that was a bit long. This is a pretty deep topic, and even the foundations are highly technical.

<comment><USER19> > _Banks benefits from digital cash because of the difficulty of committing > fraud and (assuming offline transactions) the reduced load on their > transaction processing systems_

Decades of non-adoption say otherwise. It's hard to say what the exact reason is - paralyzing conservatism, business models built on _decommoditizing_ money into an identity-based instrument, conspiracy via government regulation, or something else. But enough time has passed that if banks were remotely receptive to the idea of digital cash, it would have caught on _somewhere_.

> _there is nothing in Bitcoin that can "reissue" currency_

Every new wallet address, no? Offline transactions are vulnerable to double spends, but this is the case with every digital cash system. IIRC, the ones that protect against offline double spends do so by revealing the fraudster's identity if a token is spent twice - requiring a bank and legal system for recourse.

> _It is more common to assume some bound on the attacker's computing power > and to use complexity theoretic arguments about security._

Sure, and this is what the SHA2/DSA parts of Bitcoin do. Nobody can forge transactions, the worry comes about from double-spending. You have to remember, digital currency is _not_ a two-party problem - every involved party is what gives the currency value. This is essentially a coordination problem (which database copy is authoritative?), and is precisely the novel problem that Bitcoin _solved_. Previous p2p attempts would do something like "majority of parties", which is always vulnerable to Sybil attacks. Bitcoin went for something that _can_ be algorithmically enforced, staking its outcome on the belief that NSA-level computing would both not dwarf the rest of the network, and that double spends would be detected and could be somehow mitigated down the line.

<comment><USER17> "enough time has passed that if banks were remotely receptive to the idea of digital cash, it would have caught on somewhere."

Again, the way I understand it, the problem is not a lack of benefit but that the benefit is not sufficient to convince any bank to switch. Banks are very concerned about fraud; the problem is that they do not get enough fraud protection from digital cash to outweigh the cost, because they already have good fraud mitigation methods. Why switch to a car that gets one more mile per gallon of fuel, when the cost of doing so would not be recouperated for decades?

"Offline transactions are vulnerable to double spends, but this is the case with every digital cash system."

The difference is that a person can double-spend in Bitcoin over and over again, even if the double spending is detected at some point. In Chaum's design, a person who double-spends is eventually ejected from the system, and so a person can only double spend until the double-spent money makes its way back to the bank. A legal system is not strictly needed here; all it takes is the bank blacklisting cheaters.

"this is what the SHA2/DSA parts of Bitcoin do. Nobody can forge transactions"

One does not follow from the other. SHA2 is a (hopefully) secure hash function. DSA is a secure signature system. People might still be able to forge transactions, due to some other property of the Bitcoin protocol that composes poorly with DSA/SHA2. A transaction in Bitcoin is not merely a signed message; there is a protocol that is used to decide the validity of the transaction, and that protocol might be vulnerable to attack (and maybe vulnerable to attack _as a result_ of using DSA, as opposed to some other signature system). Without a formal proof of security for the entire transaction protocol, it is hard to say.

A simpler example might help to illustrate the point. Imagine a system for telling employees that they have been fired that works as follows: the boss signs and encrypts the letter "F" using his signing key and the target's encryption key. It may appear that forging a firing notification is hard, because the signature marks it as authentic and the encryption designates the target (i.e. if you cannot open the message, then you were not fired). However, it is possible for an employee who is fired to turn around and fire others by re-encrypting the message and signature -- which works _even if the signature and encryption systems used are secure_.

(This issue has been studied in the past; see e.g. <http://world.std.com/~dtd/sign_encrypt/sign_encrypt7.html> or <http://eprint.iacr.org/2008/440>)

"This is essentially a coordination problem (which database copy is authoritative?),"

What does "authoritative" actually mean in the absence of an authority? Without a good definition, it is hard to actually say what a solution would have to look like.

"the novel problem that Bitcoin solved."

The fact that Tuesday's fork could happen is pretty strong evidence that Bitcoin is not really a solution to the problem (assuming we even know what the problem actually is). The fact that a double spending attack was made possible by the fork is a sign that Bitcoin is either (a) solving the wrong problem or (b) not solving the problem at all.

Even if we limit ourselves to considering only Sybil attacks, Bitcoin does not truly solve the problem. Sybil attacks are still possible; the only difference is that now the attacker will need more CPU power (maybe; more sophisticated attacks are certainly conceivable).

"Bitcoin went for something that can be algorithmically enforced"

Except that it is not enforced (at least not under any well-understood definition of that word), it is based on this sort of thing:

"staking its outcome on the belief that NSA-level computing would both not dwarf the rest of the network"

In other words, it is assumed that the adversary could never accumulate as much computing power as all the Bitcoin users combined have accumulated. This is a pretty bad assumption to make, since it fails under any number of entirely plausible circumstances. NSA-level computing is a complete mystery to the outside world; maybe they are using computing technology nobody else has, that works substantially more efficiently. How do you know your adversary does not have such systems? Every so often, Bitcoin "miners" switch to some faster technology for that task; is an adversary who invents a new technology for this really so hard to believe?

"double spends would be detected and could be somehow mitigated down the line"

What exactly can be done to "mitigate" double spending in Bitcoin? There is no system for denying access to the network. An attacker who double-spends Bitcoin could keep coming back and could keep double-spending. In Chaum's system, double-spending carries the cost of losing one's access to the system; with Bitcoin, it carries no cost at all (one might just sell the equipment used for the attack, and so one only really needs sufficient capital or credit to procure the equipment in the first place).

<comment><USER19> > _because they already have good fraud mitigation methods_

Then why is it such a big topic, with the banks even deflecting the blame by inventing "identity theft" etc? And even if the banks are fine, the _merchants_ are not, and a new bank should have sprung up to address that. Which leaves us with the remaining option - incumbent banks are cooperating to prevent new competition. I'm not trying to specifically convince you of this paranoia, but provide it as something that _may_ have to be overcome by a digital payment system to be adopted.

> _Chaum's design, a person who double-spends is eventually ejected from the > system_

I'm hazy on my ecash citations. Is "Chaum's design" the one where merchants are assigned identities, payment is offline but specific to the merchant's identity, and a double spender's identity is revealed if a coin has been spent at two different merchants? That's the system that's stuck in my head as best- in-breed _if_ there is a bank on board.

But what I've been trying to get across here is that Bitcoin provides a property _none_ of those other systems provided - freedom from a trusted "issuer"/bank/etc. (While those protocols don't trust the bank to preserve privacy, they _do_ trust the bank to administer the currency by being the counterparty to the tokens.)

> _People might still be able to forge transactions, due to some other > property of the Bitcoin protocol that composes poorly with DSA/SHA2_

Oh sorry, you caught me with my rigor-pants down. What I meant to say is that being built from those primitives, it could be proved as secure as those primitives. Unlike the Byzantine agreement component, which will always have other security tradeoffs beyond SHA2.

> _What does "authoritative" actually mean in the absence of an authority? > Without a good definition, it is hard to actually say what a solution would > have to look like._

When we give up trusted authorities (and specific "parties" necessarily created by some trusted authority), what remains? What differentiates "the majority" ? One of the few things I see is computing power.

> _Sybil attacks are still possible; the only difference is that now the > attacker will need more CPU power_

No, Sybil attacks have been _defined away_ , as they depend on some notion of "parties". The "honest parties" wishful-thinking has vanished, leaving only "majority of computation" as the network authority. Of course the merits of this security model are still up for debate, but it seems to mostly work.

> _The fact that Tuesday's fork could happen is pretty strong evidence that > Bitcoin is not really a solution to the problem_

Erm, given that the fork was a rare event, it actually shows that Bitcoin is _mostly_ solving the problem, just not perfectly.

> _What exactly can be done to "mitigate" double spending in Bitcoin? There is > no system for denying access to the network_

Lol. "no system for" is not the same as "system prevents" (see what happened to the End to End principle). I _guarantee_ we will eventually see exchanges exerting control over what constitutes "valid transactions" and "the network". This is Bitcoin's real weakness.

<comment><USER17> "Is "Chaum's design" the one where merchants are assigned identities, payment is offline but specific to the merchant's identity, and a double spender's identity is revealed if a coin has been spent at two different merchants?"

More or less; the important concept is that a double-spending attack will not only be detected, but that it will both reveal the identity of the attacker and allow the attacker to be blacklisted. It is not necessary to differentiate "merchants" and "spenders;" re-spending a transferred coin in an offline protocol is possible (without sacrificing the "double-spending reveals the attacker's identity" property).

"Bitcoin provides a property none of those other systems provided - <USER2> from a trusted "issuer"/bank/etc"

Bitcoin may do this, but it does so by sacrificing rigorous security and offline payments. Even if we assume that a monetary system without any authorities makes sense (I am doubtful about that), a system where the attacker's effort is linear in the system's parameters is not a system that can be trusted with any significant amount of money.

"What I meant to say is that being built from those primitives, it could be proved as secure as those primitives"

Except that Bitcoin is not a signature system, nor is it a hash function. The only statement that can really be made is this, "Bitcoin's security is dependent on the use of a secure signature system and a secure hash function." Again, look at the email robustness example; a system built from secure cryptographic primitives can still fail to meet its security goal.

"When we give up trusted authorities (and specific "parties" necessarily created by some trusted authority), what remains? What differentiates "the majority" ? One of the few things I see is computing power."

Parties are not created by authorities; parties are what communicate in a distributed system. In the commonly used model, the attacker is allowed to control some number of parties and coordinate their actions; any party, honest or malicious, can scale their computation by some polynomial of the system parameters.

In the case of Bitcoin, parties can enter or leave the computation at any time, without having to send messages to the other parties. That introduces an entirely different challenge, since the attacker can keep adding parties to the system, eventually controlling a majority of whatever capability the parties have. That is not to say that some notion of security cannot be achieved; rather, it means that any notion of security based on a "majority" of _anything_ cannot be achieved without some way to restrict the number of parties the adversary can enter in the system.

The anonymous remailer system faces a similar problem: an attacker can create as many remailers as he wants. In the case of anonymous remailers, however, it is OK for the attacker to control a majority of parties, since it only takes _one_ honest remailer for the system to be secure (i.e. for messages to be anonymized). That should be the goal of Bitcoin: the ability to prevent forgery and double spending as long as _some_ honest parties remain in the system (assuming such a thing is even possible without a central authority; it could be the case that no such protocol can exist).

"Sybil attacks have been defined away, as they depend on some notion of "parties"."

I think the parties in Bitcoin are _the people who use it_. After all, the point of Bitcoin is to facilitate monetary transactions between its users.

"The "honest parties" wishful-thinking has vanished, leaving only "majority of computation" as the network authority"

No, there is still an issue of "honest parties" versus "malicious parties." Honest parties in Bitcoin are people who are willing to follow the rules and who are not trying to double spend their money or spend money they did not mine/receive. Malicious parties are those who are trying to break the rules by whatever means are available to them. The fact that the majority of computational resources is what decides the validity of the transactions just means that a malicious party needs to collect the majority of computational resources; this is not infeasible, and it is only _somewhat_ impractical (and only really impractical for individual people).

"Of course the merits of this security model are still up for debate, but it seems to mostly work."

It seems to mostly work because nobody with the resources needed to carry out the known attacks cares enough about Bitcoin to do so. The NSA is too busy spying on people to worry about Bitcoin, and companies with large numbers of computers like Amazon or Google are busy using those computers to run their businesses.

This does bring up an interesting point, however: an attacker would only really need such large computing resources _during the duration of the attack_. The hardware would still be useful after the attack, and the attacker might simply sell it or use it for some profitable purpose. I think the only thing that really prevents fraudsters from doing this is the lack of capital/credit needed to procure the equipment in the first place (let's put it this way: if you were running a bank, would you give a billion dollar loan to someone whose business plan was "defrauding Bitcoin users?").

"Erm, given that the fork was a rare event, it actually shows that Bitcoin is mostly solving the problem, just not perfectly."

The problem is that the fork was caused by parties failing to adhere to the protocol. If Bitcoin is not resilient to parties failing to follow the protocol _due to a bug_ , then it is also not resilient to parties that do not follow the protocol _because of a coordinated attack_. In other words, Bitcoin is not secure against malicious parties (which are defined as parties that do not faithfully follow the protocol).

<comment><USER19> > _Bitcoin may do this, but it does so by sacrificing rigorous security and > offline payments_

Both seem like definite hard tradeoffs to me. Offline transactions imply there is some ultimate real-world identity that can be punished for fraud. By "sacrificing rigorous security", I assume you're referring to the majority of CPU power controlling the network. If we give up having a central authority and verified identities, we necessitate _some_ measure of "majority of power" in the system (although it doesn't necessarily have to be CPU).

> _a system built from secure cryptographic primitives can still fail to meet > its security goal_

Sure, but one _can_ formalize the properties of Bitcoin, and could prove that it indeed meets those properties.

One of these properties is "network is controlled by the majority of computing power". I'm not saying this is a universal good thing or ultimate solution. What I am saying is that this property is what provides independence from a central authority, which is possibly what has enabled Bitcoin to actually be adopted.

> _Parties are not created by authorities; parties are what communicate in a > distributed system_

No, "parties" are a convenient abstraction for distributed systems papers in that they bound the pervasiveness of an attacker. The reader intuitively understands them as some notion of identity (IP address, digital certificate, etc), but here we have no luxury. As you later touch upon, once you get rid of identities, a single attacker can create an unlimited number of parties.

I think general MPC has only been proved secure if a majority of parties are honest. Bitcoin is substituting 'parties' with computing power, for precisely the reason you describe. Would we say MPC is insecure because the effort required to attack it (number of malicious parties to establish) is linear in the size of the system (total number of parties)?

I understand this isn't the best security guarantee, but you seem to be having an allergic reaction to it. Complexity theoretic guarantees are useful _because_ they work. However, most real-world power balances are close to linear.

I guess my main point has been that Bitcoin provides a property (authority- independence) that previous ecash papers have not. Its guarantees of this aren't the strongest, but if we're to improve it we must recognize the problem it's solving.

Maybe there's another way of implementing authority-independence that doesn't succumb to something as simplistic as computing power. As it is, it seems that Bitcoin will continue to centralize as miners further specialize and the requirements to be "on the network" (versus transacting through an agent) grow.

<comment><USER17> "Sure, but one can formalize the properties of Bitcoin, and could prove that it indeed meets those properties."

This seems a bit backwards. Rather than formalizing the properties of Bitcoin, it seems that we should be formalizing the _goal_ of Bitcoin i.e. the properties we _want_ , and then prove that Bitcoin satisfies those properties (if it does actually satisfy them). I think that such a formalization would require a formalization of the entire Bitcoin concept of money, which would probably be beneficial in and of itself.

"If we give up having a central authority and verified identities, we necessitate some measure of "majority of power" in the system"

I think that really depends on your notion of money. If you are like me, you believe that money has value because of its utility: fiat currencies have utility that is defined by a legal system (taxes, debt law, torts, etc.), but one could imagine something else. Suppose, for example, that you had a digital cash system in which the money was redeemable for CPU time in a secure outsourcing system; this could potentially be decentralized. Controlling more computing resources would not give an attacker greater power over the network, but would allow a party to receive more payments (because they are basically selling access to their CPU). It is of course possible that such a system could not be securely realized for technical reasons.

"One of these properties is "network is controlled by the majority of computing power"."

This is not a very precise definition, at least not in the cryptographic sense. What is the formal definition of computing power here -- what is the computation model? It would be very hard to _prove_ that a system has this property in a rigorous way.

On the other hand, in the system I described above, you could formalize the measure of how much work a node did (and how much payment was received) by using circuit families as the computation model and the number of gates evaluated as the measure of work. This sort of abstraction would allow a rigorous proof of various properties of the protocol; e.g. maybe you want to show that the payment a party receives will be some proportion of the number of gates the party evaluates.

"As you later touch upon, once you get rid of identities, a single attacker can create an unlimited number of parties."

Not _unlimited_ ; the attacker's ability to enter parties into the system is bounded by the computing power of the attacker. If the attacker can only scale their computation by some polynomial in the parameters of the system, the attacker can only enter some polynomial number of parties. If the protocol is secure as long as there is one honest party, the attacker would not be able to win _even_ under such a scenario.

"I think general MPC has only been proved secure if a majority of parties are honest."

It is not really that simple. For example:

<http://eprint.iacr.org/2012/441.pdf>

There is a protocol that is secure even if only one party is honest. The problem here is that "secure" does not have a single meaning in MPC. There are various adversary models: an adversary might only be able to choose which parties to corrupt before the protocol runs, or might be able to corrupt parties while the protocol is running; he might be allowed to adapt the attack between the computation rounds and the output round, as in that paper; he might be allowed to compose protocols together in arbitrary ways; etc. Some protocols require a setup phase or an authority, some are standalone (as in the paper), some require a broadcast channel, and so forth.

<comment><USER19> > _you had a digital cash system in which the money was redeemable for CPU > time in a secure outsourcing system_ ... _It is of course possible that such > a system could not be securely realized for technical reasons_

I don't see how it could be possible to design a system were useful CPU work done for others was _turned into_ tokens, as one could simply create a whole bunch of fake work. The fundamental question is who is the counterparty to the tokens? If it's the entity selling CPU time, then you're dealing with a gift card system that doesn't scale to a real currency. If it's not, then you're no longer describing the payment system but have switched to describing an application of it.

> _What is the formal definition of computing power here_

Clearly it's just the ability to calculate SHA2 preimages. If you want something better, you've got to come up with that formality _and_ an implementation to show that it is practical.

I'm having a hard time responding because it seems like you want to postulate systems with these nice-sounding properties, but it seems apparent to me that you'd never be able to connect them with proofs to make a system. You simply won't be able to build proofs of work for something as simplistic as "number of gates evaluated" (and if you're talking about 'gates' in MPC, you're really just talking about eg group operations).

> _If the attacker can only scale their computation by some polynomial in the > parameters of the system, the attacker can only enter some polynomial number > of parties_

What you're describing here _is_ Bitcoin. You've just been spoiled with attackers usually needing exponential resources. As I said, your formalities are misleading you - crypto algorithms may work this way, but not everything does! An algorithm cannot discern good guys from bad guys, meaning they're both on equal footing and the best we can do is have a power balance.

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER20> Does this mean, that basically any functional change in the block verification code can be used to leverage the hashing power of all users of one version into a 51% attack?

The attack would be essentially to create the current situation artificially by crafting a block that is only valid by one version of bitcoind, therefore splitting the block chain. Then one needs to include two different transactions into the two blockchains. ( In the theoretical scenario, by mining another block for one of the chains. ) For this I do not need to have 51% of the hashing power, but the branch of the blockchain needs to be supported by 50% of the hashing power.

EDIT: Thinking a bit more about this, it seems that the probability to suceed with such an attack seems to rely on the attackers abbility to craft a 'splitting block', which should be proportional to the share of the attacker controlled hashing power and the ability of the 'incompatible' clients to outgrow the standard block chain. ( So that a merchant with an 'incompatible' client accepts a payment based on the fork of the blockchain.) This means that the attack is probably impossible, if the one CPU one vote approach is not only used for valid transactions, but also for valid clients.

<comment><USER21> Ah how awful and awesome that the world is becoming like a William Gibson book.

</comment></comment><comment><USER22> Sometimes I wonder how many extra tons of coal have been burned simply because of the existence of bitcoin.

<comment><USER23> At the moment, one ton of coal per hour.

Assume that mining reward is approximately equal to investment. This will tend to be the case, though it fluctuates.

Right now we're rewarding 25 bitcoins, at a price of $45, every ten minutes, or $6,750 per hour. Let's say half the required investment is hardware, half electricity at the national average of 11 cents per kWh. Divide 3375/.11 for 30,681 kW power devoted to bitcoin at this moment.

With similar calculations, I recently figured out that if bitcoin were to reach the size of the U.S. dollar in about 20 years, it would be consuming about a gigawatt. It was less than I expected, because the number of new coins per block keeps decreasing, and you only pay electricity for the new ones. This doesn't account for transaction fees, which increase the mining investment that can be sustained. At the moment I think they're a small percentage of the mining award. I'm also neglecting miners' profit margins, which decrease our energy investment.

Coal is 22% of U.S. power production, and generates 2,460 kWh/ton. (30,681 * .22) / 2460 happens to equal almost exactly one ton of coal burned per hour to support bitcoin.

The U.S. generates 227 GW from coal, so our 6.7 MW is about one part in 33,000 of total U.S. coal consumption.

Sources: just type questions into google and all the numbers come right up. I assumed, perhaps incorrectly, that U.S. numbers were more typical of the bitcoin population than global numbers.

<comment><USER23> Math goof, can't edit: 30,681 * .22 is 6750 kWh, which divided by 2460 kWh/ton is of course 2.74 tons of coal per hour, not sure how I came up with 1 ton.

</comment></comment></comment><comment><USER24> From news in #bitcoin-dev, it looks like miners on 0.8 are being instructed to downgrade to 0.7, and that'll be the winning fork of the chain going forward. There shouldn't even be any lost bitcoin transactions.

<comment><USER25> _There shouldn't even be any lost bitcoin transactions._

That can only be true if there are not conflicting transactions in the two chains. That might be the lucky outcome, but it's certainly not guaranteed to be the case.

Any transactions that were confirmed on the faulty chain will have to be re- confirmed in the correct chain. How long that will take would depend on just how many transactions need to be processed, and how big their payload is. Until that is completed, the state of the bitcoins involved in those transactions is ambiguous.

</comment></comment><comment><USER26> Well, then, bitcoin was about due for a HUGE DISASTER to bring the price back down to sane levels, wasn't it?

For those not watching, BTC is currently trading at ~$45.

<comment><USER27> What determines whether a price is sane or insane for a commodity with no intrinsic value?

<comment><USER26> It's more than doubled in the last two months.

[http://bitcoincharts.com/charts/mtgoxUSD#rg180ztgSzm1g10zm2g...](http://bitcoincharts.com/charts/mtgoxUSD#rg180ztgSzm1g10zm2g25zv)

<comment><USER28> That doesn't seem necessarily relevant.

<comment><USER29> Wild runs are typically- not by requirement, but typically- indicative of a crash in the near future. This is because speculation is usually the main driving force behind very steep ramps.

<comment><USER30> What determines a "wild run?"

As has been shown time and time again in academic and corporate research, the single best predictor of an asset's value is the current market trading price for that asset.

<comment><USER29> So you'd argue there is never a bad time to buy?

<comment><USER30> No.

<comment><USER29> It's great to have an actual conversation. You should try it some time.

<comment><USER30> Well, you asked me a yes/no question that has little to do with what I said. So I figured I'd just answer it in the same manner.

<comment><USER29> You are establishing a pattern of responding to comments with _maximal_ brevity and offering zero constructive input.

Ok, so you think RickHull was using "Exceedingly rudimentary technical analysis based on non-scientific trends"? What have you got for us that is so much better?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment><USER31> Slightly off-topic, but it is well-known that one can embed arbitrary data in the bitcoin block chain, so you pretty much have to expect that at some point someone will inevitably insert one of the many illegal numbers into it, putting everyone running it openly at risk, regardless of the political attitudes towards bitcoin itself. I know anonymity isn't one of bitcoin's purported purposes, but I think it will ultimately be necessary to make it one because of this.

<comment><USER32> Not sure what an "illegal number" would be. Certainly someone could embed child pornography or political propaganda.

Bitcoin seems subject to a vast array of DOS and other attack that could be seriously problematic if it became an important currency.

<comment><USER33> I think OP is referring to something like an AACS key: <http://en.wikipedia.org/wiki/Illegal_number>

</comment></comment></comment><comment><USER34> From [1]:

>If this is a widespread problem, it is an emergency. We risk having (several) forked chains with smaller blocks, which are accepted by 0.7 nodes. Can people contact pool operators to see which fork they are on? Blockexplorer and blockchain.info seem to be stuck as well.

So, what would happen to the coins used in those forked transactions? If the chain does fork what would the best strategy be for performing the merger?

And more interestingly: since bitcoin transactions are considered to not be reversible bitcoins are easily converted to and from other currencies with non-reversible transactions. If one were to convert his or her bitcoins to, e.g., Liberty Reserve right now and the chain got reversed that would result in pretty much a perfect scam, wouldn't it?

[1] [http://sourceforge.net/mailarchive/message.php?msg_id=305878...](http://sourceforge.net/mailarchive/message.php?msg_id=30587843)

<comment><USER20> The chains do not get merged. It is just, that the longest block chain is the consensus history of all transaction ( and it needs to be consistent). So if the .7 branch overtakes the .8 branch, then legitimate clients will detect that a transaction was not carried out and retransmit it. ( And the scam you are describing is precisely why Mt Gox did stop accepting bitcoins. They are afraid that someone can take advantage of the situation.)

</comment></comment><comment><USER35> This can only be positive. Finding out issues like this will only make the software/network better.

<comment><USER36> This is the first large occurrence of an issue that has always been known to be possible to people who are reasonably familiar with BitCoin, due inherently to it's design. This could be bad for BitCoin because now a much large portion of BitCoin users/investors are also aware of this risk.

<comment><USER13> No this is not the first large occurence of this issue.

A fork this big (dozens of blocks covering multiple hours of transaction history) already happened in August 15, 2010, due to an unrelated bug: [https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposu...](https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures#CVE-2010-5139)

<comment><USER37> Though to be fair, that's like saying something happened in the precambrian age when talking about the average bitcoiner's awareness.

</comment></comment></comment></comment><comment><USER38> No matter how much I try, there is always a part of Bitcoin which I don't fully understand, kind of scary actually.

<comment><USER39> Do you really understand all the inner workings of the current monetary system?

<comment><USER40> The difference is that enough people accept the current system without understanding it that you can use it for your needs. Not enough people use bitcoins that you can gloss over details.

<comment><USER41> If the Bitcoin monetary system breaks, only those using Bitcoin for savings or investment get hurt. Those who use BTC as a means of payment (buyers and sellers) have little reason to care, so long as they frequently convert excess BTC into other currencies.

That's not so different from the U.S. dollar. You can buy and sell stuff using U.S. dollars, but unless you foresee the value of USD going up (a kind of deflation), you don't want a pile of USD under your mattress. (Also, it's uncomfortable.) Depending on your economic outlook, you want the money in something else: metals, some sort of investment vehicle, or a basket of [foreign] currencies.

</comment></comment></comment></comment><comment><USER42> The fork is now resolved, sites like mtgox should begin processing deposits again after a couple more blocks.

</comment><comment><USER43> So the solution from MtGox is to downgrade, wait a bit, then upgrade. What a currency of the future!

<comment><USER44> Very little that has ended up replacing the status quo has done so without growing pains.

<comment><USER37> Very little that's actually _in_ the status quo doesn't have similar problems. Their problems just don't get widely reported.

</comment></comment></comment><comment><AUTHOR> This could be a very bad thing.

There was a fork in the blockchain, and the community will have to decide how to resolve it. Some transactions which were "confirmed" could be reverted.

IF YOU ARE A MINER READ THIS: [http://sourceforge.net/mailarchive/message.php?msg_id=305879...](http://sourceforge.net/mailarchive/message.php?msg_id=30587976)

<comment><USER37> Word on #bitcoin is that transactions should NOT be lost.

We'll see how it actually shakes out, but that's good news for bitcoin if it holds up.

</comment></comment><comment><USER45> >Miners are encouraged to downgrade to Bitcoin 0.7.2 - at least temporarily - to push the correct blockchain forward.

How does one know who to believe when determining what the "correct" blockchain to forward would be?

<comment><USER6> The good thing about this is that there is no major conflict among people regarding which block-chain is correct. Almost everyone agrees that we need to solve the problem of having a huge portion of nodes not being compatible with the current block chain. Only one of the two blockchains meets this criteria.

</comment></comment><comment><USER46> For a clearer explanation see: [http://www.reddit.com/r/Bitcoin/comments/1a51xx/now_that_its...](http://www.reddit.com/r/Bitcoin/comments/1a51xx/now_that_its_over_the_blockchain_fork_explained/)

</comment><comment><USER46> I was asleep when this happend, but waking up to check HN, reddit and my mtgox got me up to speed. For some reason, this doesn't worry me a bit. Mostly because of the steady and strong growth I've see recently.

</comment><comment><USER47> Bitcoin seems to be picking up again. From Mt. Gox:

        > Last price:$45.00000
        > High:$48.46900
        > Low:$36.65000

Edit: It could go back down a lot. We'll see what happens.

<comment><USER48> Prices have been above $36 for barely a week, 5th/6th rally saw high volumes; the recovery (8th to 11th) was weaker and did not break the high. The volume of both sell-offs was comparable, but the today's low is higher. I reckon it might flatten out around $40 for a bit, then pick up again.

</comment></comment><comment><USER49> Guys, it looks like prices are dropping pretty quick now on mtgox.

This will be another... interesting couple of weeks for bitcoin.

<comment><USER9> down $4, looks like normal price fluctuations from the last couple weeks.

<comment><USER49> It was down to $36.50 for a couple seconds/minutes- looks like that got bought back up though.

Weird.

</comment></comment></comment><comment><USER50> I'm curious how this bug will affect bitcoin price. I'm betting it'll go up even more.

<comment><USER51> How could this possibly result in Bitcoins going up? Even if this is handled without any hiccups, this should shake a lot of people's faith (myself included).

This should be a wakeup call for anyone that thinks that Bitcoins are totally secure. What if next time the bug in the client is more exploitable? Someone malicious could potentially take out the entire Bitcoin economy in one day by exploiting it.

<comment><USER37> If it comes through this with no lost transactions, then the system has proven a degree of robustness.

<comment><USER52> Only because the community is so small that telling "everyone" to downgrade to 0.7 is actually doable. Now imagine a future where everyone uses bitcoin - imagine getting an institution like a bank to get on the "right" version...

<comment><USER53> Actually, for this purpose the system is not getting any bigger right now.

You only need to notify miners and mining pools. These have been concentrating for a while and will continue to concentrate in the future.

Individual users who aren't mining don't need to do anything.

</comment></comment></comment></comment></comment><comment><USER54> What a stressful 24 hours. Everything has finally been resolved.

</comment><comment><USER55> What is a good way to follow updates on this situation?

<comment><USER47> This (probably) won't discuss the technical problem, but <http://www.bitcoinity.org/markets> will let you track Bitcoin prices.

<comment><USER55> thanks for the reply. I always have bitcoinity open. (dark theme FTW).

The answer to the question I was trying to ask is <https://coinbase.com/network/blocks> which enables me to check in on how far behind the future legitimate blockchain is (7 blocks at time of writing).

<comment><USER56> This page is out of date by a bunch of blocks.

<http://blockchain.info/> is updated live.

As you can see, the 0.7 chain has already overtaken the 0.8 chain, and clients are now resubmitting transactions into the 0.7 chain.</comment></comment></comment></comment>


Next language to learn?  - <AUTHOR>

I've been coding in .NET for a while (ASP.NET MVC). I like the direction MS is going with Open Source, but I want to branch out into some LINUX type stuff too. I have an idea for a site that  I could code up in about a month if I used .NET.<p>But I want to take the opportunity to kill two birds with one stone, and build it using all LINUX. So what's the best framework for me to learn? Ruby, Node, PHP? Which skills would be idea for freelancing (planning to leave curr. employer by end of year). I'm not too keen on Ruby, the smug Ruby developers I've known have turned me off to it, but I realize that's kind of a stupid anecdote to carry with me too. <comment><USER2> > I'm not too keen on Ruby, the smug Ruby developers I've known have turned me > off to it, but I realize that's kind of a stupid anecdote to carry with me > too.

Yes, it is the wrong thing to pick up on.

I've been doing PHP for a little over a decade now. If I had to start all over, or if I had to start as a developer right now, I would still choose PHP. The amount of money, productivity, benefits and satisfaction I have gained from working with PHP has been enormous.</comment>


Windows 10 China Government Edition - <AUTHOR> https://blogs.windows.com/windowsexperience/2017/05/23/announcing-windows-10-china-government-edition-new-surface-pro/amp/ <comment><USER2> "The China Government Edition will use these manageability features to remove features that are not needed by Chinese government employees like OneDrive, to manage all telemetry and updates, and to enable the government to use its own encryption algorithms within its computer systems."

It's sad yet astonishing that the people who get the most secure, experience optimized and pro privacy version of Windows live in one of the world's most oppressive countries. It's sad because security, usability and privacy isn't something that Microsoft defaults to, it has to be coerced to implement these things or have its business opportunities in China being jeopardized. Maybe this is a lesson that Western governments need to embrace.</comment>


Ask HN: Does anyone offer email servers as a service? - <AUTHOR>

I run a tiny side business hosting sites, mostly for friends. I'm taking on a new one that has a couple of domains associated with it, and the owner wants to receive any email sent to any of them. I've set up mail servers in the past, but if possible, I would rather avoid it. So I figured someone must offer mail servers, where I can tell it a domain, create an account, and change the MX records. Google Apps for domains is the closest thing I've found so far, but it seems like a lot of fluff around what I want. Has anyone encountered a simpler solution to my problem? <comment><USER2> [http://www.rackspace.com/email-hosting](http://www.rackspace.com/email- hosting)

Rackspace Email is $2 per mailbox per month ($10/month total minimum), 100% uptime SLA, 24x7x365 support, webmail/POP/IMAP. You bring your own domains, just point MX records to Rackspace.

<comment><AUTHOR> I've had lots of good experience with Rackspace in the past, but in this case I only need one mailbox, but I need all mail for the domains sent to it. Maybe my case is too specific.

<comment><USER2> Rackspace Email has all the features you'd expect of an email host, like aliases, forwarding and catch-all addresses. You should be able to forward the mail from all the domains to one mailbox. You'll still need to pay the minimum of $10/month.

</comment></comment></comment><comment><USER3> You might consider iRedMail. It's not a service, but it's super easy to set up. It bundles all the top mail services in one easy installer and provides their own custom admin webapp (the simple admin is free... the advanced admin is how they make money). You can add multiple domains after the installation process. They'll make you create an initial super user on some domain during installation but you can delete it later.

[http://iredmail.org/](http://iredmail.org/)

</comment><comment><USER4> [http://MXroute.com](http://MXroute.com) offers email servers with a reasonable pay by the GB plan but forwarding is limited

[http://ClouDNS.net](http://ClouDNS.net) offers dns service that has email forwarding (no accounts, just forwarding)

<comment><AUTHOR> mxroute appears awesome for my needs. Thanks!

<comment><AUTHOR> Seriously awesome. Since making this post I have set up the domains and account I needed, and tested it. All that's left now is the mx records. :)

</comment></comment></comment><comment><USER5> Google Apps is the route I've taken in the past. I've also tried Outlook (server, not client) and regretted it, but it was what the client wanted.

I run the same kind of business, if you want to collaborate hit me up we can share ideas.

</comment><comment><USER6> Check this ([http://www.hackertoolbox.com/tags/email%20hosting](http://www.hackertoolbox.com/tags/email%20hosting)). I am very happy with zoho.com.

</comment><comment><USER7> Namecheap, the domain registrar, has pretty good value-added e-mail services. Free forwarding with domains, actual IMAP mailboxes from $10-$30 for the entire year. I'd recommend them.

</comment><comment><USER8> Fastmail?

</comment><comment><USER9> Zoho Mail?</comment>


Impressions from our $5m series A financing - <AUTHOR> http://micho.biz/post/64865358804/impressions-from-our-5m-series-a-financing

<comment><USER2> 'Funding isn't success. Revenue is' that's the key of the whole business.</comment>


SoundCloud Now Lets You Distribute Your Music to Spotify, Apple Music - <AUTHOR> https://pitchfork.com/news/soundcloud-now-lets-you-distribute-your-music-to-spotify-apple-music/ <comment><USER2> This is great because the process I had to follow in order to get my band listed in Spotify required far too many hoops to jump through just to be able to distribute our music more easily to fans. Bandcamp proved to be the best service for initial distribution but the method for SoundClound sounds like the middleware we had been missing all along.</comment>


Go and Assembly - <AUTHOR> http://www.doxsey.net/blog/go-and-assembly <comment><USER2> Now _this_ is an impressive argument. Particularly the first section about the tool chain (and the assembly part is really cool too).

I have been holding back because I don't like the lack of exceptions. But it occurred to me that C doesn't have anything like exceptions either, and even though that lack causes some serious irritation, the C language as a total package overcomes it and is really powerful.

I don't know if any language can beat that list of tool chain benefits. Maybe I _will_ give go a whirl.

<comment><USER3> I think the only thing missing is a REPL as part of the tool chain. ipython and scala shell are so useful, especially when you're learning or just testing things out.

<comment><USER4> Agreed. The way I tend to use the repl in clojure is just to code up a script in vim and then %Eval the whole thing. Editor plugins for Go could compile- and-run, and know stuff like the working directory and the gopath, which could get you a bit closer without having to build a real REPL.

<comment><USER5> > Editor plugins for Go could compile-and-run

Yep, rolled my own here: <http://github.com/metaleap/go-buildrun> \-- I use it with GoSublime on Ctrl+B (which I strongly suspect must have some repl-like feature anyway by now, but not sure) -- but works in any editor that lets you hook a key binding to an executable and pass it the current .go file's path.

</comment></comment></comment></comment><comment><USER6> Here's how to do inline assembler in D:

        int *_memset32(int *p, int value, size_t count) {
          asm {
            mov     EDI,p           ;
            mov     EAX,value       ;
            mov     ECX,count       ;
            mov     EDX,EDI         ;
            rep                     ;
            stosd                   ;
            mov     EAX,EDX         ;
          }
        }

The compiler adds the function prolog/epilog for you, as well as any save/restore for used registers.

<comment><USER7> Well, this article wasn't about _inline_ assembler. Regardless, inline forms have a number of problems, the biggest one being supporting multiple platforms w/o a bunch of preprocessor noise. That doesn't stop it from being useful for certain languages but it matters less and less given how compilers behave these days.

<comment><USER6> There is a steady drift away from using assembler even in languages that support it. Intrinsics, for example, often work better. But there are a few things where it really comes in handy.

<comment><USER7> I wonder if we'll see more user-side emulation of intrinsics given new __attribute__ flags compilers are implementing. It certainly is easier to reason about.

Go doesn't have anything like that yet but I wouldn't be surprised if an experimental implementation is done by one of the alternate compilers being worked on.

</comment></comment></comment></comment><comment><USER5> Great write-up. As I'm perusing the math/somefeature_arm.s and math/somefeature_amd64.s files in Go's math package, I can't help notice most of them look like this:

<http://golang.org/src/pkg/math/remainder_arm.s>

That is, very short code that just looks like a function call to me, the complete asm noob. What is it, are all these maths functions implemented in hardware by amd64 and arm architectures? Or is this "asm code" just reverting to calling the Go implementation of the particular function (aka the not really that "optimized")?

<comment><AUTHOR> In this case there is a 386 implementation:

<http://golang.org/src/pkg/math/remainder_386.s>

The other two call the go version:

<http://golang.org/src/pkg/math/remainder.go>

<comment><USER5> Yeah that was kinda my point ;)) so basically 386 users get some highly specialized hand-tuned asm optimization whereas arm and amd64 merely get a commoner's gc treatment -- or am I missing something? ;)

<comment><USER8> Several things:

\- The fprem1 instruction is actually a long microcode sequence and is quite slow; 26-50 cycles on SNB according to Agner Fog. Several iterations of that loop are necessary for a complete reduction of some operands.

\- There is no analogous instruction on arm (or really, any platform that isn't x86), anyway.

\- If you're using the floating-point remainder operation in a performance- sensitive context, You're Doing It Wrong. Programmers have gotten so used to this that there is little value in optimizing remainder; it is rarely used in situations where the optimization would matter.

<comment><USER5> This was just a random example I picked, I'm not using that function currently. But let's just say abs(), sin(), cos()...

</comment></comment></comment></comment></comment><comment><USER9> And herein lies the problem with Go. Seriously, try searching for articles about Go on HN. People always say "well the name isn't a problem, because you just search for it with "golang" instead!" but _no one writes golang unless they're pointing out how to search for it_. If I was trying to get back to this article a month from now and I searched for "go", would I find it? Probably not, unless I remembered the article title contained the word "assembly", but then I'm matching a search to assembly and not Go.

The name is a problem. And if the name is not a problem, then the community is a problem.

<comment><USER5> [[[EDIT: wrote this little rant before realizing you specifically refer to HN search rather than general search. Yeah why would I ever search on a specific Go topic exclusively on HN, instead of web-searching?]]]

Every time a Go article comes up, the "name searchability" discussion comes up. Go's been around for some 4-5 years now, can we all come to terms with its name?

Somehow whenever brainfuck-lang threads show up, this issue is never raised, but surely might exist just the same? What about Perl (a common word), or Basic (even more basic), heck "C" (a freakin' letter). Is that so much better for searchability? Rust -- a common word. D -- a freakin' letter. Miranda -- a language but also the name of 100s of townships, an IM client etc etc.

Go is not the first language to have this "problem", and in fair daily practice it never ever is a problem. Because you never search for Go, you search for "Go channels" or "Go image processing" or "Go GTK binding" or "Go compiler error X" etc. etc. Like you would for all these other fine examples of oddly named languages. And somehow, Google is semantically smart enough to present a few decent matches among the first 10, even with all your personalization & tracking cookies etc. etc. disabled.

So... problem? Herin lies the problem with Go? Seriously... it's just not a big freaking deal getting in the way of getting stuff done. Promised.

<comment><USER10> Your examples make no real sense, other than "Basic". Perl is absolutely NOT a common word. _Pearl_ is common, but Perl is the programming language (only)

<comment><USER5> zOMG you're right re pearl -- I'm kinda shocked at myself right now. In my defense, in German it's "Perle" so not that different...

OK scratch the Perl example. Still standing by my point: it's a "problem" shared by many languages and it's not a problem in the first place.

<comment><USER10> I found a list of English words by frequecy of use in Project Gutenberg texts.

"Basic" is around #9,500.

"Rust" is ~#10,950

"Java" doesn't appear at all (List goes out to 40,000) (Admittedly, somewhat biased by the dated-ness of the material, but it's still not a common one.)

Go is #106, and modern lists based on contemporary sources place it in the top 50 most used English words.

<comment><USER11> <http://norvig.com/mayzner.html>

(1MB) word count list: <http://norvig.com/google-books-common-words.txt>

Go: 187, Basic: 759, Java: 7136, Rust: 13110

With relative frequencies 320M:103M:8.9M:3.6M ~ 100:30:3:1

<comment><USER12> This is very biased, because there's a whole junkload of intro-to-java textbooks in Google books.

[https://www.google.com/search?q=java&btnG=Search+Books&#...</a>

</comment></comment></comment></comment></comment></comment></comment><comment><USER13> So what does that middle dot actually do before the function names? It doesn't seem to be mentioned in the linked documentation of the Plan 9 assembler, and if I have to use a character that I can't easily type with my keyboard, I'd like to at least know what it actually does. :)

Also, doesn't doing this limit your code to using gc toolchain (since the generic Go function has to get called from the arch-specific asm code which uses that Plan 9 dialect)? Does this mean that the Go standard library can't be compiled with gccgo for example?

<comment><USER14> > So what does that middle dot actually do before the function names?

<http://stackoverflow.com/a/13490787>

<http://article.gmane.org/gmane.comp.lang.go.general/78328>

</comment></comment><comment><USER15> Does Go only support that crazy Plan 9 (amd64) assembler syntax that nobody uses anywhere?

<comment><USER16> Well, since two of the original three developers (Pike and Thompson) were part of the Plan 9 team, it makes perfect sense that they based the compilers on the Plan 9 ones.

<comment><USER17> I see recent commits in Go's mercurial history to fix bugs on Plan 9. Is anyone at Google actually using Plan 9 to develop Go? Or is building for Plan 9 just a sanity test for maintaining cross platform code?

Wikipedia says the last "stable" release of Plan 9 was in 2002, but there seem to be a number of recent forks.

<comment><USER18> Plan 9 is on a rolling release since 2002.

</comment></comment></comment></comment><comment><USER19> This reminds me of a topic that had come up earlier last year: Intermitten problems with 32bit programs in go. If I remember correctly programs would crash intermittently if the initial 512MB memory block requested wasn't contiguous. Does anyone know if this still is the case? Is the solution still to always just use 64bit?

<comment><USER5> As I'm only on 64b right now, I can't quite remember whether that was fixed by 1.0.3 or will be in 1.1 -- but I'm pretty pretty sure one of these is the case.

</comment></comment><comment><USER20> That is pretty neat. I'm glad he mentioned that the Go compiler will not inline functions written in assembly, but it will inline small Go functions.

<comment><USER5> Yeah but the list of restrictions preventing inlining is pretty exhaustive...

<comment><USER21> This is true currently but both the inlining and the garbage collector have improved tremendously over the past year and should continue to get better.

I do wish Go supported an explicit inline modifier that worked like haxe's though (unlike the C/C++ one which is more of a suggestion).

<comment><USER22> Most C dialects (for example, GCC and Clang) provide some form of explicit inline qualifier that forces inlining, for example "attribute((always_inline))".

</comment></comment></comment></comment><comment><USER23> This assembler is awful. I thought that AT&T had a monopoly on ghastly assembly language syntax -- but this article causes me to question that assumption:

      MOVL BX,autotmp_0000+-4(SP)    ; from the article -- terrible!
      MOV EBX,[ESP+autotmp_0000-4]   ; Intel -- comprehensible!

This assembler has an imaginary register called FP.

WTF is up with the center dot?

A programming language should _not_ require Unicode to write -- _especially_ assembly language!

I don't know what's worse: That this assembler exists, or that a project chose to use it after better alternatives had been created!

<comment><USER24> It's amusing that the first line is considered "terrible" but the latter is "comprehensible". For someone versed in modern languages they both look like gibberish.

<comment><USER23> Here's an explanation suitable for someone only familiar with high-level languages:

MOV x,y translates to the assignment operator "x = y" in a high level language [1].

Your program only has access to one giant array called "memory" [2] [3]. So MOV EAX,EBX means "EAX = EBX" in high-level terms; MOV EAX,[EBX] means "EAX = memory[EBX]" in high-level terms ("memory[EBX]" has the same meaning here as in C-family languages like C, Java, Javascript and Python). This choice of operator notation is intuitive, because it's very similar with the use of brackets in other popular languages.

The insane syntax uses parentheses instead of brackets. Which is confusing, since it's _not_ related to the standard meaning of parentheses, grouping for order of operations or function call. So you would say "MOV EAX,(EBX)" in weird-syntax land.

But the insanity doesn't end there.

In the sane Intel syntax, if you want to load the value at memory location 148 + -4 + ESP into EBX, you can probably figure out how you would say it:

      MOV EBX,[148 + -4 + ESP]

The C/Java/JavaScript/Python translation is:

      EBX = memory[148 + -4 + ESP]

In weird-land, the syntax for this operation is:

      MOVL BX,148 + -4 (SP)

To me, it looks like this instruction says:

      Let t = 148
      Let u = The contents of memory pointed to by SP
      Let v = -4*u
      Let BX = t+v

Clearly, there are only two possible explanations for this: The person who came up with this syntax was drunk at the time, or the person who came up with this syntax was high at the time.

[1] In a HLL, "x = y" allows arbitrarily long expressions for x and y, but in assembly language only a few different forms of x and y are allowed. In a high-level language, in the expression "x = y", x needs to be an lvalue, while y can be a more general rvalue. "a = 5+6" is legal; "5+6 = a" is not. Both the left- and right-hand side can be arbitrarily long and complicated, for example the LHS could be "a.b.c.d.e.f.g.h" and the RHS could be "m+n+o+p+q+r+s+t", assuming the appropriate variables exist and have the appropriate types.

[2] Unless you use multiple segments. But you generally don't do that.

[3] Or paging. But you usually let the OS take care of that.

</comment></comment></comment><comment><USER25> Why the \cdot? Is Unicode required to parse assembly?

<comment><USER16> "Source code is Unicode text encoded in UTF-8."

<http://golang.org/ref/spec#Source_code_representation>

Historical reason, TL;DR edition: Plan 9 based compilers, because Ken Thompson.

EDIT: see also mseepgood's response: <http://news.ycombinator.com/item?id=5185334>

</comment></comment><comment><USER26> This is a nice example how to do low level programming while using a safe strong typed language most of the time.

</comment><comment><USER27> I only have 2 problems with Go.

1\. It does have its own package manager but good luck actually finding packages. golang.org's list is out of date and so is every other resource.

This is a serious problem IMO.

2\. The third party web libs are pretty poor. I'm a big fan of Express for Node and prefer just a little bit of goodies ontop of something minimal.

A lot of people like Sinatra/Flask so I'm not the only one who likes this. There's nothing like this in Go.

We have the bits and pieces to make it but no one has stepped up. Right now developing anything for the web with Go is just too annoying, you have to create so many things that literally every other language has had solved for years.

If both of these problems were solved I would insta switch to Go for everything and never look back. It's just so pleasant to program in for all the points you mentioned + more.

<comment><USER28> Try <http://godoc.org/>

Because Go uses URLs for package names its easy to build tools like godoc.org that automatically aggregate packages from the web.

<comment><USER27> It's a good start but it needs many more features to be considered usable. For example, I just did a search for "redis" and about 30 libs came up. Half of them don't even have a description.

How can I know which one to pick at a glance? Asking me to evaluate and profile 30 different libs for just a single task is unreasonable.

Also this page isn't even on Google's first page for when you search for something. I didn't even know it existed until you mentioned it.

<comment><USER29> How do you handle that with any other language? There is no shortage of redis libs for any language.

<comment><USER30> If we look at CPAN [http://search.cpan.org/search?query=redis&mode=all](http://search.cpan.org/search?query=redis&mode=all) , there are a few things right in the search results. We have version numbers, release dates, and a review score. All of those give you a chance at finding a half decent library. The first result was updated a week or 2 ago and has 4 significant digits in the version number. None of it's a guarantee but it's a place to get started.

<comment><USER27> It doesn't seem to be a place to get started for Go though. I just did a search for "golang redis" and it showed me a single perl redis lib?

I like the idea of the reviews and ratings though. Normally I would put almost no value in a rating system but we need to somehow separate the good from the bad without having to dive in and look at and profile code from 20 diff libs on a daily basis.

<comment><USER28> CPAN is the repository for Perl modules, not Go

</comment></comment></comment></comment></comment></comment></comment><comment><USER31> This font renders odd in IceWeasel 10.0.12 , all occurrences of the letter 'e' have their left side 'cut off' so they stand out and are very difficult to read.

Chromium Version 22.0.1229.94 Debian 7.0 (161065) works fine.

<comment><USER32> Same on Mozilla's official Firefox 19 (beta channel). Raising the font size (Ctrl +) makes the issue go away.

</comment></comment><comment><USER33> Except for his bullet about compiler speed, which might be faster than GHC, all of his bullets apply to GHC Haskell too.

<comment><USER34> I write haskell code all day. I spend my day writing it at work (with occasional HN breaks obviously) and then I go home and write personal projects in it. I advocate haskell on a semi-regular basis. I certainly fall on the pro-haskell side of things. But GHC absolutely does not meet all those bullet points.

Compiler speed is not some minor difference, it is absolutely massive. Build times of 30 seconds vs 2 seconds, and that is without counting the 10 seconds of cabal resolving dependencies.

>Go comes with a complete set of documentation available from the command line

GHC does not come with command line docs.

>All Go code is statically compiled so deployment is trivial

GHC links in C libs dynamically, and as far as I can figure there is no way to get static linking working, so I have to have all the same C libs installed on my production servers as my build server. With go you can just upload your binary to a bare bones server and it works.

>but it also has a tool to clean up code: gofmt

GHC has nothing like this.

>And there's also go fix which can automatically convert Go code designed for earlier versions to newer versions

Or this.

Haskell is a great language, but it does not match go's toolchain.

<comment><USER33> > Compiler speed is not some minor difference, it is absolutely massive. Build > times of 30 seconds vs 2 seconds, and that is without counting the 10 > seconds of cabal resolving dependencies

I simply did not play with Go to know the compilation speeds. I believe you that it is a massive difference, and it is indeed a major Go advantage.

> GHC does not come with command line docs.

The haddocks are available from the command line. So I don't know what this means. Hoogle is available from the command line.

> GHC links in C libs dynamically

Ah, I see. Did you try -optl-static? I haven't, but it might work.

> GHC has nothing like this.

There are tools to format Haskell code by certain conventions on hackage.

<comment><USER35> This is a complete aside, but what are the good tools for formatting Haskell code? I've been using stylish-haskell, but it's somewhat limited and barfs on certain Unicode identifiers I like to use. (I should probably file a bug report for that...)

<comment><USER33> Don't know anything better than stylish-haskell, but AFAIK it fits the bullet point completely.

</comment></comment></comment></comment></comment><comment><USER36> You can always search "go programming", and the search engine should give you the results of go that occur in the context of programming, which should usually pertain to the go programming language.

</comment><comment><USER37> Go also offers a set of features in the build system that make it obvious and intuitive to write assembly for different targets, all without having to muck with makefiles or macros.

<http://golang.org/pkg/go/build/></comment>


The MIT Guide to Lock Picking - <AUTHOR> http://www.gregmiller.net/locks/mitguide

<comment><USER2> This is an excellent guide for beginners, and gives a good understanding of how pin tumblers work (and a few other types of locks). Also, there is a good survey of tools and their particular uses. If you are interested in learning about lock picking, read this guide and go down to your hardware store and get a deadbolt to practice on. You can make your own tools, but if you're lazy, Southern Ordinance is a great retailer. Good luck!</comment>


Craigslist "censored" bar disappears, questions linger - <AUTHOR> http://www.sfgate.com/cgi-bin/blogs/techchron/detail?entry_id=71991&tsp=1 <comment><USER2> This seems like a semi-pointless change. Although craigslist might not return this feature, someone else will. As the internet tends to act like a hydra.</comment>


The Coolest Hack I've Ever Pulled Off - <AUTHOR> http://blogs.xobni.com/asmith/archives/45 <comment><USER2> dude, you called your prof gay?!?! Did he let the whole video run? Did the hack include making it impossible to stop the video without unplugging the computer?

<comment><AUTHOR> He probably could have hit Ctrl+Alt+Delete or unplugged the power, but that was it. The program absorbed other keystrokes and mouse clicks.

Either way he was a cool older guy. He had to be cool to put up with 400 teenagers.

I think his biggest reaction was flattery. He was flattered that we made a surprise video for him for his last lecture.

</comment></comment><comment><USER3> The plot for this "hack" is nearly identical to an old episode of "Welcome Back, Kotter."</comment>