That was painful to read through. It's written like a decently formed forum post, but I would expect more from an academic paper. A well formed forum post makes claims and tries to back them up, but often fails to do so in a consistent way. An academic paper presents results from properly formed studies or experiments. A forum post argues that components of Bitcoin which go against the author's political ideas must be flawed because their ideology says so, while an academic paper should present data without arguing philosophy.

As an example of some cringe-worthy writing, we've got:
What's up with this grammar? Why does it matter that it's "like" bitcoin matured at some particular point in time? Are they trying to make readers understand the struggles Bitcoin has been through over the years? If so, why are they doing that in a scholarly article about mining software optimizations?

While I found their section on mining optimizations interesting and potentially actually useful, I don't know why they bundled it together with their poorly argued idea that Bitcoin is not a currency because the block reward halving is too large of a step down each time. Really?
While they admit that "apparently only very small percentage of active mining devices were switched off on 29 November 2012", they make a completely unfounded claim that next time, things will be different. Oh, and of course, this means that there will be fluctuations in value, which no currency should ever have. Real currencies have a price fixed by a government with armies, and Bitcoin needs to emulate that or it will never succeed...

This should really just be split into two papers: one for the mining optimizations and one for the "block halving is bad" whining.

Okay, then let's try to figure out how many bitcoins are owned by someone who just made a recent tx. b91a9fa769b1a401cb5ccd291cd99ff76d530d2fd22f597e743f7c169673bcd8 will do nicely. The two outputs contain 0.17323 and 2.08772 BTC, in that order. Considering there are many wallets out there that will put the change output last, and there is only one input, I think it's safe to assume the .17323 was sent to someone else, while the 2.08772 is still owned by the transactor. The change address has not been used for any other transactions, so we can't get any more information there.

Let's look at the source of those 2.6105 BTC then, 1BjEjcT3Z89pm6r3fRYhdpb43ySUg4Hc1n. The owner of this address is likely owner of the 2.08772 BTC change output. But what more can we discover? This address has only received bitcoins once, from tx ed504fe450deff23e1afa210fb96b0a3cfdced74da747f4bdda0d11440675211. Ah, again it seems this is a change address. Our mystery person started with 2.85938529 BTC, then made two spends, the .17323 mentioned earlier, and the newly discovered 0.59823529 out of this address. The interesting part now is that ed504... has two inputs, and it's highly likely that they belong to the same person.

I kept on following the transactions back in time, and they went a ways. I can be reasonably confident that 17ejmoBxMySL2hoDHgz8oCiv4BdRkxYFVr belongs to the person we're tracking, but its source of bitcoins would hint that our guy got paid at this address, and none of the other addresses in the tx are his. The same goes for 1Cy3HpsfEZEmRLQkZF8269mEzihXrkYeGe and 14wjT7byrZr7i4evq1gHWMdsurYAEtQJg4. With 1LqwYp6yiCwTBi5zsyob52CTRwNWCP6fH, we have the additional benefit of seeing that the address that funded it (1MxSAD) put its change back in itself, heavily implying that 1LqwYp and 1MxSAD are not owned by the same person.

So, what can we take away from this? If we were the recipients of the original transaction, and got this guy's shipping address, credit card number, name, and so on, what could we find out? Well, for one thing, considering all of these transactions have occurred today, it's likely this whole mess I've been looking through is some automated system. We're not yet at the point where individual people will on a daily basis make ~8 small payments purely in BTC. Perhaps it's dividends from a small security, or a bunch of people withdrawing funds from a web service. So if we got a name and shipping address for this, it might be reasonable to think that this guy runs a Bitcoin web service or something. We can also say that it's likely that at some point, this guy held about 2.997 BTC between some of his addresses, but is now down to 2.0877 BTC. However, we cannot say to whom the many outgoing transaction went. We won't be able to tell what other products or services he paid for. We also have based all of this off of educated guesses based on bitcoin amounts to change addresses, decimal precision, and the likelihood of two inputs being from the same person. There is a reasonable chance that we have switched up the guesses of spending and change at some point, which would invalidate so much of this analysis.

Overall, we can't pull out much more information, and we definitely cannot tell how many bitcoins this guy owns in total. It'll be at least .0877, but he may have many more. Heck, for all we know he could be Satoshi, sitting on a million coins from the early days. For me personally, if I were to give you one of my transactions, you would not come close to being able able to tell how many coins I own. Manage your coins well, and you can have a large impact on how well you can be tracked.

