text:
What could be the consequences of many bitcoins being lost out of circulation if people lose their wallets?
If for some reason many people lose their wallet files then many bitcoins are effectively taken out of circulation.
Seen as it's not possible to tell as far as i know if bitcoins are actually disabled in this way, so to speak, I'm wondering what are the implications for this.
I thinking of the hypothetical doomsday scenario whereby it's a significant percentage of the economy. Lets say it was enough to significantly reduce the volume on the markets.
For example a large group of people who hold a great many and live in the same city are subjected to a large EMP. :-)
Would this effect the value of bitcoin indirectly?

I believe this is a related question about returning lost coins into the reward block

Economic theory tells us the price would rise.  It would have a deflaitonary effect on bitcoin economy.  However because bitcoins are so easily divisible it would not impact the ability for the network to function.
If 90% of bitcoins were lost/destroyed that would leave 2.1 million "whole" bitcoins in circulation.  This wouldn't be an issue because currently bitcoin network supports transactions down to one satoshi (0.00000001 BTC) which is 210 trillion discrete units of exchange.
It is possible to allow smaller units of exchange however I will illustrate that is unecessary.  The world's money supply (M0) is valued at ~ $20 trillion.  If entire world switched to using bitcoin for all commerce the value of a "whole" bitcoin would be $9,524,000 each.  However the smallest unit 1 satoshi would be worth $0.10 Even with 90% of bitcoins destroyed/lost there would be sufficient units remaining to allow commerce down to a 10 cent granularity with Bitcoin replacing the entire world's money supply.
It would result in some changes in language.  Obviously most people wouldn't value things in terms of bitcoins but rather in smaller units like satoshi's (0.00000001 BTC).
As an example a fastfood meal could be priced as $5USD, 0.00000053 BTC, or 53 satoshi's. Obviously 53 is far easier for humans to express than 0.00000053 BTC despite them having equivelent value.  Given the high value of a single BTC, "whole" BTCs would rarely be used other than to express things that are currently express in millions of dollars (like salaries of celebrities, values of corporations, size of national debts, etc).
Satoshi is used as an example but alternatively SI prefixes could be used. For common usage prices in fractional μBTC (micro bitcoins) makes the most sense with 1 μBTC = 1E-6 BTC.
Some examples:
"Man gold broke 200 μBTC today"
"The US Congress raised the minimum wage to 1.50 μBTC effective Jan 1"
"I got the job.  Starting salary is 8,400 μBTC a year"

So what if we lose more than 90% of coins? For example, what if we lost all coins?

Well if we literally lost all coins (as in ever single satoshi of all 21M BTC) then it doesn't really matter does it.  The blockchain has no value.  Simply start fresh with a new blockchain.

Hmm but even when all satoshis are lost, no one is aware of it right? Perhaps the transactions are no longer moving, but that isn't enough evidence that they are in fact lost and not just "stored".

Correct. There is no way to know how many coins are lost but we can look at coins that haven't been in x period of time to get an upper limit on the number of lost coins. i.e. if 8 million coins have moved in the last 90 days then we know at least 90 days ago the network had at a minimum 8 million usable coins.

The value of a bitcoin would increase because the supply would be lowered. Because bitcoins are pretty much infinitely divisible, the usefulness of bitcoins and the ability to use them in commerce would not be affected.
However, it does create one problem. It makes the future supply of bitcoins much harder to predict. If you take the absurd extreme where, say, 95% of the supply of bitcoins is believed to have been lost, you always have the risk that someone will acquire the ability to spend a large sum. If that happens, the value of bitcoins will drop due to the sudden supply increase. If there's a realistic fear that this will happen, people will be less willing to store their assets in bitcoins.
This fear can increase the velocity of bitcoins through the marketplace. It can also increase the interest in exchanges between bitcoins and other currencies, as people prefer to hold wealth in a currency with a more predictable supply.
Although this outcome is not that likely, I believe it was a mistake not to design something into the protocol from the beginning to deal with it. I discuss one such solution in my answer to 'Why doesn't Bitcoin return lost coins into the block reward. Though I realize that 20 years is not long enough.

BitCoin isn't "pretty much infinitely divisible". In fact, only being able to divide it by 10^8 portions means that we will start facing granularity problems when we lose more than 90% of the coins, as demonstrated by the maths in DeathAndTaxes's post.

Would this effect the value of bitcoin indirectly?

Simply put, yes. If the number of bitcoins in circulation were to decrease the bitcoins that are still in circulation would be worth more. That is, of course, if the faith in Bitcoin as a currency remains the same.
In practice, if a huge part of the bitcoins would suddenly disappear there would probably be some sort of panic. Trying to say exactly how this would affect the value of Bitcoin would mostly be speculation though.


text:
what is the relationship between the blockchain size and the transaction volume on the network?
I'm thinking about the scalability of the system with regard to the transaction volume. Is it possible to predict future blockchain size for a certain future transaction volume? Is the relationship directly proportional?
Are there any estimates compared to traditional fiat currencies transaction volumes?

The Bitcoin wiki page on scalability looks at what things would be like if transaction volume was similar to that of Visa. It states:

Today the Bitcoin network is restricted to a sustained rate of 7 tps
  by some artificial limits. These were put in place to stop people from
  ballooning the size of the block chain before the network and
  community was ready for it. Once those limits are lifted, the maximum
  transaction rate will go up significantly.

The page also contains various calculations on what the implications are of the Bitcoin network matching Visa's rate of transaction processing (which the page states as being around 2,000 transactions/sec). Figures on storage required for the blockchain are included in the calculations, but it's clear that as Bitcoin grows the core backend nodes will require commercial levels of investment in hardware & systems.

Well, there are upper per-block size limits (about 500KB per block) based on the currently implemented protocol.  So max levels might be 5x or 10X current levels.
When those levels get hit, then it will be levels of fees that determine transaction volumes, and the many microtransactions seen today will no longer be justifiable.

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/

sort: votes


text:
Can you use an external PCI expansion box for mining?
I'm wondering if plugging cards into something this external pci expansion box would be effective in a mining setup.
I guess it depends on how much bandwidth is used, but I don't know how bandwidth intensive the mining process is. Has anyone here used a setup like this for mining?

Maybe you could go nuts with several plugged into one motherboard!

The amount of bandwidth used for mining is absolutely trivial, so bandwidth won't hurt you much here. Of course you would have to use something like this box because this one doesn't appear to be nearly deep enough for a full-length video card. Using the backplane from this box in a custom enclosure might be worthwhile.
The secondary problem you'll run into is power. This unit appears to have just enough power supply to power the communications between ports. An additional PSU will be needed for the GPUs themselves which, conveniently, typically draw most of their power from four or six pin connectors.
So in short, using this backplane in a separate enclosure with an external power supply (and a lot more airflow) seems pretty viable to me. Of course I haven't personally done this so I make no guarantees, but if someone has actually attempted this I'd love to hear about it.

I've updated the question to link to a box which includes a psu

The PSU is still inadequate. Three Radeon 5830s under load, for example, draw over 500 watts combined. The 220W PSU that comes with the new unit is still grossly inadequate for the task.

It's insane really how much they draw!

Unless of course you used FPGA cards instead of graphics cards

That's... That's brilliant... Where do I sign up???

I don't know how hard they are to set up but these seem about as  mature a solution as you could get

Oh they finally got rid of the obnoxiously bulky and expensive cable requirement? Dual X6500s for $600 isn't bad at all...

Unfortunately, this particular device provides four ordinary PCI slots (not PCI-Express). There is currently no sensible mining hardware that connects to a PCI slot.

This NA211A one is more like it. I'll update the main question

That one looks like it might actually fit a full-length card too. Still not nearly enough ventilation of course...

You'd have to get power and cooling right, and you'd have an issue with double-width cards. But it looks possible.

I think that one takes a single double slot card, and two other single slots, but not enough power! Top graphics cards these days are crazy

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
How to generate PPCoins using Proof of Stake?
PPCoins uses Proof of Stake (in addition to Proof of Work) to generate coins.

Must the client be online for this generation to happen?
Do PPCoins stored in any web wallets / exchanges generate coins for you?

Yes
Yes, but it's not a great idea to do that. Coins need to sit in a wallet for at least 30 days before they start generating stake. I would never leave coins in an exchange\online wallet idle for 30 days.

Followup - should be client be online all the time? What about the first 30 days? After that period, can I turn it on once in a while, or should be be online all the time?


text:
Do "the official bitcoin developers" control Bitcoin?
Is there one person or organization that controls Bitcoin?
What if Gavin Andresen, the lead developer, or Bitcoin Foundation, "the official bitcoin organization", decide to change something? What if they release a new version of the software that changes the coin limit, or enforce government regulation?

I of course know the answer, I'm just looking for a canonical written answer so I can refer people who don't know the answer to this resource. Is there a FAQ entry? A good article that explains it?

At the moment in my opinion, Gavin does indeed control Bitcoin Project to some extent. He is widely recognised as the main developer behind it and could probably push his authority on a lot of subjects if he so desired. However, I am under the impression that he would not perform such actions - they would undermine the credibility of Bitcoin and be bad for everyone.
He does appear to have a lot of influence over a lot of aspects of the Standard Client, the Protocol and overall behaviour exhibited by Bitcoin. He will most likely have the final say for example on the subject of block size limit. However, if he would change any more major aspect of Bitcoin that would undermine a lot of other people's work, say by changing the mining algorithm hard coded into the ASICs, it wouldn't be long before he would lose his position of authority and possibly create a hard fork.
So to sum up, at the moment Gavin is de facto the person who controls Bitcoin on its most basic level, and he will most likely hold that position of authority only as long as he remains a "benevolent tyrant" so to speak.

I somewhat agree, but I would qualify your answer further and emphesize that there are something things that Gavin, or anyone else, just can't change. Even if somehow 99.9% of Bitcoin developers, users, and miners agree to it, Bitcoin will never have more than 21,000,000 BTC. There are a few other properties that will never change, or if they change it will create something new, but not Bitcoin.

