Bitcoin Threat Model

[kiba]

Please note, this is a revised version of an email that I sent to a guy who know something about security.

--------------
1. Who are our adversaries?

Corporations who have their business destroyed by bitcoin competition, or in the process of getting destroyed. Government who are keen to control their economy through central banking.


2. What are their capabilities?

Security and cryptanalysis knowledge. Nation-state level resources. Ability to use force and threats to keep people in line.

3. What are our countermeasure?

Network effect; strength in number. Promoting, and growing the economy.

Security and cryptanalysis knowledge. Constant discussion about security.

Decentralization effort such as BitDNS. I open sourced my prediction market; however, we do not have open source exchange markets and other critical infrastructure.

The head cannot be easily cut off. The authority will find it difficult to haul away Satoshi Nakamoto, but it cannot be said the same for other people. Already growing the number of hacker who know how bitcoin work and can improve it.


4. Measures we could take:

Create a dedicated tiger team whom jobs is to find security flaws within the network.

Offer security bounties as incentives.

Open source key infrastructure such as trading sites.

Create protocol documentation.

"Kill switch" for bitcoin banks system. (Really, it mean that everyone who hold bitcoin balance on the behalf of somebody else.)

[FreeMoney]

2. What are their capabilities?

Security and cryptanalysis knowledge. Nation-state level resources. Ability to make laws and enforce them.

 

This is not reality. If government could enforce laws there would be no drugs, no murder, no theft. These things plainly exist. Government cannot enforce law, but only uses it as a pretense to capture adversaries and control those who produce for them. This may be important when considering security. Also there is no monolithic government, but only individuals who are acting in their interests or out of fear.

And I would love to see a technical analysis of the bitcoin software.

[kiba]

This is not reality. If government could enforce laws there would be no drugs, no murder, no theft. These things plainly exist. Government cannot enforce law, but only uses it as a pretense to capture adversaries and control those who produce for them. This may be important when considering security. Also there is no monolithic government, but only individuals who are acting in their interests or out of fear.

Updated my analysis.

[em3rgentOrdr]

great analysis kiba!  Thanks for starting this discussion.  Bounties for exposing security vulnerabilities is an excellent and very creative idea!  Where do I pledge or send bitcoins to?  How will the review committee that evaluates any claimed vulnerabilities be structured/governed?  How to ensure that coders who contribute changes to bitcoin source code don't secretly deliberately include faulty obfuscated code so that they can fix their broken code to collect the bounty (or avoid similar other conflicts of interests)?

[kiba]

great analysis kiba!  Thanks for starting this discussion.  Bounties for exposing security vulnerabilities is an excellent and very creative idea!  Where do I pledge or send bitcoins to?  How will the review committee that evaluates any claimed vulnerabilities be structured/governed?  How to ensure that coders who contribute changes to bitcoin source code don't secretly deliberately include faulty obfuscated code so that they can fix their broken code to collect the bounty (or avoid similar other conflicts of interests)?

Err, just start a bounty thread?

[RHorning]

One of the reasons that I've been trying to document the bitcoin protocol is precisely so we can have a programming language agnostic document for reviewing the software and to find potential flaws in the protocol.  The key is documentation, where the secrets aren't hidden in the code.  You may not know how to program software, but reading protocol documentation like this can also cut through some of the extra stuff that is necessary to simply make the software work which can also be a distraction when reading the straight software code itself for understanding.

I also want to add here that I've been building on the work of a whole bunch of people when writing that documentation, and I've got to give a whole bunch of kudos to theymos both for answering my silly questions and correcting some of the errors I've made in terms of assumptions and even misspellings.  I'm not doing that effort alone.  There is quite a bit more to be done on that documentation effort, so if you are interested in helping out, please join in that effort!

There is also a need to push for alternate implementations of the protocol.  I know of at least efforts in Python, C#, and Java that are at various levels of completion right now to do just that in addition to the current C++ version that is the main client.  To me, that helps so far as eliminating any sort of central authority over the spec and democratizes the network in the long run.  If one particular implementation of the protocol goes bad, the rest of the network will continue to move along without it, or perhaps the "rogue" implementation will expose a fatal flaw in the protocol.  Either way, it helps to make the network as a whole all that much better.  It also makes the key to protecting the network more about the protocol itself rather than having to do a full security audit of the particular client (although that could be done too).

Recruiting people that may be interested in Bitcoins is useful, and perhaps as much as anything else we need people from a more diverse background to get involved too.  Lawyers, merchants, doctors, engineers (of disciplines less related to information technology) and even plumbers, carpenters, fast-food burger flippers and department store sales associates are needed too.  Some of it is to find out what they want and need or would like to use Bitcoins for, and at the same time get them to poke at the software.  By far and away some of the best software analysis I've ever had came from people who had a very different background and did things that I never expected... usually not "experts" but rather very ordinary people who pushed a button or did something in a way I never would have ever thought of trying.  School teachers in particular are very rough on software testing and don't pull punches.