Quick google searches will turn up many results for peer-reviewed, highly cited, public articles discussing attacks on SHA-2. These come from many different countries, and cover many old and new attacks. Do you have any evidence to back up your theory that academic research worldwide on SHA-2 is being highly controlled? That's a pretty wild claim to make with no supporting facts.


You mentioned you wouldn't be surprised if Russia has broken SHA-256. Do you believe that the NSA would tell the rest of the government to use hashes that Russia could compromise? What you're suggesting is that the NSA is scheming against the rest of the government, opening them up to surveillance from the NSA and other countries. Again, this is an extraordinary claim. Do you have any evidence for it?

I provided premises which required no stretch of the imagination to accept. Is it unreasonable to think that the entire public research world can come close to matching the intelligence of one small group? Is it unreasonable to believe that the NSA is acting with national security in mind when suggesting Suite B? You have responded to both of these premises with completely ungrounded ideas about conspiracies and schemes. How am I supposed to prove you wrong? You ever hear about the teapot? What could I say to convince you that your ideas are probabilistically unlikely and are not reasonable beliefs to hold?

No. http://keccak.noekeon.org/third_party.html. Are you saying we can't trust ANY of these well-respected third part verifiers? There's been so much public work done on analyzing Keccak, and results are very promising.

The math is entirely different. EC multiplication is nothing like standard multiplication. You want to claim a vulnerability in DSA implies a weakness in ECDSA? Prove it. Give me a link to some research showing that, or point out where in the math there might be some similarity.

There are two big things that I think need to be pointed out here. First, you have an assumption that the NSA can crack any cryptographic encryption or hash that they had a hand in developing (SHA-2 being the main example). Can you explain why:

A) Nobody else in the entire world has publicly managed to even come close to breaking SHA256.

B) NIST only recommended that the US Government move from SHA-1 to SHA-2 once it was publicly accepted that SHA-1 was insecure. Now, they're supposed to use SHA-2 everywhere. If the NSA is so far ahead of everyone else, why would they use hash functions they know to be insecure? As soon as a public release of a vulnerability comes out, their security will be severely damaged. (http://csrc.nist.gov/groups/ST/hash/policy.html)

C) SHA-3 was chosen through a contest where researchers publicly submitted and discussed their hash functions. The chosen winner to become SHA-3, Keccak, was selected because it is clearly fast and secure. It was not developed by the NSA, and there would be very little room for the NSA to "rig" the contest, finding a hash function that they, but nobody else, could find a flaw with. Doesn't this show NIST's intent: to provide a national standard for a secure hash, drawn from the minds of the best crypto researchers, in the case of SHA-2 failure?

The other issue I have with this theory is that Bitcoin does NOT use classic DSA. Bitcoin's signatures are done using elliptic curve cryptography. Neither ECC nor ECDSA come from the NSA (Here, here, and here). A vulnerability in classic DSA does not mean there's a vulnerability in ECDSA.

So now we have two cryptographic functions, SHA-256 and ECDSA. SHA-256 is THE standard hash function, which has no public vulnerabilities and there is no evidence I see that would lead me to expect the NSA can reverse it. ECDSA is a fast, secure signature function that uses very different math for its security. The conclusion? Bitcoin was built using some of the most secure cryptography known to man, using multiple functions from different origins and mathematical backgrounds to ensure its security for ages to come. No NSA conspiracy here.

One of their other posts says that they're using BitPay to convert straight to USD. They're still too afraid to actually have BTC holdings.

The whole point of talking about bitcoins in terms of BTC, mBTC, or µBTC is to ease communication, especially in person where it's hard to verbally say .0245 BTC. Our languages and methods of speaking numbers have reached a point where we are most comfortable speaking numbers with three to four digits to the left of the decimal place and two to the right of the decimal place. Most people would understand if I spoke 123.45 as "one hundred and twenty three point four five" or 432.25 as "four thirty two point twenty five". While we are more comfortable with speaking in the thousands than speaking in the thousandths with 54,321 as "fifty four thousand, three hundred and twenty one" compared to 2.1234 as "two and one thousand two hundred thirty four ten-thousandths", we still naturally gravitate towards discarding low decimal places and lowering the number as a whole.

If 1 XBT = 1 µBTC were to be accepted as the standard today, many of the digits would be so insignificant that they would be ignored in verbal discussion. When we see something being sold for 4.25 USD, we'll usually tell our friends "It's four bucks", because cents are pretty worthless nowadays. Verbal discussions would instead use kiloXBT, or some slang derived from that. If my coffee is two dollars, or ~15,000 XBT, I'm pretty likely to pick up the slang and say "It's fifteen kilobits". Talking about larger purchases would be even more extreme (MXBT?).