@ripper234 Even if somehow 99.9% of Bitcoin developers, users, and miners agree to it I disagree. If that were to happen, the word 'Bitcoin' would almost always refer to the new Bitcoin network. There might be some section of the internet that preferred to deal in 'old bitcoins', but they would be in the 0.1%. That being said, getting 99.9% of any group to agree on something isn't possible for groups larger than 3 people.

@ripper234 It could be done, one would just need to create a hard fork. This, however, would undermine a huge part of the Bitcoin project.

@NickODell "Getting 99.9% of any group to agree on something isn't possible for groups larger than 3 people." Which is exactly why the Bitcoin project will break up owing to disagreements over the 21M limit. History shows we like to create money out of thin air when we have that option. In Bitcoin, we have that option.

@Manish Since we already have one halving day behind us and no forks about the limit thus far, I think we are in the clear.

@ThePiachu Let's see what happens when the price of a bitcoin is $10,000 and it's an important part of the economy (and not just for playing SatoshiDice). Also, see Nassim Taleb's Thanksgiving turkey.

@Manish We will see in 3 years and a bit then.

History proved that to be wrong :)

Well, some devs have been ousted, some have forked, some people have had disagreements over which way Bitcoin development should go, and it seems Bitcoin is on the more conversative side of things. Turns out block limit is more divisive issue than total coin cap :D

These might be a little stale, but:
Development process:

http://en.bitcoin.it/wiki/Development_process

Release process:

http://en.bitcoin.it/wiki/Release_process

But bitcoin is controlled by the economic majority (those who will buy the coins that are issued after the new software is released):

http://en.bitcoin.it/wiki/Economic_majority

Answers should be a bit more than just links.

Duplication means more places where stale or incorrect information is found.

Yeah, all I'm saying is that it's best to provide a TL;DR in your answer instead of just linking.

They control bitcoin in the same sense that Queen Elizabeth controls the United Kingdom.
In theory, she has the power to something highly destructive, eg. order the military to drop a nuclear weapon on France.
In practice, unless her decisions agree with democratic consensus, she will almost certainly be dethroned.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
Is there an efficient and secure way to transmit bitcoins over shortwave radio?
This experiment by CBC that used chirp over the radio to transmit a wallet seed tickled my interest. Of course this isn't secure. And it's also inconvenient to create the wallet from the seed. What's a better way to do this in a practical way? Chirp is very accessible and convenient. Shortwave radio has a decent range, some distance over the sea.

Although I am not qualified enough to suggest a protocol for over-the-air, I can still get some technical pointers. You may want to ask at the ham radio SE community.
Yes you can easily send Bitcoins over shortwave radio using encryption but radio encryption is not a topic of this community. It's also severely illegal in the U.S. for a HAM operator to use any kind of encryption when transmitting.
The Bitcoin network over-the-air
This is what I think you are asking, the Bitcoin protocol does not send private keys of bitcoins around as its main technique as this is risky and dangerous inherently. The Bitcoin protocol moves bitcoin without the need to exchange private keys of any bitcoin so it be better to just implement the network over radio.
Bitcoin can practically be agnostic to the protocol you are using, as long as communication is possible Bitcoin will work. There are many protocols for shortwave radio available that can move data from a transmitter to a receiver. As an interesting example, you could totally set up a node that communicated via Morse code as long as it has other nodes to talk to. You'd run into problems with bandwidth as some tx/rx modes are slow. You can possibly use a modified version of Bitcoin-qt and use the same handshakes and messaging it does over tcp/ip.
The HAM radio community has interesting an P2P by itself which you can look into. APRS is a packet-based network which relies on peers to rebroadcast messages, it's really cool and is readily documented and has many tutorials.

I really should have thought of packet radio! My Dad was building them for years on 2m HAM radio. APRS looks like an interesting mesh topology!

I've been looking at this question too.   It is my understanding that a bitcoin transaction is not "encrypted" . The information is not obscured in any way, and can be transmitted publicly without breaking the security. You are simply transmitting a "hash" of the transaction, or signature. Nothing has to be decrypted to be read. You simply verify the signature to see if it is a valid transaction. It's not a big deal for everyone to see the transaction itself. They will anyway once it's in the blockchain.  My best guess is this would not break the obscurity rule in the US.
The rule I think that might be in play is not using amateur radio for commercial purposes. Buying an item through packet radio would most likely trigger this limitation.  What I wonder, though, is if maybe it could be used to send some sort of humanitarian aid, for instance if one person with bitcoins does not have Internet access, and wishes to send money to someone who does, via radio.  I can't think of a way a person could 'receive' bitcoin without being connected to the Internet   (since receiving is really only recording the transaction in the blockchain)

You can receive transactions just fine without being on the Internet at all.  You just won't know that you've received them until you check the blockchain.


text:
Would it be possible to create a mining pool service that specifically processed only certain transactions?
I've seen that it's possible to encode custom data in the block chain.
I'm wondering if it's possible for someone to start a mining pool consisting of client that use some metadata in either wallets or their transactions to process only some transactions, possibly for zero fees, that offers a confirmation time service level.
If so how would one determine the amount of processing power required to honour a certain service level?
Would this service undermine some principal technical mechanisms of the bitcoin network?

From what I understand, you are asking whether one can customize a client running at a mining pool to favour some transactions based on factors like what metadata they contain or where they were sent from.
The answer is, yes, it would be pretty easy if you would be able to program a custom client or pool software.
Searching for a piece of information in a transaction is pretty easy and shouldn't require too much processing power (one could for example use OP_PUSHDATA and later OP_DROP to store some data without affecting the transaction). The downside is that anyone could see which transactions were potentially prepared like this.
If you wanted to discriminate based on where the data came from (for example, your own eWallet, or custom wallet running on a computer), you'd need to spend some more time coding, but one couldn't distinguish between your special transactions and the normal ones. You could for example encode the client to wrap the transaction up in some data packet and sign it using a specific key and algorithm before sending it to your server. You'd have to write some special code to check the signature and relay the information to the pool, but it shouldn't be too hard.
Such service would certainly go against the spirit of Bitcoin, and probably you'd get some backlash from the community if it found out, but it is possible none the less. Unless such a pool would hold a considerable amount of Bitcoin network's hashing power however, it would not disturb how the network works. However, if it was to reach 51+% percent of the hashing speed, as it is always with such an attack, it could control the entire network.

Just to be clear, I have no intention of attempting to code such a service. Also when I ask about undermining the network, really I mean technically as opposed to idealistically, as in could such a pool of alternative clients be considered a form of attack, or destabilise the network in any way? I've edited to clarify

@barrymac Edited accordingly. Basically, unless you hold the majority of hashing power, the network should be safe. Otherwise it would just make the waiting time for transactions being included in the blocks longer (on average by the percentage of network hashing speed it possesses).

Are you actually saying that an attempt by a particular client or pool to accelerate some transactions over others would actually end up have the opposite of the intended effect, and in fact delay them ? interesting!

@berrymac If you wanted to include ONLY preferred transactions, other transactions would be delayed, because they would have to be mined by other pools. When you solve a block, other pools have to start over, thus the delay.


text:
Why are the majority of miners not voting on on P2SH?
Link (via reddit)
Currently the vast majority of miners just don't vote. Was there a mistake made in organizing the voting process (maybe most miners haven't heard about this vote?), or perhaps most miners really don't like either proposals?

Well I for one had no idea I could vote. Or how to do so. I'm guessing that because I'm mining in a pool that I forfeit my vote to the pool owner?

@SeanChapman - yeah, the pool owners decide how to vote. To vote for yourself, either solo mine or join P2Pool.

I was going to set up P2Pool but don't I have to solve a full block before my vote is actually "cast"?

@SeanChapman - that is true - the miner that actually solves the block will decide what to vote.

Most miners sell their vote to their pool operators for very little in return.

Well I think I have an incredibly slim chance of solving a block so I think I'll give my hashing power to a pool that is voting the same way I want to vote

@SeanChapman - why not P2Pool?

Well if I use P2Pool I'll likely never solve a block in time to have my vote broadcast (my hash power is about 517MHash), so I may as well contribute to a pool who's voting the same way I am, unless I'm misunderstanding how voting would work with p2pool

@SeanChapman - your expected contribution to the vote stays the same anyway, and switching to P2Pool is a good idea in general. You get a small bonus, instead of a fee, and contribute to decentralizing Bitcoin.

@ripper234 that's a good point but it feels as if I'm not contributing I suppose

As mentioned in BIP0016, this proposal will cause a dangerous-to-the-network blockchain split in the following case:

"A pay-to-script-hash transaction that is invalid for new clients/miners but valid for old clients/miners."

Therefore, at least 51% of the miners (and probably more to be really safe) must confirm that they are aware of this problem and promise to upgrade their software very quickly after any new client is released that implements the proposal (again, if the proposal is accepted).
In this context, abstaining technically ought to be interpreted as "I vote NO to p2sh but I may change my vote to yes later" since p2sh is only safe once 51% of the miners have indicated their agreement with it.  Simply failing to indicate disagreement has to -- at least temporarily -- count as a "no" vote in order for this election to achieve the intended purpose.
The voting technically won't begin for another day, but I think the low turnout so far is certainly telling.  It's not like there's any penalty for a pool starting its votes early, and since changes like this require testing there is a risk to waiting until the very last minute to start encoding votes.

As mentioned in BIP 0016, voting will take place at the end of januari 2012. votes you see now (januari 24th) are from pools who have already upgraded their software to vote either for or against. There are some pools who have said they will upgrade, but haven't done so yet.

The big set-back is that the original P2SH proposal (BIP 12 aka OP_EVAL) was Withdrawn by its author, Gavin. In its place, he proposed a new, much inferior system that is broken by design. Despite a sanitized P2SH being proposed in BIP 17, however, he continues to promote and push for the broken BIP 16. Hopefully once BIP 16's voting date has come and gone, he and those who follow his command will adopt BIP 17 (or propose something even better?).