In terms of legal protections, I think the whack-a-mole issue that comes from peer-to-peer networks is perhaps the best and most powerful feature of Bitcoins.  This kind of software is a hydra that simply can't be killed, and governments have a very hard time coping with it.  Repeatedly I have many people on these forums insisting I consider a client-server with a fixed address for some project ideas I've proposed, and one of the reasons I am against that is in part because of the role that an oppressive government can have upon somebody whose house can be searched & confiscated.  I think more effort out to be done to encourage more peer to peer programming using Bitcoins, but it takes thinking along those lines to get that to happen.

As for possible attacks, the presumption of a government entity wanting to engage in an attack is based upon a belief that governments have command of limitless funds and resources.  That implies both smart people on the government payroll and access to equipment like super-computers and server farms of incredible size.  I suggest that the emperor has no clothes on this point so far as the combined computing power of ordinary people is by far and away much larger than what the government has, but it may not be so easy to pull that many people together to fight the government.  It would be interesting to see what sort of government-sponsored effort to wipe out Bitcoins might be, but I think only a brute force attack would really be effective.  It would involve hundreds of people running tens of thousands of computers at incredible cost.  More to the point, such an attack would have to be approved at a high level where Bitcoin would have to be perceived as a substantially greater threat than other potential enemies.  Even though you as an ordinary citizen may not think that cost is a huge issue, it does become something very important for those who have to manage the resources of a government, even a totalitarian government.  One good defense here is also to make any attack to be far more expensive than any possible gain.

Keep in mind that many of the cryptographic techniques used by Bitcoins have been reviewed by the top people in cryptology and have been vetted to one degree or another, even if the specific assemblage as used in Bitcoins hasn't been.  The neat thing Satoshi did here was to put the whole thing together in one neat package from a wide diversity of ideas that have existed for years in computer technology.  I never considered the idea, and I was certainly aware of all of the pieces as separate elements.  I do give Satoshi kudos for coming up with the idea in the first place and that certainly was a stroke of genius.

Anyway, this is a good summary you've done here Kiba in terms of outlining some of the major issues facing Bitcoin as a project.  There are some real threats to Bitcoin, but there are also protections and defenses which need to be realistically considered as well.

[em3rgentOrdr]

great analysis kiba!  Thanks for starting this discussion.  Bounties for exposing security vulnerabilities is an excellent and very creative idea!  Where do I pledge or send bitcoins to?  How will the review committee that evaluates any claimed vulnerabilities be structured/governed?  How to ensure that coders who contribute changes to bitcoin source code don't secretly deliberately include faulty obfuscated code so that they can fix their broken code to collect the bounty (or avoid similar other conflicts of interests)?

Err, just start a bounty thread?

I nominate kiba as escrow!

[kiba]

Bold the heading, incorporated one of RHorning's suggestion.

[em3rgentOrdr]

There is also a need to push for alternate implementations of the protocol.  I know of at least efforts in Python, C#, and Java that are at various levels of completion right now to do just that in addition to the current C++ version that is the main client.  To me, that helps so far as eliminating any sort of central authority over the spec and democratizes the network in the long run.  If one particular implementation of the protocol goes bad, the rest of the network will continue to move along without it, or perhaps the "rogue" implementation will expose a fatal flaw in the protocol.  Either way, it helps to make the network as a whole all that much better.  It also makes the key to protecting the network more about the protocol itself rather than having to do a full security audit of the particular client (although that could be done too).

Great analysis in your post, RHorning...  Decoupling protocol from implementation is a great idea and extremly important for the growth of bitcoin.  People should be able to implement bitcoin however they like, and in the future, I envision implementations on FPGAs, assembly language, micro-controllers, manufactured in silicon, ASICs, inside internet routers, on webpages (eg php, javascript), on all variety of high-level languages, and last but not least: carrier pigeon protocol, just in case WW3 breaks out and the people with the nukes reduce humanity to the stone age.

[genjix]

RHorning spot on. Nothing to add.

[RHorning]

and last but not least: carrier pigeon protocol, just in case WW3 breaks out and the people with the nukes reduce humanity to the stone age.

While a major global thermonuclear war would make life miserable for a great many people and cause some heartaches, I don't think it would necessarily erase all technology.  Still, it is interesting to think about alternatives to the current system of communication and look at alternative.

The funny thing about IP over avian protocol is that a carier pigeon has the highest current bandwidth as measured in terms of bits transmitted per second.  The method has drawbacks, of course, but strapping a thumb drive on a pigeon can certainly haul a whole bunch of data in a short period of time, and do so rather cheaply. Sending a hard drive via FedEx is a good way to ship data over intercontinental distances if you have large quantities to transmit, which really is just a variation of that protocol.  While optical transmission methods are getting better over time, a standard "hard drive" has consistently outpaced and in fact grown faster in terms of data density and therefore using a courier for data transmission has been by far more productive to ship large quantities of data than using a communications link.