I guess what I'm saying is that right now, people would be comfortable referring to most amounts of bitcoins in the range between BTC and mBTC. Switching the digital representations to be based on 1 XBT = 1 µBTC would not remove the prefixes, just make people use different ones. If we're going to be using prefixes either way, why take the extra step of re-denominating? Moving around in verbal discussion between different prefixes may take some years for everyone to get used to, but it will be done, regardless of what the base unit is. We shouldn't fully change our means of referring to bitcoins just because some software will require some readjustment.

We already have multiple threads discussing this exact same topic. I guess the poll is new, but let's all keep in mind that there's a lot of other threads to read through for finding thorough discussion. I guess I'll reiterate what I said earlier (more complete post at https://bitcointalk.org/index.php?topic=220322.msg2330960#msg2330960 )

I voted for none of the above. Using BTC for everything is crazy, and "BTC" should probably get phased out in favor of something more ISO compliant. Though, to defend alternative 2 and metric in general, is it really all that complex for newcomers and non-engineers? Are we not already comfortable referring to weights in kilograms and distances in kilometers and millimeters? We still should solve ISO compliance and database storage, though. Bitcoin should try to conform to published standards, so I support a change to XBT, but I do not agree with XBT's re-denomination to µBTC. I do not believe it is the burden of Bitcoin to work with current financial software. There are two ways databases can support current BTC usage.

1) Databases themselves can be changed. Their precision can be increased and 3-character boxes can be changed to have 4 (I wouldn't be surprised if many systems already have support for more characters), or to ease transition, a new table could be added to store a metric prefix for each listed currency. With existing currencies, not much would have to change. Let's keep in mind that Bitcoin is not the only new currency to be growing. What if Litecoin, along with many of the others, all began being listed in databases? Financial systems would have to adapt to support the variety of names, abbreviations, and denominations. Even the ISO standards should probably be adjusted in the future to accommodate the now common idea of non-national currencies.

2) In case for some reason the databases cannot be modified, we can use an abstraction layer between the database and the presentation. Already, very few end users are going to be typing in straight-up SQL to pull from a database; there's always some sort of software that performs the query, parses it, and displays it in a nice way to the user. Why not have the database store an entry labeled BTC, but storing an amount of µBTC? Whatever software parses the information can present it to the user in any way they want: BTC, mBTC, µBTC, etc. This would really only be a temporary solution until the software itself changes to support the wide variety of currencies that are emerging.

So the way I see it, grau's XBT causes a good thing (ISO compliance) and a not-so-good thing (unnecessary re-denomination). What benefits would we get from denominating XBT as µBTC, aside from compatability with outdated databases (which I don't see as an issue)? With the current exchange rate, we'd probably want to use kXBT anyway so that 1 USD = 7.7 kXBT. Why not go for the ISO compliance without the unnecessary re-denomination? Let's have XBT = BTC, use the metric system which we all are comfortable with, and be done with it. We can still use mBTC (mXBT) and µBTC (µXBT) for the handy comma separators.

I'd like to point out that while switching to XBT is important, there is no commonly accepted denomination of XBT as compared to what we currently know as BTC. For example, in the thread grau linked to, the original post proposed XBT as a name for mBTC, while grau later posted the more database compliant idea of having XBT be 100 satoshi, or 1 µBTC.

There are really multiple problems here. The first is the issue with BTC being non-compliant with ISO standards. The second is how we refer to very large or very small amounts of bitcoins. A third is that current financial databases have precision to two decimal places, and no more.

grau's proposed change to a standard of 1 XBT = 1 µBTC attempts to solve the first and third of these issues. It is not a solution to the second issue (which is the topic this thread is intended to be about). As one USD would be equivalent to ~7,700 XBT at the current exchange rate, we still have the issue of very large numbers. If XBT are more reasonably talked about in multiples of 1000, a reasonable solution would be to use kXBT, so that 1 USD ≈ 7.7 kXBT. This is just as much of a decimal place shift as BTC -> mBTC. This does not mean 1 XBT = 1 µBTC is a bad idea, but it is not a solution to the issue this thread was started to talk about, and it is not a substitute for the metric system. As such, I see it as a very out of place option in the poll.