Currently support for BIP 16 seems to about twice as large as support for BIP 17. It won't make the Feb 1 deadline, but the deadline can be postponed. I think the largest reason people (e.g. Tycho) don't commit to any of the proposals is that they fear it's rushed ... all of which can be fixed if the voting is postponed by a month or two.

Luke, I am grateful for the technical effort you have put into Bitcoin, but with utmost respect, you need to work on the tone of the way you promote BIP 17. Gavin has been open, self-critical, and intellectually honest. Statements like "broken by design" do him a disservice. I suspect most of his supporters don't understand the technical details, but follow him simply because of his more reasonable attitude. Please, stick to technical analysis of the proposals and don't turn this into a personality clash drama.


text:
How to debug a failed restore of a Namecoin wallet?
I bought some Namecoins a while back. With the upcoming Merged Mining patch, I reinstalled Namecoin 0.3.24.63 on my newly formatted computer, copied my wallet.dat from my backup to the right folder, and ... can't seem to figure out how to view my funds.
I ran namecoind -rescan, and then:
> namecoind listaccounts

{
    "" : 0.00000000
}

> namecoind listreceivedbyaddress
[
]

Am I using the right commands here? Is my wallet corrupt/empty? Should I just wait for the blockchain to download? In Bitcoin, if I remember correctly transactions I made using a backup wallet were visible immediately (grayed out) even before the blockchain was downloaded. Any more suggestions?
Update - I have all the blocks.

namecoind.exe getblockcount
  19062

Wait for the blockchain to download.

@David - I have, no change.

The best thing to do is wait for the blockchain to download.  With most wallet backups/new installations of bitcoin or namecoin blockchain downloading is usually the issue.  Many people seem to get a little impatient and think the program is broken when it's really just the download taking a while.

OK, I have all the blocks. The output from namecoind.exe getblockcount is 19062.

I would confirm that the wallet.dat was placed in the correct folder.  One option is to place it wherever you want and do a -datadir=(folder path).

I started the namecoin client, went to c:\users_UserName_\AppData\Roaming\Namecoin and found a folder full of namecoin data, updated in real time. Then I copy-pasted my wallet.dat there, overriding the one that was there.

Then you need to run with -rescan again.

@David - http://bitcoin.stackexchange.com/questions/1249/how-exactly-does-rescan-work

And, I've got nothing. Is there another way to debug this? I'm begining to suspect my original copy of the wallet is corrupt in some way, or just doesn't include the transactions for some reason. How can I verify it's a legit namecoin wallet?

Namecoin wallets and Bitcoin wallets are essentially identical, they just have differently formatted keys. You could try opening the wallet.dat file with something like pywallet or any other pre-0.4 Bitcoin wallet tool for that matter.


text:
How to backup Android Wallet?
I'm finally getting ready to install an Android client.
I believe Android Wallet is the most popular one.
How do I back up the bitcoins stored on it?
Also, is there a thin native Android client being developed?

P.S. I ended up using the Android version of Blockchain's MyWallet, which has built in backup to email/dropbox/google drive.

possible duplicate of Is there a known way to export my wallet private key from the "Bitcoin Android" app (com.bitcoinandroid)?

Andreas, once stored, how does this "private key" work as a backup tool? If my phone is lost, how can I retrieve the balance that was in the android wallet on my pc for example?

@Tom - most clients support importing a private key (how to do this is client-specific)

This does not provide an answer to the question. To critique or request clarification from an author, leave a comment below their post - you can always comment on your own posts, and once you have sufficient reputation you will be able to comment on any post.

Bitcoin Wallet for Android supports backing up your private keys to external storage (e.g. SD Card). Just select "Export/Import private keys" from the action bar overflow menu.

Just to note v4.3.2 (not sure when it changed) of bitcoin wallet backup wallet/restore wallet are in safety menu which can be found in the  overflow menu.

As with any backup solution you must test it yourself through the whole cycle first in a zero risk scenario.
Mycelium has an excellent backup solution which outputs a seed phrase for a HD wallet
You can then store this any way you wish, for example on paper in a physically secure location.

I think I'll wait for a good light client. I just wanted to play around with some coins on my android, but it's not urgent (I really don't have anywhere to spend them anyway at this point).

Yes it takes an age to get started, even on a wifi connection. I think mine took over 24 hours. But after that it's sweet and I like to keep a few on there just in case. There are people beginning to accept them, and I couldn't miss the opportunity. Sometimes it's scary when the wallet becomes worth more than the hardware though! :-)

Things change a lot since the first answer, updated.


text:
Has LargeCoin shipped any hardware yet?
LargeCoin announced their ASIC mining technology back in March 2012, with an estimated delivery of July 2012.
"ttul" in Bitcointalk, who made the announcement, also said "Expected delivery is July 2012. If we miss our delivery deadline, then we will return deposits in full."
Have they delivered any units? Did anyone order any? Has there been a more recent comment anywhere on when they will deliver?

Some people pre-ordered Largecoin units, but they never took deposits from anyone.


text:
Will merged mining mine each chain as efficiently as non-merged mining?
Let's say I get a hash rate of X when mining either Bitcoin or Namecoin.
When using Merged Mining, will I be able to still do X concurrently on both blockchains, or will I do significantly less than X?
In other words, if I merge-mine other coins, will it hurt my Bitcoin mining rate at all?

Every hash you do will contribute fully to the hashing power of both block chains. You will have to do a tiny bit of extra work when you generate a work unit, but that's almost insignificant, and you only need to generate a work unit once for every few billion hashes you do.
You will generate just as many Bitcoins as if you only mined Bitcoins and just as many Namecoins as if you only mined Namecoins. There are only two downsides of any significance. First, your Namecoin blocks will be a bit larger than they would otherwise be, since they include Bitcoin headers. Second, you will have to generate new work units every time a new block is discovered on either hash chain, so about twice as often. (This can be a big deal for a large mining pool.)
See my answer to this question for details on merged mining.

David Schwartz
If the difficulty on the aux chain is extremely low, it may not possible for the miner to produce a valid bitcoin block. Because calculation is restarted every time an aux-block is found.
Am i right?

A few of us have been running some tests merge mining a number of chains at once.   While in theory the hit rate should remain the same, in practice so far we are seeing reduced results.   Hopefully we will find out why soon.

Add progress on this?


text:
Does the ZeroCoin protocol fulfill its promise of anonymity?
Zerocoin is a new cryptographic extension to Bitcoin that (if adopted) would bring true cryptographic anonymity to Bitcoin.
Has anyone seriously analyzed the protocol and verified it works as advertised?

I hope so. I'm going to look pretty stupid if it isn't actually anonymous. The paper contains a sketch of a proof that the system is in fact anonymous. That is verifiable. Indeed to get published, other academics had to look at it. Now that the paper is public, even more will. If there is a problem with the proof, someone will point it out.
As others have said, the main question is efficiency and that is probably fixable with further research and engineering.

You're one of the paper's authors, correct? Am I correct that there isn't a public release of source code?

Yes I am. No there is not yet. We have to clean up the prototype code we wrote before we release it.

If this is true, and the implementation is "scalable enough", then this is great news for Bitcoin. Looking forward to seeing it adopted, and using it myself.

This is the zerocoin paper, but as far as I can tell, they haven't released source code yet, so all we can really do is speculate.
The single largest problem it has is that a zerocoin spend requires about 100x more disk space/bandwidth/cpu than a normal bitcoin transaction. However, the intended use case is that you use normal bitcoin transactions most of the time, then run through zerocoin when you want more anonymity.
Second, because all zerocoins are indistinguishable, they must either

all be the same denomination, which sucks for people making very large transactions and for people making very small transactions, or
Have a handful of predefined denominations, like 1-zerocoins, 10-zerocoins, etc. The problem with this is that it reduces your anonymity set.

As far as security/anonymity goes, I believe that they have a workable system unless there's some problem with their zero-knowledge proof, which I've repeated below.


text:
What is the meaning of the field for "Profitability decline per year" in bitcoinx' profitability calculator?
In the Bitcoin mining profitability calculator at bitcoinx.com/profit, there is a field with the description "Profitability decline per year". What does this field mean in regard to the calculation?
At a guess, I'd say, if it's set to 0.01 the projected income for a year from now will be 1% of today's projected income.

I agree that it isn't worded very well. It seems to be a number r such that the revenue n years from now will be r^n times the revenue today, so basically what you said.
To empirically verify this, set electricity and hardware cost to 0 (so that profits equal revenue), time frame in months to 12 (for a full year), and profitability decline to 1. You should get $1,366 or so. If you change it to 24 months, you get $2,732 - exactly double the previous. On the other hand, with a profitability decline of 0.2, you get $679 in 12 months and $814 in 24 months, which is $135 (or 20%) more.

it's because of increasing difficulty (which is apparently projected out for a year on bitcoinx).
"Difficulty" gets higher over time as the Bitcoin network matures and more mining hardware is connected to it.
This means that with the same amount of electricity and hardware cost chances of finding a block of bitcoins are getting lower. This phenomenon is displayed as "Profitablilty decline per year".


text:
Get the slush stratum proxy working on a mac
Title says it all - can anyone walk me through setting this up on a mac? I ran the linux python install script but i'm guessing i'm missing a few dependencies as it failed on me.
edit: there are numerous errors, listed here:
Reading http://tmrc.mit.edu/mirror/twisted/Twisted/9.0/
Download error on http://tmrc.mit.edu/mirror/twisted/Twisted/9.0/: [Errno 61] Connection refused -- Some packages may not be found!
Reading http://tmrc.mit.edu/mirror/twisted/Twisted/10.0/
Download error on http://tmrc.mit.edu/mirror/twisted/Twisted/10.0/: [Errno 61] Connection refused -- Some packages may not be found!
Reading http://twistedmatrix.com/projects/core/
Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.2/
Download error on http://tmrc.mit.edu/mirror/twisted/Twisted/8.2/: [Errno 61] Connection refused -- Some packages may not be found!
Reading http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/
Download error on http://tmrc.mit.edu/mirror/twisted/Twisted/8.1/: [Errno 61] Connection refused -- Some packages may not be found!

Running Twisted-12.3.0/setup.py -q bdist_egg --dist-dir /tmp/easy_install-OQqo5N/Twisted-12.3.0/egg-dist-tmp-9vucfj
unable to execute llvm-gcc-4.2: No such file or directory
unable to execute llvm-gcc-4.2: No such file or directory
unable to execute llvm-gcc-4.2: No such file or directory
error: Setup script exited with error: command 'llvm-gcc-4.2' failed with exit status 1

Knowing the error message would quite obviously be important to be able to help you...

good point. added to question.

unable to execute llvm-gcc-4.2: No such file or directory seems to indicate that you do not have a compiler installed. Did you set up Xcode and install the command line tools, or install GCC through MacPorts or Homebrew?

Aah, I've been a fool, the command line tools have apparently been optional addons for Xcode since 4.2 so I assumed i had gcc but did not. Got them from xcode preferences/downloads. Thank you! Works fine now. Worryingly though, gcc will no longer be an option for future versions of Xcode (4.6 forwards)

Any reason this has to be so difficult? Ah, to show that the devs are so much smarter than the rest of us!

So, while Mac includes python it does not include gcc by default, even once you've installed Xcode 4.2 or later. For now, grab that, go to preferences, downloads and get the command line tools.
Once a version of Xcode higher than 4.6 is out you'll have to find a new way to install gcc on your mac, as gcc will no longer be included, but I guess that's a question for another stackexchange, and likely a macports or homebrew solution.


text:
What happens when a Trezor is lost?
Trezor is one of the leading implementation of a hardware wallet. Its first generation won't support multisig ... because the Bitcoin network itself doesn't have strong multisig support.
What happens if a Trezor is lost or stolen? Where are the private keys it guards backed up? Is a password required to release funds stored on it?

I will just add (since this question is from 2013) - as of 2017, Trezor supports multisig, through Copay Chrome app.

If I remember correctly, the Trezor uses deterministic wallets, as specified in BIP 0032.  That means that the device will give you a sentence that the wallet can be regenerated from, in case it's lost.

As Julian has stated correctly the Trezor is  a heuristic deterministic (HD) wallet as most modern wallets are these days.That means that it generates a tree of pairs of secret keys/public keys(addresses) when its  initialised(to be more accurate it actually does this on the fly) from a 12, 18 or 24 word passphrase.
So if you have written down(on the card provided by trezor) this passphrase and have it locked away in a safe deposit box you can recover your entire wallet even if you have lost the trezor.
DANGER DANGER WILL ROBINSON......
If you have also used a password(not the pin) you will need this too... else all you will see on your recovered trezor is an empty wallet..
Its a great extra security feature if someone manages to steal your 24 word passphrase but can also be very dangerous.
YOU HAVE BEEN WARNED ;)