The worst I could see computer technology getting to in a technological collapse is having chip production get reduced down to the 7400 chip series of discrete gates.  The Apollo Guidance Computer which took astronauts to the Moon was built with that technology, as was the Altair computer that started the microcomputer revolution.  While that is a step back, surprisingly something like Bitcoins might survive even that sort of "downgrade" of computer technology, where communications would happen over a simple modem or modem-like telecommunication system.  Once the chip production was going again in any sort of production line, Moore's Law would kick back in all over again as well with all of the benefits (or curses) that come with that kind of technology development.  I don't see a reboot of civilization after such a major war going through the vacuum tube stage of computers like the ENIAC or the UNIVAC systems.  It might be funny to see Bitcoins implemented on something like an Apple II computer, but I think the basic concept could easily be done that way at least with a "thin client" protocol.

[S3052]

On the question about counter measures:

How would the customer funds be safe if someone would shut down the exchange websites?

Are the funds ( BTC and / or USD ) be protected and can be retrieved or are they gone?

[em3rgentOrdr]

and last but not least: carrier pigeon protocol, just in case WW3 breaks out and the people with the nukes reduce humanity to the stone age.

While a major global thermonuclear war would make life miserable for a great many people and cause some heartaches, I don't think it would necessarily erase all technology.  Still, it is interesting to think about alternatives to the current system of communication and look at alternative.

...

The worst I could see computer technology getting to in a technological collapse is having chip production get reduced down to the 7400 chip series of discrete gates.  The Apollo Guidance Computer which took astronauts to the Moon was built with that technology, as was the Altair computer that started the microcomputer revolution.  While that is a step back, surprisingly something like Bitcoins might survive even that sort of "downgrade" of computer technology, where communications would happen over a simple modem or modem-like telecommunication system.  Once the chip production was going again in any sort of production line, Moore's Law would kick back in all over again as well with all of the benefits (or curses) that come with that kind of technology development.  I don't see a reboot of civilization after such a major war going through the vacuum tube stage of computers like the ENIAC or the UNIVAC systems.  It might be funny to see Bitcoins implemented on something like an Apple II computer, but I think the basic concept could easily be done that way at least with a "thin client" protocol.

Good point.  Actually someone did make a fully-functional 4MHz computer http://www.homebrewcpu.comrunning a modified Minux OS which currently serves webpages http://www.magic-1.org and even telnet into telnet://magic-1.org to play games on entirely out of 7400 series gates:

I'm calling this computer the "Magic-1", or M-1 for short.  It's a one-address, microprogrammed machine with  one-byte opcodes.  It features 8/16-bit data operations, functioning on an 8-bit wide data bus with 16-bit addresses (mapped via 2K-byte pages into a 22-bit physical address space).   Code and data address spaces can be shared or disjoint, giving each process up to 128K bytes of addressing.   User and supervisor modes exist, along with hardware address translation, memory-mapped IO, and support for DMA and externally-generated interrupts.  As far as components go, it is built entirely out of 74LS and 74F-series TTL devices plus modern SRAM and EPROMs for the microcode store.   After redesigning the memory access mechanism several years into the project, Magic-1 runs at 4.09 Mhz.

[RHorning]

On the question about counter measures:

How would the customer funds be safe if someone would shut down the exchange websites?

Are the funds ( BTC and / or USD ) be protected and can be retrieved or are they gone?

This is one reason I prefer peer to peer solutions as opposed to a client-server protocol.  If you put your money (LR dollars or BTC) into Mt. Gox, you depend entirely on the server operator and his security protocols for the exchanges.  I'm not dissing Mt. Gox here as it is a very valuable service to the community and is becoming a defacto standard place to do exchanges, but a court injunction or some idiot blowing up a car bomb next to the physical server could in theory take out the website.  That can be fixed after a fashion with backup sites and real-time double databases (MySQL supports such a feature where you can have one server acting as "backup" recording all of the database transactions and then "instantly" switch to the backup database as primary if necessary).  Still, it becomes dependent upon what that server operator may or may not do in that situation. 

A court injunction is real bad so far as keeping a backup site running would be seen as contempt.  Well, I suppose that is bad for the server operator but not the people using the exchange.  A "failsafe" that could be put into Mt. Gox where at the press of a single button or something similar could "flush" the Bitcoins back out to the users who put those bitcoins back in or have the "backup site" simply perform that flush if the main site went down without some sort of password.  Mt. Gox as an exchange would still be down and the site owner perhaps facing criminal charges, but the coins themselves (and presumably the Liberty Reserve dollars too) could be returned to the rightful "owners" of that money.

There are counter measures, but if you get involved in some of these exchanges, you should be aware of the potential risks.  If you have a claim to those coins through the Bitcoin network, this isn't a risk at all at least along those lines and the coins are as safe as the network as a whole.

[kiba]

There are counter measures, but if you get involved in some of these exchanges, you should be aware of the potential risks.  If you have a claim to those coins through the Bitcoin network, this isn't a risk at all at least along those lines and the coins are as safe as the network as a whole.

I incoprorated your excellent countermeasure suggestion.