Here are my preferred solutions to the three problems. XBT is a great term, and I'd like to see it in use. I do prefer to have BTC-XBT parity (that is, XBT is simply an ISO-compliant name for BTC). This is the simplest solution, gaining ISO compliance without having debates about whether it should be equivalent to mBTC or µBTC. It solves the problem without forcing users to learn a completely new system for representing their bitcoins. For a user who's more out of the loop and less tech-savvy, a simple rename is easier to understand than a rename with a complete re-denomination.

The solution to the second problem is easy: use the metric system. I fully support the use of mBTC and µBTC, or with BTC-XBT parity, mXBT and µXBT. I don't understand the people saying "Most currencies don't use metric, so we shouldn't either". If most places in the US use the imperial system, does that mean we shouldn't switch to metric? I would argue that both the 100-centric currency system and imperial system are inferior to the standard of metric, and that both should switch to it. As for the naming and push for usage, I feel this is something that will happen with time. As long as people are aware that metric is the way to go, people will start using it in discussion just because it's easier to use. A waiter at a restaurant will realize that it's simpler to say "23 millibits" or "23 millibitcoins" than it is to say "point zero two three bitcoins". We will likely have a gradual change from bitcoin to millibitcoin (I've already started to use it where appropriate), with mBTC-dollar parity being the point where just about everyone uses it. Slang, such as millie, gavin, mil, etc, will develop with time, but that's not something we can democratically vote on or enforce. If we start using millibitcoin, slang will come.

The third issue is easily solved in software. There is always an abstraction layer between the data stored in a database and what is presented to users. That is, the denomination stored in the database does not have to be the denomination presented to the user. Financial institutions can store bitcoin count in µBTC (µXBT) so that they have their two decimal place precision, then present it to anyone who wants to reference it as BTC or mBTC (XBT or mXBT). In the unlikely case that each database entry HAS to have only three characters and there is no abstraction layer whatsoever, they could simply add another table to the database to hold the metric multiplier for each currency stored, or even just change the database. There are so many solutions, and it's not something Bitcoin needs to solve. If the future of currency really does lie in a wide variety of cryptocurrencies, all with their own preferred abbreviations and metric prefixes, it may be the burden of the financial institutions to change their software to accept a wider variety of numbers. Just as Bitcoin is making governments realize that their current systems are inadequate for handling decentralized currency, Bitcoin and the currencies that follow will make financial institutions realize that their systems must be changed as well.

rBbQDesKygEU7ojxQ7835N1BHZ9nRxeFbT

How about a 2-of-2 multisig address? I believe it's in development now.

https://en.bitcoin.it/wiki/BIP_0011
https://en.bitcoin.it/wiki/BIP_0019

Okay, then let's reduce the default transaction fees. Done. There's no need to completely revamp the Bitcoin protocol, hard fork every client in existence, and change the very definition of the word "bitcoin".

btccharts isn't working for me either. Bitcoincharts seems to be pretty up to date though. I was confused for a while there, when everyone was saying "Oh no, crash! Crash!" and btccharts showed a nice 20k bid wall at $9.

Okay, I get your point now. I guess the way this mixing would solve that issue is to make it meaningless to know that addresses are related. Sure, you can see that four 25 BTC outputs have come together to pay 100 total BTC, but since mixing occurs between each transaction, you can't trace them any further back. You can't tell who owns them or what those coins have done in the past, and if the mixing has been done properly (like in Casascius' last post), there won't be any cases of "Oh, I see from tx1 that someone owns addresses A,B,C and I see from tx2 that someone owns C,D,E. Therefore, the same person owns all 5 addresses."

Whoo, you guys type fast. 3 more replies since I started writing this up.


In the original post, it was mentioned that in the future, most people will be storing only the unspent transactions, not the entire history of everything. Many of the blockchain pruning ideas implement something similar, and I think it's pretty likely that the solution that finally gets implemented will only store unspent transactions. While casascius' method would bloat the blockchain with transactions, it would dramatically reduce the side-chain that only stores unspent transactions.

Couldn't you say the same thing about this mixing? It could be expanded pretty easily to have Alice's mix offer be "Hey, I'm running a 5 BTC mixing party. Let's get everyone in on this same transaction." If a lot of people are throwing in their 2's and 3's, it'll get difficult to find the original pairs.

The reason this coin mixing strategy reveals that addresses belong to the same wallet is because of addition. Let's say you see a tx with inputs of value 2, 3, 9. The outputs are of value 5, 5, and 4. It's pretty easy to tell, knowing that this is a mixing tx, that the 2 and 3 came from the same source. We also know that the output of 4 belongs to the owner of the input of 9. What we've gained is not knowing who owns each 5 output.

With your proposed solution of just having two transactions per transaction, we still have the same problem. Let's say Alice is paying 5 BTC using inputs of size 2 and 3. Bob has another transaction where he pays 13 BTC with two inputs of 7.

Inputs: 2 3 7 7
Outputs: 5 1 13

It's still pretty easy to distinguish between the transactions. Clearly, one person owns the 2 and 3 input addresses, and someone else owns the 7 addresses. We can still tell that addresses are related. With both ideas, the only way to avoid this is to have multiple ways to combine input values to reach the output values (which is difficult when bitcoins are divisible down to 8 decimal places).

Inputs: 1 4 4 2
Outputs: 5 6

Now there's two possible solutions. 1 4 4 2 or 1 4 4 2. Casascius' idea of limiting mixing sizes to 5^n would help ensure that after the first mixing, each output should be of a fixed size. That should help reduce these concerns.

Getting back to the original issue: yes, using this mixing to combine coins would still often show that some of the source addresses are held by the same person. The strength is that that knowledge cannot be used to track future transactions. You become detached from your past, breaking any string of transactions people might be using to track you. Now, if you have 0.3 and 0.7 unspent tx's, and you happen to come across someone else with exactly 0.3 and 0.7, you can make it uncertain that you own both addresses.

I like the idea. I could imagine a client with an "Automatically mix coins" advanced option in a menu, along with a quick dialog box about the anonymity benefits, but constant transaction fees. The developer would probably want some sort of limit to prevent ignored wallets from running themselves dry from transaction fees over a long period of time (Maybe something like "I'd like to spend 10 bitcents of transaction fees on mixing, then stop", although this could definitely be worked out later).

The ability to combine a bunch of tiny bits of coins together without completely opening them up to tracking ownership sometime in the future is the best part of this. It'll help scalability and people who prefer to keep their coins consolidated at a few addresses without sacrificing anonymity.

Two issues.

1) People don't use one address for everything they do. Businesses, especially, will often create one new address for every customer or transaction. In order to calculate the the "turnover of capital", you'd need to know every address they own.

2) The best methods I know for taking one address and figuring out which other addresses are owned by the same person are checking for multiple inputs and checking for the output that looks more like the change output. Addresses with a lot of transactions back and forth between them would also be likely, though not certain, to be connected. It's extremely easy to avoid all of these with proper control of your addresses. Avoid multiple inputs by intelligently selecting outputs, and by making a series of combining transactions. Avoid obvious change outputs by looking over the input values, fees, and the real cost of the transaction and selecting proper numbers. Avoid having addresses interconnected with transactions by using a lot of addresses; one per customer or something. If you're careful, it's easy to be very anonymous with bitcoins.