text:
What are "automatic coin choice pools"?
Referenced in this thread about a 51% attack on feathercoin.

This would have been a hell of a lot worse without automatic coin
  choice pools. They routed a ton of hashpower at FTC. This broke the
  attacker's control of the blockchain.

There are some pools that reroute the computational power, depending on where they can make the most money, i.e., they maximize their utility for a fixed amount of hashing power. Apparently the huge influx of computational power triggered these automatic coin choice pools to switch to the Feathercoin network, which again triggered more pools to switch.
In the end, the attacker not only had to fight against the computational power of FC, but also had to deal with the power coming from those pools, which proved to be too much, and he lost his majority.


text:
Gaming the "off-by-one" bug (difficulty re-target based on 2015 instead of 2016 block time span)?
In this forum post from Gavin Andresen he writes:

Second: I've written 'discourage blocks' infrastructure:
    https://github.com/gavinandresen/bitcoin-git/tree/discourageblocks
    (code reviews welcome)
... which should give us the ability to nudge miners to Do The Right
  Thing.  Discouraging blocks that appear to be gaming the off-by-one
  bug should be enough incentive to prevent 50+% cartels from forming,
  without requiring a blockchain-splitting change.

I believe the off-by-one bug refers to the difficulty re-target being based on the time taken for the previous 2015 blocks instead of 2016 blocks - please correct me if I'm wrong.
What I want to know is how can this bug be gamed by miners? What can they do and what advantage does it give them?

The attack allows a group of miners with more than 50% of the network's computational power to change difficulty arbitrarily.
When difficulty is adjusted, only the times of the first and last blocks in a retarget period (i.e., the first and last blocks with a certain difficulty) are considered. This attack works by manipulating the timestamp of one of these two blocks.
Blocks are considered valid if their time is greater than the median of the last 11 blocks and less than currentTime + 2 hours, so it's legal for an attacker to create a new version of an old block with a time far in the future. If this is the first block in a retarget period, then the difficulty will quadruple after that period. If it's the last block, then the difficulty will be divided by four. (Difficulty adjustments are limited to *4 or /4.)
Note that it is not possible to do these major changes with recent blocks because the time would be more than two hours in the future. It needs to be done with historical blocks, and then the attacker needs to re-do all blocks that come after that block. So this attack is only possible when you have a lot more computational power than the legitimate network.
This would not be as big of a problem if there was a block of overlap between the retarget periods. Instead of using the first and last block in a retarget period, use the last block of the old difficulty and the last block of the new difficulty. Then the attacker will still be able to mess with one retarget period, but it will be corrected in the next retarget period.
I think a better solution would be to look at every block in a retarget period plus maybe some blocks before the period. It just seems like a bad idea to give certain blocks "special powers".
A discouraged block is considered valid (it adds confirmations to transactions, blocks after it will also be valid, etc.), but your node refuses to relay it or build future blocks onto it. If most of the network is discouraging a block, then it will almost certainly be replaced. Even a minority discouraging a block will hurt the block's chances. It is very unprofitable for a miner to discourage a block when most of the network is not, though.
(Thanks to gmaxwell for explaining this attack to me.)


text:
How to mine in Ubuntu?
How do you mine in Ubuntu 11.04? Are there any GUI miners like poclbm-gui for Ubuntu?

GUIminer can be run on linux, although the process (described in the official thread) is somewhat complicated.  To summarise that post, you will need to:

Get the source code from GitHub:
git clone https://github.com/Kiv/poclbm
Install OpenCL drivers and PyOpenCL.
Install wxPython:
sudo apt-get install python-wxtools
Run guiminer.py:
python guiminer.py

Note that (at least to use the poclbm backend) no compiling is necessary since GUIminer is written in python.  But I can still understand if you find that process a little daunting, since I don't know your level of technological familiarity with these sorts of tasks.


text:
What are the perceived advantages of bitcoin as a means of exchange?
There are lots of ways to send money - western union, paypal, bank wire, etc that are more established and fairly quick. What are the advantages of using bitcoin from a bitcoin-proponent's point of view?

This question is too subjective for a stack exchange site.  From the FAQ, you should only ask "practical, answerable questions based on actual problems that you face."

It could easily be rephrased as "What are the qualities of bitcoin as a currency and as a means of facilitating transactions that are unique"

It needs to be rephrased. It is too vague/subjective right now.

@lemonginger, et al - I changed to the suggested title, feel free to suggest more edits (just click on the edit button directly)

Maybe something like "What are the perceived advantages that bitcoin has over other currencies or other ways of sending money?"

seems odd that this is one of the most favorited questions on the site at the moment and also has "close" votes. I will try creating a new question that isn't junked up with comments since "why use bitcoins?" seems like a pretty basic question.

See also: What are the perceived advantages of bitcoin as a store of value?

The primary advantages are:

Speed and price. You can transfer money anywhere in the world within minutes with negligible fees.
No central authority. Bitcoin is not dependent on any company or government to maintain its value.
You can start accepting bitcoins instantaneously, without setting up merchant accounts, buying credit card processing hardware, etc.
Bitcoins are less traceable than many types of monetary transactions (though not anonymous).
Bitcoins cannot be counterfeited and transactions cannot be reversed.
No transaction blocking or account freezing. We have seen governments freeze bank accounts of dissidents and payment processors refuse to process certain types of transactions (wikileaks, online gambling in the US, etc). With bitcoin this is impossible.
A known amount of inflation. Bitcoin is seen as a store of value because the total number of bitcoins that will ever be created is known in advance and it is impossible to create more than that.

Regarding 4., they're certainly more traceable than cash, which is arguably the most common type of monetary transaction worldwide.  Might be worth mentioning that specifically.

In some circumstances, in others much less traceable than cash which often requires two people to physically meet somewhere and exchange it

Regarding 1., it's not true since you need to wait for confirmations.

and confirmations take 'minutes', so 'within minutes' is certainly not incorrect. :)

though you will have to setup an account with a site like mtgox if you want to exchange bitcoins for something else

@eMansipater the government regulates money transfer agents and even gold dealers to report the identity of the buyer or seller in some cash transactions. There is no inherent reason this couldn't apply to many more classes of cash transactions in the future. In some countries in Europe, they've outlawed all cash transactions over certain amounts. The global capital controls will come as this sovereign debt (and real estate) crisis will not hit bottom until 2033.

#7 is incorrect. You conflated "inflation" with "debasement". Although the debasement rate is known, the inflation rate has been running wildly between deflation and inflationary drops from $35 to $2 then back up to $17.


text:
Is the timestamp in the genesis block relevant?
Bitcoin's genesis block contains this text published in The Times on January 3rd, 2009:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks

According to the Bitcoin Wiki, this guarantees that the block was only created after this date.
What would be the problem of using any other random quote?

The newspaper quote proves that Satoshi did not mine a large number of blocks before the public announcement of Bitcoin on January 10. The block chain creator could for example create a chain of 1000 blocks before publishing just the first one. He now has a head start for mining and can invalidate the public block chain at any time by announcing the blocks he kept secret as long as his chain is longer. The block headers contain timestamps but these can be manipulated if no one else is verifying the blocks.

Much like a lot of other things in the protocol, ingenious.

It serves no purpose anymore. As soon as you pass the first checkpoint that includes blocks not all mined by the same party, this is no longer an issue. If you assume Satoshi mined 1,000,000 blocks, his block chain has to fork this block chain before the last checkpoint, so his block chain would not longer be considered valid.

@jarpiain, Shouldn't it include headlines from all over the world? For example, what happens if Satoshi has control over Times editors?


text:
What are stale shares and what can I do to avoid them?
When I mine at a pool, only a part of my shares are accepted. There is a small percentage which is marked as stale.
As far as I know I only get paid for accepted shares, so what are these stale shares and how can I avoid them?

Stale shares are the shares that were sent after a block was already solved, that is to say, they were sent late and were no longer valid. To avoid stale shares, best to have a reasonably fast mining rig (so you won't take too long to calculate a share, probably not a problem for most machines), reliable internet connection (stable, not necessarily fast), but also an up-to-date mining software (if you are mining with some really old miner it might not communicate in the most efficient manner with the pool).
In short - update your miner every now and then, make sure your internet is running okay, and don't mine on really weak rigs.

A stale share occurs when you find a share and submit it to the mining pool after the pool has already moved on to the next block. The percentage of stale shares should be very low if everything's working correct, around 2 out of 1,000 shares or so.
Several factors affect the stale share rate. The three most important are long polling, pool load, and miner-to-pool latency.
Any shares found based on old work units after the pool controller receives a new block will be stale. Long polling is a technique that allows the pool to notify all of its miners when there's a change in the block chain so they can immediately request new work units. If your pool or mining software doesn't support long polling, you will finish out the old work units, generating stale shares.
When the long polling notification goes out, all miners that support long polling request new work units at about the same time. This generates a massive burst of load as the pool has to manages lots of network traffic and do several SHA-256 operations for each share it issues. If the pool is slow to issue you a new work unit, the window in which you can generate stale shares increases.
The long polling and subsequent share request process requires a few network operations. Latency between the miner and the pool can slow this process down. Picking a pool with a controller near you (network wise) can reduce this part of the stale share window as well.
In addition, some pools have had bugs in their software that produced stale shares. The pool checks if the share is stale by seeing if it has a record of the work unit and clearing all work unit records when the chain changes. So if something goes wrong with the work unit tracking process, that will result in a stale share being reported.
For example, if the pool erroneously issues the same work unit to two miners, the first one to submit the share will get credit. The pool will remove the record when the share is found because otherwise you could submit the same share more than once. This will result in you getting a stale share report.
I probably shouldn't admit it, but I was actually responsible for one such bug. My first implementation of long polling in the Bitcoin client rushed as quickly as possible to send out the notifications of a new block being discovered to miners -- so quickly that some miners could request new work units before the client had finished processing the new block and they got work units based on the old block. Any shares they submitted based on those work units would be reported as stale.

Interesting story. Do you have some blog or website with more stories like this?

The above answers are good but one thing I would add is that hashing rate affect stale share %.
Why?  Because with a faster miner a smaller % of shares are even "at risk" of being stale.
Pools only pay for completed shares.  A block is found on average every 10 minutes so in that 10 minute window the last share is the one at risk of being stale.  Now the time between blocks varies but is 10 minutes on average so we will just look at affect of hashing power in a 10 minute window.
A 100MH/s miner would complete (on average) one share every ~42.9 seconds.  Which means in 10 minutes it could complete ~14 shares.  A 800MH/s miner would complete one shares 5.36 seconds.  In 10 minutes that is ~112 shares.
If both miners are working properly and connected to fast accurate pools at most they will lose one share.  In other words for the slow miner 1 in 14 shares are "at risk" while with the fast miner only 1 in 112 shares are at risk.  The far extreme of this would be trying to mine with a slow CPU.  Your hashing rate could be so slow that on average you only complete 1 share per 10 minute block.  So 100% of your shares are at risk of being stale.
Everything else being equal a faster miner is more efficient putting less shares at risk of being stale.
Note: for this purpose only the single GPU hashing power matters not the total rig or farm hashing power.

I don't agree. The window where a stale share can be found begins when the pool controller sees a new block and ends when the miner has a new work unit through long polling. The size of this window is dependent only on network latency and pool load and is totally independent of the miner's hashing power. You are correct that the percentage of shares "at risk" varies, but that doesn't matter because as the percent of risk goes up, the level of risk per share goes down. (The slow miner has all his shares at risk, but very low risk since the danger window is a tiny fraction of the mining time.)

The amount of data required for a standard rig isn't very high. There are a few things that I would suggest if you are having issues.

Don't use wifi if possible. Connect your rig directly to your network with an ethernet cable.
Connect to the closest mining pool. Ping different pools and use the closest one. The lower the time the better.
Make sure your network is running as good as possible. A lot of different factors can affect network performance and cause interference. Even on ethernet connected devices. Use quality Shielded Twisted Pair (STP) cable to reduce interference.

If you do this, you will notice a considerable improvement on your network.

I was also facing the same problem that time. This problem was due to my usb device (modem) which give internet access to my rig, when I remove that usb modem and connect the rig with my phone via USB than i saw a huge change in the mining performance.
My stale share which came down from 30% to almost 3%. My modem was connected directly to motherboard and it may be it got disturbance signal from all my gpus.  It was network problem and make sure the device which you use for giving internet to rig should be kept far from it.
In given picture you can see how much stale shares drops from left to right .

Recently, SparkPool released a new version, added the feature that display stale shares. Some miners are asking what is stale share, we think it is necessary to explain it in detail.
Under the current POW mechanism, the mining pools push calculation task to the miner continuously. If the mining pool receives the share of the last task submitted by the miner after a new task is sent, this share is a stale share. Of course, there is no need to worry too much about it. Stale shares will be calculated as income, but it will be slightly lower than the normal share.
The delay is mainly affected by the miner's network status, and a good network performance will greatly reduce the chance of stale shares.  We hope that the miners improve their own networks, and the SparkPool will be continuously optimized the servers simultaneously. If you have any other questions, feel free to contact our customer service staff.


text:
Is it possible to brute force bitcoin address creation in order to steal money?
Bitcoin users frequently generate new addresses for each transaction they make, which greatly increases the number of bitcoin addresses being used to receive money.
Would it be possible (and profitable) for someone to find collisions in the bitcoin address space in order to steal money?

To give you an idea of the numbers involved: There are 1,921,075 different addresses in the block chain. That's less than 0.000000000000000000000000000000000000001 % of all the addresses that can be generated.

@Artefact2 Yes, there is currently 2m different addresses. If we want BitCoin to scale to 7b, 8b, 9b, or 10b people, each generating 10k different addresses a day, that's 100 trillion addresses created daily.

@Pacerier Why would every user need 10k different addresses per day?

@Murch, 10k may be a severe underestimation. In any case, now is not the best time to answer that question, for the same reason 4 decades ago wasn't the best time to answer "Why will we run out of IP addresses?"

@Pacerier: That is an interesting statement, but I am more interested in why you expect that to happen than what the exact figure might be in the end. ;) I've opened a new question for it here:
Why would we ever need 10k new addresses in average per day?

James D'Angelo has created a video to visualize the magnitude of Bitcoin's private key space: Bitcoin 101 - Quindecillions & The Amazing Math of Bitcoin's Private Keys

one guy made a website,which generates random private keys. You must visit https://bitcoindoubler.cf

It may be "theoretically" possible, but in reality it's unlikely to be achieved - As in counting the number of atoms in an office building unlikely.
Bitcoin addresses are actually the 256-bit SHA hash of an ECDSA public key, so any vulnerabilities in those algorithms would constitute a vulnerability in bitcoin itself. Realistically, however, breaking this level of encryption requires a huge amount of processing power. Coincidentally it requires precisely the same kind of processing power that bitcoin mining requires and in almost every scenario it would be massively more profitable to mine than to hack.
Edit: It's actually RIPEMD-160(SHA-256(public key)) as opposed to just SHA-256(public key) as I originally mentioned, so it's a 160-bit hash of a 256-bit hash of a public key. While the target keyspace (160 bits) is smaller thanks to this final step, it's also an additional computation that a would-be hacker must make. While the additional computational complexity doesn't even come close to canceling out the removal of 96 bits of keyspace, it should be noted that finding a collision in a 160-bit keyspace is still incredibly difficult and time consuming. More importantly, it is more difficult and time consuming than actually mining the same number of coins would be, thus making it highly unlikely anyone would even attempt such an attack - even if the equipment to make such an attack plausible in a meaningfully small span of time existed.

The address spec is located at https://en.bitcoin.it/wiki/Protocol_specification#Addresses if anyone cares to double-check my edits :)

Double check and repost what you find, this site is better then the wiki, lets put the information here instead of there.

Downvoted because this use of "possible" is unlike that which any reader would suppose.

Altered my opening sentence to indicate that "possible" is meant only in the strictest scientific sense of the word.

@DavidPerry The RIPEMD hash of the public key doesn't provide security.  I would update your answer (no need to leave an edit paragraph).  The public key is the SHA256 of the private key.  If an attacker compromises that he can generate the address (RIPEMD hash) from the public key trivially as it was his own key.

@theUnhandledException If we were attempting to create an address collision, all steps would be necessary as there could be multiple public keys that would RIPEMD into the same address - if the address is the only bit of data that an attacker has available, the RIPEMD-160 hash would be a necessary step since they can't derive the public key from the address.

@DavidPerry.  The RIPEMD has a smaller address space than the public key (2^160 vs 2^256). It takes slightly longer for each attempt (private key -> public -> address) vs (private -> public) but the odds in finding a collision on each attempt are 79228162514264300000000000000x more likely (8E28).  Now this is somewhat academic because 2^160 and 2^256 are both beyond our computatinal ability to brute force but the hashing of SHA-256 public key to RIPEMD-160 address lowers security.  As an example imagine the public key is 256 bit but address was 8bit would it be difficult to find a collision?