I think he's referring to Elliptic Curve Digital Signature Algorithm, not the Electrum server at ecdsa.org. Bitcoin keypairs, including deterministic keys, are created with ECDSA. Like most public key cryptosystems, it is never impossible to carry out an attack; it is only extremely impractical. That's (probably) why vuce is saying ECDSA is only assumed to be secure. If you need complete mathematical certainty of impossibility, there's bigger problems than just deterministic wallets.

I agree. I love the general design, but having all three large BTC's be tilted makes the whole bill look a little tilted. Feels like there's another nearly-vertical axis that nearly approaches the strength of the the true vertical axis. I love "Strength in Numbers", but "Vires in Numeris" makes it feel more like flavor text on a bill and less important to the usage or understanding of the bill.

Well, I guess if we're going to organize a response, we should think of the best way to respond to each point.

Volatility: This one is an issue, but one that I believe will work itself out over time. Maybe some references to bitcoincharts over the past 6 months would provide hard data. Maybe someone else has a better idea here, because the volatility is probably keeping businesses away. Oh, how about Bit-Pay? It provides quick conversion straight to USD so that volatility doesn't matter and merchants can accept BTC without risk.

Vulnerabilities: Open source. According to https://en.bitcoin.it/wiki/Common_Vulnerabilities_and_Exposures , the last real exploit was in August 2010, and that was handled with a blockchain fork. Since then, we've been doing great. Client devs are doing a good job of patching up issues before they become a threat. Emphasize that the protocol itself has had no issues; all problems are with bugs in client code.

51% Attack: There was a recent thread where plenty of people explained why a 51% attack would not have much of an effect. It might be worth tracking it down. Maybe find some quotes from large pool operators where they explain that they're not going to collaborate on an attack? Maybe bring up p2pool as a helpful solution.

Any other ideas?