What I'm saying is that to be able to spend the contents of address x we have to know privkey y and pubkey z. What I'm saying is that x = RIPEMD160(z) and that without computing RIPEMD160(z) there is no way to determine if a given pubkey x matches our target address. Since everything in the blockchain is stored in reference to x rather than y or z we must needs compute RIPEMD160(z) for each value of z in order to check its balance or compare it to a known address we intend to steal from. We would need to compute RIPEMD160(SHA256(z)) for each value of z, thus increasing power needed to BF.

@DavidPerry I think you're missing the point.  You don't have to find the private key.  You only have to find a private key that corresponds to a public key with the correct 160 bit hash.  That is 2^(256-160) times easier than finding a private key that corresponds to the correct public key.  And while adding in the extra hashing step will make things take maybe twice as long, the 2^106 factor reducing the difficulty swamps that.

@DavidPerry Your error is in "to be able to spend the contents of address x we have to know privkey y and pubkey z".  In order to spend the contents of an address you only need to satisfy the scriptPubKey which typically says: "OP_DUP OP_HASH160  OP_EQUALVERIFY OP_CHECKSIG" - ie. make sure that the hash given in the input hashes to the same 160 bits as  and then verify that the given signature was produced by the given hash.  At no point does it check that the "right" pubkey was used, since we don't even know what the "right" pubkey is, only its 160 bit hash.

Holy crap, people are still arguing over this question? Necromancy, people, it's a bad thing. I concede the point just to not have to argue over a 7-month old answer any more. Also because you're correct. It's still way more profitable to mine than hunt for keypairs anyway, and as long as that's true we can probably consider the system secure. Similar to how it's not impossible to rob a bank, but it's usually (in the long term) safer and more profitable to get a job that's legal.

@DavidPerry You said that it is more profitable to mine than to hack. But is that likely in the future when all coins are already mined and the only "profit" are transaction fees?

@Pacerier while it's difficult to make predictions about future variables (number of keys holding a balance, etc) the odds of finding a privkey containing funds is outrageously low. Multiply the probability of finding such a key (effectively zero) by the average balance (impossible to guess at) and as long as that amount is less than the value of an equivalent time spent mining, we should all be safe - basically as long as quantum computing stays stuck in the lab.

@DavidPerry Ic. But quantum computing won't stay stuck in the lab isn't it? Computers weren't stuck in labs for too long.

@Pacerier just FYI, the value of a day's efforts generating privkeys is nua where n is the number of keys generated, u is the percent of all keys actually in use and a is the average balance of a given account. Right now n~=2,030,400,000,000 for a good Radeon card, u~=3.28*e-43, and a~=19.22 BTC which means that a full day cracking on a Radeon 5xxx card is worth ~1.28e-29 BTC, or 1.28e-21 of a satoshi - the security is in the sheer size of 2^160, no amount of addresses in use will likely ever represent any significant percentage of a number so large.

@Pacerier if quantum computing ever leaves the lab and becomes affordable, Bitcoin isn't the only encryption-reliant tech that's in trouble. Even then, new crypto will spring up that's resistant to Shor's algorithm and Bitcoin can switch from ECC to something else. The beauty is that it's flexible enough to avoid these kind of problems.

It is possible to brute force some Bitcoin addresses, because some people generate their private keys in an insecure manner.  Any (non-zero) 32 bytes can be a private key.  So running sha256 over a passphrase gives an apparently random, but brute force-able private key.
Take sha256("sausage") for instance:
$ echo -n 'sausage' | sha256sum
30caae2fcb7c34ecadfddc45e0a27e9103bd7cfc87730d7818cc096b1266a683  -

Load up bitaddress and paste that private key into the 'wallet details' tab to get the corresponding Bitcoin address, then look it up on blockexplorer:
$ GET http://blockexplorer.com/q/getreceivedbyaddress/1TnnhMEgic5g4ttrCQyDopwqTs4hheuNZ; echo
0.01000000

and you'll see that the address held one bitcent for about 2 days in February 2012.
See also: "fuckyou", which held 2.5 bitcents for 12 festive days at the turn of last year.
So in practice it's possible to brute force bitcoin address creation, but only for poorly chosen passphrases.  These were probably just people playing around with the idea of "storing bitcoins in their head" which is why they are for such small amounts, and why they weren't left funded for long.
No address balances were harmed in the making of this answer.

+1 for the interesting (though pratically useless) take, for the sausage, and for the cool closing sentence.

Really good explanation about "deterministic wallets". Thanks!

what if instead of using such simple passphrases (dictionary based and 2 words at most) one would base its address from a 6 word passphrase with the majority of the words being non-existant in language dictionaries?

That would obviously be safer than using "sausage" as your passphrase, but not as safe as using a completely random 256 bit private key.  Brute forcing a 6 word passphrase is easier than brute forcing an arbitrary 256 bit key.  It's say your word list is 64k long (16 bits per word).  Then your 6 word phrase has 16*6 = 96 bits on entropy.  A random key has the full 160 bits (bitcoin addresses are derived from a 160 bit hash of the private key).

It took me three minutes... I'm still reeling from the experience... 'free bitcoins', guys, 'free bitcoins'. All in lower case, with a space and no punctuation. You can find the whole story here: http://igor.host/index.php/goldendustproject/, with pictures and all... Whew! can't explain it myself

In order to spend money sent to a Bitcoin address, you just need to find a ECDSA public key that hashes to the same 160-bit value. That will take, on average, 2160 key generations.
Supposing you could generate a billion (230) per second, you need 2130 seconds.
Doing this in parallel using a billion machines requires only 2100 seconds.
Getting a billion of your richest friends to join you gets it down to only 270 seconds.
There are about 225 seconds per year, so you need 245 years.
The age of the Universe is about 234 years so far — better get cracking!

Can RIPEMD-160(SHA-256(public key)) only be reversed by trying different public keys or is there a more efficient way (assuming no weakness)?

To answer myself: no. However if the address was previously used to send bitcoins, then the full public key can be found in the input of that transaction. That reduces the problem to calculating the private key from the public key and there are more efficient ways to do that than random guessing. But you'll have to have to wait at least 30 years for Moore's law to catch up. See my question here.

Your calculation assumes that the correct key will be the very last key you generate right?  I would think that after 2 ^ 23 years you would have a 50% chance of having cracked it...

@Peter you do have a point there..

@Peter Actually I don't think so. Whenever you add a bit or remove a bit of security you are effectively doubling or halving the search space respectively. Brute forcing half the search space means searching through 2^44 -- not 2^23.

This here is the correct answer.

Is this time estimant to crack 1 private key or to crack them all?

No, it is not possible, for two reasons.
First, you would have to generate and hash an unimaginably large number of ECDSA keypairs to have a reasonable chance of finding a collision. With current computing power, that would take longer than the age of the universe.
Second, as pointed out in the other answers it is much more profitable to generate bitcoins if you have lots of computing power.

It is possible, just highly unlikely and impractical.

Doing something that would take longer than the age of the universe is possible?  Not by any meaning of that word I'm familiar with.  I upvoted this answer, so the zero score means someone must have downvoted it.  I'd be very careful downvoting the head developer of BitCoin on the BitCoin stack exchange ;) .

@eMansipate I believe the average or expected time is longer than the age of the universe, but there nevertheless would be an astronomically small probability (small enough to be completely ignored for any practical purpose) of finishing in a smaller amount of time.

If somebody asked in a physics stackexchange "Is it possible for my body to spontaneously explode" would you say yes?
After all, it is theoretically possible for all the atoms in your body to suddenly change quantum states and fly apart...

Yes, I would, and anyone with a decent knowledge of physics would back me up on that. We must never discount something as impossible simply because it is very highly improbable. If you were to ask on a physics stackexchange, some fan of the Copenhagen Interpretation would probably tell you that Bitcoin already has been hacked, just not in this "fork" of the universe. Someone can still try it and they can still succeed, they're just not very likely to - the likelihood is so low that it can be discounted but "no" is still an incorrect answer.

Oh and @eMansipate: I have nothing but respect for Gavin and all he's done, Bitcoin is an amazing project and I'm glad he's working on it. He's certainly a stupendous programmer and a very intelligent man but all of that does not make you immune to being wrong once in a while. I don't take my downvotes or closed questions personally and I would hope Gavin doesn't either.

@David Perry: You've just made the word "possible" synonymous with "non-contradictory" and invalidated its most common use. I bet you don't actually use the word that way, as no sane person does. "Is it possible for you to mow my lawn Sunday?" "Yes.", a week later, "Why didn't you mow my lawn?" "I only said it was possible."

@David Schwartz: This isn't really an appropriate place for this discussion but I do actually use the word that way. I also say "I have a hypothesis" when I do not, in fact, have something that qualifies as a theory. Perhaps it's pedantic but language erosion is a serious problem.  In any case it's off topic here so I'll not argue it further.

@eMansipate you can't define the length of a particular trial only the average trial or some probability range.  For example it is highly improbable but I could generate a collision between 2 SHA-256 hashs back to back total execution time <1 second.  Granted w/ current computational power to have a REASONABLE chance of creating a collision would take a huge amount of time however that doesn't make it impossible because one could form a collission in one trial.

@theUn I can't believe this answer has five downvotes when it clearly and accurately answers the question as actually asked. When a phrase like "in order to steal money" is introduced it becomes eminently clear that the scope is practical possibility rather than theoretical. If the Security SE was asked whether it was possible to brute force SSL certs in order to spoof a website, the answer would be "no, it is not possible" because until or unless new math/hardware is invented humanity as a whole lacks that capability. With "current computing power" clearly referenced, the same applies here.

Or, for a more direct comparison consider the question, "Is it possible to make a living by playing roulette at a casino?"  Anyone who says yes because you just might win every time for the rest of your life is giving the wrong answer--the context required by "make a living" makes it clear that we are talking practical possibility rather than theoretical.

@eMansipater  I think it is more the line "First, you would have to generate and hash an unimaginably large number of ECDSA keypairs" that statement is false.  100% false.  You could generate a collision with a small number of hashes, possibly even 1 hash.  Likewise "With current computing power, that would take longer than the age of the universe."  The minimum amount of time to find a collision can't be defined.

I was just wondering how you know the age of the universe?

shoelessjoe: It might be better to say that our sun will envelop the Earth before this is likely to occur.
DeathAndTaxes: The minimum time can't be defined, but the average time can. That said, average time doesn't determine whether something is "possible" - minimum time does, and minimum time in this case is one hash.
eMansipater: My answer re: roulette would be "possible but highly unlikely" as calling something impossible makes you look very stupid when someone actually does it.

And yes, Gavin, it is possible for my body to suddenly explode, especially on New Years Eve... dude, that was quite a party....:-)

If you would like to see some proof to verify that it is truly quite impossible to generate a known keypair, you could test this yourself, if you wanted.
Pavol Rusnak has created coinkit, a python library for interacting with Bitcoin related stuff. In there, there is an example on how to use it that does exactly what you are asking.
What it does is it generates a random keypair and searches blockchain.info for a balance.
I let it run about a month ago with slight modifications on about 1mio adresses and did not find a single one colliding.

Can anyone explain why this answer is downvoted? I'd like to avoid mistakes in the future and I'm clueless.

Dennis, although I was not the one to downvote your answer, I can see why someone might. It doesn't really add anything that other answer don't already describe, doesn't provide any mathematical calculations, and is even a little rude toward the OP.

Oh, rudeness was my intention and I sincerely apologize. It was rather meant to be sorta funny. Anyway, as to the 'not adding' I disagree, it points to a link where you can see what is theorised above, in practise. Putting things in practise is always valuable. Would you not agree? I edited my answer based on your feedback. Thank you!

You did reference links not found elsewhere, and updated your answer with feedback. Thanks! Upvoted.

There is the LBC (Large Bitcoin Collider) project that attempts to do that. According to their website they've created over 8,000 trillion keys, as of October 2017.
According to a Motherboard article of April 2017, LBC found over 30 Bitcoin private keys.

Those private keys are not "real". They were "planted" by the creator of LBC, i.e. he funded those private keys for the sole purpose of them being found by LBC. Those private keys were not actually in use by people for actual transactions. Those private keys were also very short ones and had a high probability of being found.

@AndrewChow can you prove that "planted" accusation? If you take the page number of the backend pages, add the offset of the line number and put that number through the algo, you will exactly obtain the Wif and the address.

@Michael It's literally in the LBC thread on Bitcointalk: https://bitcointalk.org/index.php?topic=1877935.msg18672178#msg18672178. Bounties were created solely for LBC.

If you prefer diagrams: https://i.sstatic.net/VWwJq.png (there are more addresses in the address space than there are zeptometres, 1/1 000 000 000 000 000 000 of a metre, in the universe's width).
If you prefer maths: http://download.wpsoftware.net/bitcoin-birthday.pdf (by Andrew Poelstra) says (slightly edited):

Using [birthday attack maths], we calculated [above] that for a 0.1% probability of collision, we would need 5.4 × 10^22 addresses in existence. For a 99.9999% chance, we would need 6.35 × 10^24 addresses.
So, even if there were 10^22 bitcoin addresses generated, a collision simply will not happen.  But if there were 10^25 addresses generated, a collision absolutely would happen.
Should we worry about this?  No, for these independent reasons:

The chance of getting a specific collision, say, a collision with one of your addresses, is still 1 in 2^160 or 1 in 10^48 . So even if you've got a million million million addresses, nobody has a chance of colliding with you.
At the time of this writing, there are less than 10^7 addresses in use in the network.  So anyone with 10^25 addresses would only be colliding their own addresses.
Each address takes around 100 bytes to store. (Actually about half that, but we only care about orders of magnitude.) So for the network to support 10^25 addresses, it would take 10 million million terabytes of storage just to record them.  (And this is not even touching the problem of searching such a huge data store.
According to sipa, if the current mining network (which is at 25 THash, and the most powerful computing network in the history of the world) were switched over to address generation, the network could generate 2.5 × 10^12 addresses per second (one address generation corresponding to roughly 10 hashes). At that rate, it would take 127,000 years to get so many addresses. It is debatable whether homo sapiens has walked the earth for that long.
With 21 million bitcoins ever existing, and 8 decimal places of divisibility, at most 2.1 × 10^14 can possibly have money on them at once.  But in a space of 10^24 addresses, this means that only one in 10^12 addresses could possibly have money on them. So an attacker, after doing the physically impossible 3 trillion times over, has only a one in a trillion chance of getting even one satoshi out of it.

Theoretically it is possible (but not profitable).  But in reality the amount of money you would have to spend to do it would be a lot more than what you would make.

Possible: Yes.
Probable: No.
Many events are possible even though they're not probable. The likelihood of bruteforcing a bitcoin private key is improbable enough that with current computing standards it is, for all intents and purposes, impossible.
As the science of cryptography develops and as bruteforcing becomes more powerful the underlying bitcoin infrastructure will be improved to keep pace with the improving technology. This may require accessing your bitcoin wallet using an improved client in the future to maintain a high standard of security.
Additionally, a bitcoin address is not the same as a private key. Generating a bitcoin address will allow an attacker to send you coins, but it would not allow them to sign transactions with your private key (i.e. remove coins from your wallet).

-1 Downvote. Technically a public key collision would invalidated the security of a private key.  Say you have a private key & public key pair xy.  If I find a collision such that a new private key z that has same public key y I CAN sign transactions as you.  By signing the a transaction (involving your bitcoins) w/ key z they would be validated by the network just as they would if signed by x.  Both would appear equally valid.  Only your last paragraph is wrong.  If you modify the answer I will remove downvote.

"allow an attacker to send you coins"?  Anyone can send you coins.  In order to spend your coins, 'all' the attacker needs is a private key such that the corresponding public key has the same RIPEMD-160(SHA-256(x)) hash as your public key.

Yes, following technology progression, once equipment is available that can do 1Thash/sec and above then it becomes feasible to start finding collisions with a reasonable success rate. I'd estimate in circa 2-3 years this will be viable, as to whether anybody attempting it lucks out to get an address which has a decent quantity of BTC associated with it is another thing, and the question as to whether it'd even be profitable is further still.
I'm quite sure that the odds are much less than the basic math indicates.. if you find a match which is circa 20 chars long, the odds are rather high that the full address will match due to the process involved in generating the key pair.
Skip forward a decade, and this will be far more of a realistic worry, or at the point Thash becomes normal, and Phash is on the cards.. just as GPUs are now dormant and looking for a use, so will mining equipment that hasn't even been invented yet be in a few years.

I must admit, I don't know enough about how many addresses one could generate with a 1 Th/s computer, but I once calculated the probability of a collision occurring when every person on this planet has 100 addresses. If I remember correctly it was still in the range of 10^-27, so the statement that seeking collisions becomes plausible with 1 Th/s feels wrong by a few magnitudes. Also, if the technology progresses sufficiently, addresses can just be incremented to a bigger space.

I probably wasn't clear, it's quite feasible now to have Ghash/s equipment at home, when it's feasible to have Thash/s equipment at home, that's no longer profitable to be used for mining bitcoin, then there will be an incentive to start collision mining pools with xxx Thash/s capabilities. Mining equipment fast becomes useless for mining bitcoin, mining bitcoin becomes harder, the rewards become less - finding collisions becomes easier as there are (a) more key pairs/addresses in use over time (b) more hashing power available cheaply (c) no increase in difficulty ever.

That was not the issue, I follow you on that. My issues are: 1) Can ASIC miners even be re-used to generate addresses, and 2) I think that your proposition underestimates the difficulty of finding a collision immensely.

Regarding (2), will need to crunch some numbers on that, the variables are: the speed at which attacker(s) can create ECDSA public keys and check them against a list, the number of funded bitcoin addresses for which a key would be useful - certain parts of the equation are well known, for example we can assume reasonably that key distribution will be pretty even throughout the space (thus attacking only a portion of the space would be viable), and that there are roughly 2^96 private keys for each address.

Regarding (1), for any address which has spent an input and has remaining unspent inputs, the public ECDSA key is in the block chain, making checking much easier, for any address that has only received and not spent,t hen the ripemd-160 address in the blockchain which requires 2 extra steps of ripemd-160(sha256(ecdsa-public-key)) which makes it substantially more computationally expensive, much less so than computing a full address ala vanity address making.

Is there a pluggable crypto-technology built into the BitCoin architecture that can circumvent the inevitable?

Can you justify your calculations, please?  If RIPEMD-160 is secure, it should require roughly 2^80 keys to find a collision.  Generating a key takes much longer than an SHA-256 hash (and standard mining ASICs won't do it), so "THash" is not a useful measurement.  But even if you could do 1 tera-key per second, you have to do 2^40 keys to average one collision - that's about 34,000 years by my calculation - and even then, you'll probably just have found a collision with another key you generated, that doesn't actually contain anyone's coins.

And can you please explain  your remark about a 20 character match?   It sounds like you're claiming that the 2^256 possible private keys map to only 2^117 or so of the 2^160 possible addresses - that would seem to be a huge weakness in the hash algorithms used if true, and should be published in a leading crypto journal.

I read on bitcoin.org that a private key $d_A$ is any integer between $1$ and $n-1$. Also $n=FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFE 0x00 = 18,446,744,073,709,551,615 0d00 $. Assuming 100M different addresses that is $5.42 e^{-12}$ probability of selecting a used address. If we have $x$ guesses, we need $x=$frac{1}{5.42e^{-12}}$ private keys to ensure finding one. That is $5.42 e^{12}$ address generation then for all 5.42 trillion randomly generated private keys generated, you would have to multiply $G$ by each private key $d_n$ in the elliptical field to get the $Q_n$ then search the bitcoin block chain for that $Q_n$. After 5.42 trillion of them you would almost certainly find one and be able to steal its btc.
You could work out the computer science of this like how long to multiply $d_n \times G$ and how long to search the block chain. Being as almost all wont be in it, it will be all worst case searches.

I feel as if this is something that may happen occasionally however far to few to be considered a significant threat, at least for now as this problem won't scale like the block chain does. Also you can even average the amount of contained in a btc wallet, and work out the profitability, and I suspect it is low. Like you would go through all that just for the odds of stealing maybe 500 usd


text:
Can a block ever be empty?
The standard response is "no, the reward is at least one transaction." What about after there is no more reward?

Outputs with 0 value are valid (but non-standard). When the block subsidy reaches 0, blocks without fees will need to produce coinbase transactions with 0-value outputs. Every block must have a coinbase transaction.

That is far in the future and can still be changed, but at the current time a coinbase transaction is required and will always be present. It is very likely that this rule will be upheld in the future as well. It is also possible that the transaction accuracy could be increased enough for there to always be a block reward, however minuscule.


text:
When did litecoin fork bitcoin?
I'm looking for the git tag of Bitcoin at the time of the fork as well as litecoin after the fork

Since the v0.8 release Litecoin is developed using patches to the Bitcoin code base.

Was the code completely revised as of 0.8?

Yes, differences to bitcoin in v0.6.3 were turned into a patch set to the bitcoin code base to be maintained separately.


text:
Are there any Scala libraries/implementations/projects on bitcoin?
There are quite a few Java libraries and I am building my Scala code on BitcoinJ, but obviously, native Scala libraries would be quite a bit more elegant. Has anyone tried?

Per the Area 51 example questions,  programming questions are off-topic here and should be asked on Stack Overflow.

@eMansipater Well, that example is about urllib vs urllib2. This is about bitcoin libraries. I think that the users of this site can provide a much better answer to this question than people at Stack Overflow.

I think it should be on topic. http://meta.bitcoin.stackexchange.com/questions/103/should-questions-about-programming-bitcoin-applications-be-on-topic

As currently rephrased I am voting to re-open.

A scala library would be great. Although bitcoinj is a great software, the complexity of Java makes hard to hack into. Note that I have used bitcoinj in Scala without any problems.

I really don't think it's needed. Bitcoin is a complicated project, it's better to have one canonical JVM-based library than a library in each JVM language.
AFAIK there is currently no Scala library, and I'm betting there won't be for some time (unless perhaps as a wrapper to bitcoinj?)

This an old question, but there is an implementation now:
https://github.com/bitcoin-s/bitcoin-s-core

As far as I know there are no Scala Bitcoin libraries currently under development.
As @ripper234 suggests, you could make do with the (canonical) BitCoinJ library which is currently under heavy development. This approach is often the case with JVM languages, whose primary purpose is to leverage the quality of the underlying support libraries rather than reinventing the wheel.
However, given that Scala now has a .Net implementation, then this argument becomes weaker. Therefore I would take the stance that there is room for a native Scala implementation, just as there is one for C# (BitCoinSharp).
Although slightly off-topic this forum discussion of a C reference library (not C++/C#) brings up some interesting ideas - does it skim over a Scala library in passing.

You could also check out my project: https://github.com/colinrgodsey/scalaminer
Looking to expand functionality too


text:
What is Bitcoin?
I'm a programmer, and a generally smart person, but I can't understand really what bitcoin is.

Is it a new payment merchant like PayPal?
Is it a virtual currency like LindenDollars that can't be really used as money? (put money In, but not Out)
Is it a new currency system, where people exchange bitcoin addresses instead of real money?

Great question! I was sure it was asked by now, but remarkably, I couldn't find it ... so maybe it was not.

The reason that we don't have a question like this is probably because it has been considered "too basic". Seems like people like this question though so I won't touch it unless the community wants to. I'll remove the FAQ "label" in the title though. All questions should have relevance to other users and the most popular ones will get many votes so there is no need to invent additional labelling, let's keep the titles clean.

Your second and third options are the same. In either case, you can put money in if someone is willing to sell the virtual currency but can't if they're not and can take money out if someone is willing to buy the virtual currency but can't if they're not.

Is it a new payment merchant like PayPal?

No.
PayPal is a company, Bitcoin isn't.
PayPal deals with existing currencies like US dollars, Bitcoin doesn't.
PayPal holds your balance for you, can freeze your account and can stop you from sending your money to people it doesn't like.  With Bitcoin, nobody can freeze your account or tell you how to spend your bitcoins.

Is it a virtual currency like LindenDollars that can't be really used as money? (put money In, but not Out)

Whether it is a currency or not isn't clear, but it is virtual.  Some say it's more like a commodity than a currency.  It acts a lot like gold, in that there is a finite supply of it, it's valued by some people, and it can be used as money anywhere that accepts it.  Also, it can be bought and sold for US dollars and many other currencies.  At the time of writing 1 bitcoin is worth 470 USD, and there are plenty of people willing to buy them from you at just under that price or sell them to you at just over that price.  The price is decided by the market. The price bitcoin trades at is the one people think it is currently worth.

Is it a new currency system, where people exchange bitcoin addresses instead of real money?

It acts a lot like a currency and can be used to trade with anyone who accepts it.  It is very cheap to transfer between any two points in the world, and very fast compared to transferring US dollars or other currencies.
See this introductory video for a slicker introduction.

It's a distributed digital cryptocurrency. The key word here is distributed, i.e. there is no central authority, instead transactions are handled peer-to-peer with a complex protocol where everyone ensures no one cheats.
New bitcoins are created at a predetermined rate to people who run "miners", which are a vital part of the protocol that checks for transaction genuinity.
You can exchange bitcoins with other hard currencies using public exchanges such as Mt. Gox. You exchange them with other people willing to sell or buy them, just like on a stock exchange.
For more details: http://www.weusecoins.com

Lol at the serial downvoter (and lol at this stupid policy of keeping the votes secret, too).

Distributed is definitely a key word in bitcoin. Great explanation. I would also argue that an equally key word in explaining bitcoin could also be decentralized.

There are a couple of books on Kindle that might help you get started.  The best way to really understand Bitcoins is to create a wallet and fund it with a few Bitcoins then use them.
To start safe and securely check this book on Kindle out: http://www.amazon.com/dp/B00A1CUQQU

Bitcoin is no payment merchant like PayPal, as it is no company but an open source project and a community of users connected in a completely decentralized P2P network. It can act as a payment service similar to PayPal, but you have no intermediary and transactions are irreversible and (for the most part) free of charge. Also, Bitcoins are not on some online account that can be frozen, but only on your harddisk (similar to cash in your wallet).
Bitcoin is a virtual currency as it has no physical form (it's just information in the form of cryptographic keys). It can however very well be used as money in the real world and is actively exchanged for various fiat currencies or products and services (obviously in both directions).
It is a new currency system where people exchange Bitcoins instead of traditional fiat money. Unlike the latter, it is however not backed by any government or corporation. Therefore it has a floating exchange rate only determined by supply and demand. In this respect Bitcoin is also similar to commodities or for example precious metals.

Bitcoin is multiple things:

A new currency, like the dollar or euro.
A payment system to pay with this currency. Just like there's Paypal or credit cards or bank transactions to transfer dollars or euros, there's the Bitcoin software and network to transfer bitcoins.
An innovative technology that allows people to gain consensus without depending on a central party, and without requiring trust.
The future of money. Or actually, the future of any form of asset that can be represented by information, such as: money, voting rights, stock / company shares, land or real estate ownership, temporary rental car access, you name it.Note that all these examples are already digital today, except now they're recorded and administered by some central authority (e.g. banks, notary services, government registers, etc). Bitcoin technology allows for a safe, decentralized, efficient, free alternative that no longer depends on central authorities.

You could also see Bitcoin as 'digital cash' or 'gold 2.0'.
To understand the basic workings, consider Bitcoin to be a global, public ledger. There's only transactions in this ledger, that transfer amounts of imaginary units from one account to another. This is the same as current banking, except with Bitcoin, there is no bank, company, authority, administrator, or other central party that manages the ledger.
By the way Bitcoin is set up, this ledger is stored, maintained, verified and distributed throughout all bitcoin users over the planet. Therefore when using Bitcoin, nobody can tamper with the database, we don't have to trust anyone, we don't depend on anyone, and nobody can enforce arbitrary rules or impose restrictions. Its security and trust is purely based on cryptography and transparency, rather than the supposedly benevolent intentions of bankers and authorities.
Finally: a worldwide, free, open, transparent system to transfer value, where we no longer depend on 3rd parties.
TL;DR = Bitcoin can do for money, what the internet and email have done for information and communication. In my opinion, this is one of the greatest technological inventions since the coming of the internet, and I think it will truly revolutionize the world as we know it.

http://www.michaelnielsen.org/ddi/how-the-bitcoin-protocol-actually-works/
provides a very nice picture of the Bitcoin Protocol. It explains how the transaction is done, how the validation is managed, the cons and pros of some rules and much more, but not in detail rather the basic understanding.

First and foremost, bitcoin is a protocol that facilitates the transfer of tokens (ultimately) between people. The protocol is very elaborate, and defines diverse concepts:

Addressees, which act as a store of the tokens
Transactions, or different possible ways of transferring tokens between people (actually, addresses)
Blocks, which are simply groups of transactions
the block chain - a ordered sequence of blocks

The protocol uses diverse cryptographic primitives (such as hash functions and digital signatures), as well as a decentralized network of computers to facilitate and verify the correct transfer of the tokens.

Most people call the tokens that the protocol transfers simply as bitcoins. Because the amount of existing tokens is finite, the tokens are economically scarce, and people are willing to use it as a store of value. Some people believe that this fact turns the tokens into a form of currency.

Some people also consider the term "Bitcoin" to include a large system of entities that use the protocol, including

exchanges which facilitate the trade between bitcoins and fiat money - such as MtGox or  Bitstamp
sites that track transactions, such as blockchain.info
sites that track exchange rates, such as bitcoinity or bitcoin charts

Ultimately, asking whether these entities are part of bitcoin is as useful as asking if Google is part of the internet.