text:
How much inflation does Bitcoin have, year by year?
What's the M0/MB inflation rate of Bitcoin?
Note: I'm asking about multiple years in order to make this question less likely to go out of date.

I am not sure exactly how you want to define the money supply.  The definitions of M0 and MB given here differ in whether you count physical currency held by banks and Federal Reserve account balances.  I don't know what the correct analogy of those quantities is for Bitcoin, which doesn't have a Federal Reserve, and I don't know how you would define what is a bank, nor how you would find out their currency holdings (since there are no regulations forcing them to report this).  Can you be more precise in your question?

The obvious way to measure the "money supply" at any given time would simply be to determine the total number of bitcoins generated up to that time, and assume all of them are "in circulation".  In that case your question should reduce to looking up some numbers and a simple computation.  But it seems like maybe you are looking for something more elaborate than that.

@NateEldredge Can you be more precise in your question? So, for example, when the genesis block was issued, the inflation rate was infinite, because it went from 0 to 50 Bitcoins. The obvious way to measure the That's exactly what I'm looking for.

So, for example, let's compute the inflation rate for the year 2010.  A quick binary search shows the last block generated in 2009 was 32489.  Since the reward was BTC 50 per block up to that time, after block 32489 there were 32490*50=1624500 BTC in circulation....

The last block of 2010 was 1004090 so there were 50*(100490-32489)=3400050 BTC generated during 2010.   Now 3400050/1624500 = 2.09 so Bitcoin experienced a 209% increase in the money supply during the year 2010.  Is that what you are looking for?

Bitcoin is deflationary.

@Geremia It may be price-deflationary (as the value of coins may go up), but it is certainly supply-inflationary (as the amount of coins in circulation goes up).

@PieterWuille, 1BTC = 1BTC

Year   #blocks    #bitcoins       Supply inflation per annum
2009    32,489    1,624,450          -
-----------------------------------------------------------------
2010    67,920    5,020,450        209.06%
2011    59,627    8,001,800         59.38%
2012    54,526   10,614,025         32.65%  (halving Nov 28)
2013    63,433   12,199,850         14.94%
2014    58,865   13,671,475         12.06%
-----------------------------------------------------------------
2015    54,321   15,029,500          9.93%
2016    54,851   16,075,362.5        6.96%  (halving Jul 9th)
2017    55,928   16,774,462.5        4.35%
2018    54,498   17,455,687.5        4.06%
2019    54,232   18,133,587.5        3.88%
-----------------------------------------------------------------
2020    53,222   18,586,906.25       2.50%  (halving May 11th)
2021    52,686   18,916,194.75       1.77%
2022    53,188   19,248,619.75       1.76%
2023    53,999   19,586,113.5        1.75%
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2024             19,801,156.25       1.10%  (estimate, halving)
-----------------------------------------------------------------
2025             19,965,531.25       0.83%  (estimate)
2026             20,129,906.25       0.82%  (estimate)
2027             20,294,281.25       0.82%  (estimate)
2028             20,401,178.125      0.53%  (estimate, halving)
2029             20,483,366.625      0.40%  (estimate)
-----------------------------------------------------------------
2030             20,565,553.125      0.40%  (estimate)

For the past years, I have calculated the amount of bitcoins created from first block to last block per year. The numbers starting from 2022 are estimates based on the assumption that we will add 52,600 blocks per year.

Update 2017:
It turns out that 2016 had 55,184 blocks (or an average block interval of 9.51 minutes), so with 54,000 blocks I had underestimated by 1,184 blocks. Thus, inflation rates might be slightly bigger than the estimate provided here, if that interval remains accurate. New estimates were still calculated with 54,000 blocks per year.
Update 2020:
2017 had 55,928 blocks, 2018 had 54,498 blocks, and 2019 had 54,232 blocks. Seems like we're actually finally getting closer to the 54,000 estimate, so I continue to use that for the estimate of the future years.
Update 2021:
2020 had 53,222 blocks. So, I've updated future estimates assuming 53,200 blocks per year.
Update 2022:
Added 2021 and blocks column. Realized that 2015-Murch had wrong numbers for 2012/2013 and corrected the whole table. Future estimates assume 52,600 blocks per year (we were very close to 10 minute blocks in 2021).
Update 2024:

Added 2022 and 2023.
Increased precision of inflation by one digit.
Future estimates still assume 52,600 blocks per year.


text:
If I offer a higher transaction fee, will my order get processed faster?
I was reading the wiki and it seemed to sugest that the transaction fees didn't play to much of a role in determining the priority of an order but rather the actual size in bytes and the previous amount of wait time are used.

priority = sum( input_value_in_base_units * input_age ) / size_in_bytes

but if I was a miner and I had the choice between two orders of equal size, I would always pick the one that offered the higher fee.
So for all of you miners out there, would my orders on average get processed faster?
Also it could just be that the current mining software does not discriminate based on fee size, but is it possible to write a miner which does?

DannyHamilton from bitcointalk says

At a minimum.  0.0001 BTC per kilobyte.  That would put you ahead of all transactions that are considered "low priority" which don't include a fee by all miners (and pools) that choose to use the reference implementation.
Given how low the exchange rate has been lately, you might even consider a fee of 0.0005 BTC per kilobyte.  This would put your transaction ahead of everyone that is using the 0.8.3 reference implementation for fee calculation and even with everyone using the older versions.  At the moment this works out to about 3.5 cents for an average transaction.

So the answer is yes, offering a higher transaction fee does speed up your transaction. Heres a link to the bitcointalk discussion.

source: Stack Exchange

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

sort: votes


text:
What is the approximate hashrate of a human?
Which and how much mathematical operations are required for the blockheader-to-blockhash operation and how fast would a human be able to calculate a single hash?
EDIT: For simplicity, I think it's a good idea to use the world record for mathematical calculations to make it a little more fair.

The user C121 on r/bitcoin explored this topic in the thread Mining Bitcoin by hand.
He states that it takes 3385 integer operations to calculate one double SHA-256 hash.
His conclusion was that you would reach about 0.00003 H/s, or in other terms, it would take about 9.4 hours for one hash, assuming the human in question could do a 32-bit operation in 10 seconds.
He also estimates that you would fill about seventy pages of paper with the calculations per hash.
Update:
As Mathias711 pointed out in the comments, Ken Shirriff actually calculated some SHA-256 operations manually and wrote an article about mining bitcoin with pencil and paper. He arrives at an estimate of 0.67 hashes per day, at a vastly uncompetitive energy consumption. ;)

Hmm, with a bit of pre-made tools (mechanical or not), we can actually steeply reduce this number right?

Do ASICs qualify as 'tools'?

This guy actually did it, and he reached 0.67 hashes / day.

I was actually just about to link this myself. I'm sure with practice you'd increase the number but humans make mistakes after hashing for long periods of time, I'm sure.

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


text:
Who wins the race for multiple valid blocks mined at the same time?
From my understanding, a SHA256 hash is generated by a miner and if the hash is less than a specific value, it is passed to its peers.  That said, It's possible for multiple hashes to be created at very close to the same time.  If this happens, how is the "winner" determined?  I see this has happened a lot (multiple orphaned blocks).
What can be done by the miner to see that their block wins the race, either honestly or through an attack?  The protocol stipulates that the block shall be recognized by which ever was received first.  Is it advantageous to set up peering with other miners?

When there's a fork, part of the network will mine to find the next block in one branch and part in the other branch. Whichever part finds the next block first will determine the winning branch.
A miner who finds a block will want to spread it widely and quickly. This makes sure there are many other miners who saw his block first, and thus a high probability that the next block will be found by one of those.

Is there anything a miner can do to send his block out more quickly?  Or to disrupt other miners from sending out theirs?

@Ben: Being connected to many nodes and having a fast internet connection could help. I don't know of ways to disrupt other miners.

Can anyone explain the downvote?

I am baffled by it.

A block is first verified before it is relayed.  So a block with fewer transactions will be verified sooner than a block with many transactions.  However trying to limit that will cause fees to be missed, so there's an economic cost that offsets the economic gain.

Theoretically, miners could form a coalition that would agree to mine after each other's found blocks, even if the block was found later, so long as the chain was the same length. I doubt it would be worth the trouble, but it would give members of the coalition a slightly greater chance of winning against a block found by a miner not in the coalition.

@DavidSchwartz: This sounds like the mining cartel attack (https://bitcointalk.org/index.php?topic=2227.0;all). It requires the cartel to have at least ~40% of the total hashrate to work.

@MeniRosenfeld: Very similar. I'm suggesting a much weaker version -- mine from the longest chain in all cases, but break ties between a cartel member and a non member in favor of the cartel member regardless of which block was seen first.

@DavidSchwartz: Yeah, that is simpler.


text:
How to activate the mining process in the standard bitcoin client?
I have done the whole synchronization and now it should be mining bitcoins from what I understand but I don't see anything showing that it is actually mining for bitcoins nor any activity from my cpu… Is this normal ?
Do I need to enter a command to start the mining process or is the process done automatically without having to do anything ?

Are you sure you told it to mine? It defaults off in Bitcoin-Qt, and it's pretty difficult to enable.

Really ? I did not know this.. Why don't they say this on bitcoin.org ?? Are you sure ?

Anyone as anathor theory or is this true ?

https://en.bitcoin.it/wiki/FAQ#Why_was_the_.22Generate_coin.22_option_of_the_client_software_removed.3F

ok thank you that helped! I am still very new to bitcoins and that is why I have asked...

I guess that I have missed to mining days. oh well. If anyone feels sorry feel free to send me a gift...

@Vincent they can't send you a gift if you don't publish an address... ;)

@Lohoris He put one, I flagged it as off-topic.

possible duplicate of How can I start mining Bitcoin?

bitcoin-cli -rpcconnect=127.0.0.1 generate 1

Warning: doing what is described below will not gain you any coins at all with exceedingly high probability, and just burn electricity (see other answer).
Bitcoin Core still has a built-in miner. It is not efficient, not optimized, does not use any special hardware (like special CPU instructions, GPUs, FPGAs, or ASICs), and is only useful for testing on test chains.
You can enable it by issuing the RPC command setgenerate true, and disable it with setgenerate false. These commands can be issued in the debug console in Bitcoin-Qt, or using an RPC client (like bitcoin-cli) to send it to a running bitcoind instance.

Update: The setgenerate RPC command for mining was removed in version 0.13.0

The solution don't work in the new version

You do understand that mining using a CPU is pretty much pointless? Please dig around on the wiki address provided by Nick for the specifics. Short version - it takes lots of dedicated GPU cards or specialized hardware to mine any measurable quantity. I've been running a Xeon workstation with a Radeon GPU for almost a month non stop and a) have yet to create more that a tenth of a bitcoin and b) have dramatically seen my electrical bill increase.

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


text:
What is the correct algorithm to calculate worker & pool hashrate
I need to display the pool and worker hashrates on my website.
The pool uses PSQL.

hashesPerSecond = math.pow(2, 32) * proofsOfWork / secondsElapsed
where proofsOfWork is the number of difficulty 1 proofs of work (aka shares) that the user or pool has found during secondsElapsed seconds.
If you use variable difficulty, then you can count a proof of work from someone mining at difficulty X the same as X proofs of work at difficulty 1.
For mhps divide by 1e6. For ghps divide by 1e9. And so on..
math.pow(2, 32) == 4294967296


text:
Can one GPU mine on Mac OS X using cgminer?
I succesfully installed cgminer on my mac but every time I try to run it I get the message
[2013-09-16 15:03:49] clDevicesNum returned error, no GPUs usable

why is this? Is it that you cannot mine with the GPU on a mac, or am I just doing something wrong?
Specs:

Macbook Pro (2011)
Mac OS X Lion 10.7.5
Intel HD Graphics 3000 384 MB

That generation of Intel integrated graphics does not have OpenCL support, which is needed for mining.

well that sucks, but thanks. Here is proof for what your saying.


text:
What does OP_CHECKSEQUENCEVERIFY (OP_CSV) do?
Some people have suggested repurposing OP_NOP3 as a new opcode, OP_CHECKSEQUENCEVERIFY.
What would the new opcode do? Why is it useful? Can't the signer choose the sequence field when they sign?

OP_CHECKSEQUENCEVERIFY (a.k.a OP_RELATIVECHECKLOCKTIMEVERIFY) can do relative lock times (used for sidechains and lightning).
It basically checks, if an input's sequence number is smaller than the sequence threshold (1 << 31 = 2147483648), and if so, it will compare the nLockTime against the sequence number of the input.
More info:

https://github.com/ElementsProject/elementsproject.github.io/tree/master#relative-lock-time
https://github.com/maaku/bitcoin/commit/fd9864c3a3c6f2942bc0775c6c725aa379f9d616
https://lightning.network/lightning-network-paper.pdf

OP_CSV (BIP112) only constrains the nSequence value. The comparison of nSequence against time happens independently of OP_CSV's usage (BIP68).


text:
Flaw in Bitcoin protocol regarding incentives to share transactions
Once the 50BTC per block rewards have halved many times and the transaction fees start to become the primary reward for miners, it sound like there is incentive for miners to not pass on transactions as they would eventually get the transaction fee when they next solve a block. I just read about this in Slashdot -
This slashdot article:
http://science.slashdot.org/story/11/11/15/0456206/researchers-locate-flaw-in-bitcoin-protocol
Refers to another article, being:
http://coderrr.wordpress.com/2011/11/13/simplified-summary-of-microsoft-researchs-bitcoin-paper-on-incentivizing-transaction-propagation/
and a research paper produced by Microsoft (who would've thought they're interested in Bitcoins!?):
http://research.microsoft.com/pubs/156072/bitcoin.pdf
An obvious solution to the described problem is to reward nodes for sharing transactions, but this (as I understand it) leads to a "Sybil attack" where the attacker tries to gain an increased share of the rewards by sharing the transaction amongst other nodes controlled by the attacker.
The rest of the research paper seems to have a proposed solution, but it's beyond my understanding!
Is this really a problem with the existing Bitcoin protocol? If yes, does the research paper have a genuine workable solution? Is it possible to describe that solution in laymen's terms?

After much discussion with David Schwartz, my understanding is: Currently there are so many nodes (miners and not) spreading transactions that there's no issue. If the situation changed, non-miners still have the (strong) incentive to spread their transactions as widely as possible, and miners have an incentive to ensure that they get them quickly. Simple changes to the way bitcoin works or even transaction distribution services would ensure that the 2 parties (miners & non-miners) get in touch. ie each party has an incentive to get something working. If correct, can someone summarise this?

This is a non-issue.  The Microsoft paper did not appear in a peer-reviewed venue (journal or conference).
There are (at least) two parts to the bitcoin network: the peer-to-peer transaction broadcasting network and the miners.  Only the miners have a disincentive to propagate transactions.  The overwhelming majority of the nodes on the internet running bitcoind are not mining or else are doing trivial amounts of CPU-mining because their admin forgot to use the -gen=0 flag.
If so-called "CPU-friendly" cryptocurrencies like "Tenberix" achieve their goals (which is doubtful) they may be vulnerable to this problem since they are intended to avoid the sort of specialized-miner situation that bitcoin embraces.

"The overwhelming majority of the nodes on the internet running bitcoind are not mining". I think this may well nullify the problem, but is it guaranteed? Is it possible for a malicious miner with many app instances (say, spread throughout a botnet) to get enough connections to a client to prevent the transaction being propagated as it should? I don't know how the client app decides who to connect to, and this could determine whether or not there's a vulnerability

Irregular, If you can prevent somebody from talking to the Internet, you can prevent them from using Bitcoin.  However, this is a "problem" that is not unique to Bitcoin...

That's not what I meant - what I mean is: is it possible to target a particular client to try to fill up all its connections with malicious nodes?

@HighlyIrregular You can fill up all its inbound connection slots, but then you're just preventing it from helping others. It will still make whatever number of outbound connections it is configured to make to nodes of its choosing.

I'm one of the authors of the paper you mention. We've written a summary of the paper aimed at the Bitcoin community in the hopes that it will help people to better understand the paper.
I hope this helps you as well.
Here is a link to the summary:
http://research.microsoft.com/en-us/people/avivz/bitcoin_red_balloons_summary.aspx

Your paper analyzes a 'problem' that arises only due to the assumptions it makes. There is no problem unless you assume that nodes respond to the incentive not to send transactions but don't respond to the incentive to receive them. That is an irrational assumption, and in fact your proposed solution it merely to discard the assumption. Why would you assume people would hold onto transactions without also assuming they would sell them? It is strictly this assumption that creates the problem. Both incentives arise concurrently. Why assume only one is acted on?

Aviv, your summary has a condescending tone and still willfully ignores the fact that only a tiny fraction of the nodes on the P2P network do any mining -- the rest of the nodes have no incentive at all to withhold transactions.

@eldentyrell I don't see the tone you describe. Besides, the tone shouldn't matter. The summary clearly states "So we suspect the problem is not currently occurring or is not severe at the moment", so the key thing to understand is whether it could potentially become a problem in the future (especially given that mining must at some stage change from hobbyist to commercial scale unless the fundamental architecture is changed).

All you have to do is broadcast your transaction to a few major mining nodes. Whichever mines a block first will have every incentive to include your transaction.
It is a silly argument anyway. To precisely the same extent nodes are incentivized not to share their transactions with others, nodes are incentivized to get transactions from others. It should cancel out perfectly
It it's is worth X for you to get a transaction from me, I may not give it to you for much less than X. But why wouldn't you be willing to give me just a bit less than X for it?

... it sound[s] like there is incentive for miners to not pass on transactions as they would eventually get the transaction fee when they next solve a block ...

That's absurd. The longer you hold onto a transaction, the less it's worth. You have no way to know how many other nodes have that transaction, and as soon as any miner includes the transaction in a block it is worthless. You have an incentive to get as much for the transaction as you can as quickly as possible from as many nodes as possible.

"All you have to do is broadcast your transaction to a few major mining nodes" - but this isn't currently the default behaviour, is it? That said, I don't actually know how the client does determine who to connect to!

"To precisely the same extent nodes are incentivized not to share their transactions with others, nodes are incentivized to get transactions from others. It should cancel out perfectly." - this doesn't cancel out at all. It provides an incentive to receive but not send.

@HighlyIrregular Same thing. The more incentive I have to buy coffee, the more incentive my local stores have to sell it. If you don't assume people respond to incentives, there's no problem. If you do, you have to assume people will respond to the incentive to receive transactions, likely by inducing others to send them transactions, those others will in turn respond to that incentive.

The coffee analogy doesn't work because there's an incentive for both parties in that case; the customer gets the coffee and the shop earns some money. With transactions, a miner has a monetary incentive to receive them, but no monetary incentive to pass them on as far as I can tell.

@HighlyIrregular You're missing the whole point. Forget about money, don't assume you know the answer. All you know is that the shop has coffee and that the coffee has value to the customer. The customer now has an incentive to try to get the shop to part with the coffee. The shop now has an incentive to try to get the coffee to the customer. In both cases, the incentive is to get some of the value of the coffee to the customer. The natural result of these incentives is the sale of the coffee (or trade or whatever). But all you need are the two matched incentives, then something will result.

To get that there's a problem here, you'd have to assume that the two incentives somehow both go unsatisfied by all possible mechanisms. That's a completely idiotic assumption. In this case, the transaction's value drops to zero as soon as any miner includes it in a block, so they have a strong incentive to resolve the situation fast -- otherwise, they both lose out. (It's like the coffee is about to spoil. They'll work out some deal. The shop may even loan the customer money to buy the coffee!)

"The shop now has an incentive to try to get the coffee to the customer" - I don't see how the shop has that incentive unless the shop is giving away free coffee for the good of society (ie it has some motive beyond the profit motive). To stretch the analogy a little further, a Bitcoin client has an incentive to notify as many coffee shops as possible that it wants a coffee asap (and is offering $x for it), but while coffee shop A is trying to race to make the cup of coffee it's in shop A's best interests to NOT tell shop B about the fact that the client is offering $x for coffee.

@HighlyIrregular If the coffee shop does not get the coffee to the customer, it cannot get any value from the fact that the customer wants the coffee. If the coffee shop does get the coffee to the customer, it can extract a fair share of the value of the coffee to the customer. (Again, forget about the money. It so happens that the way customers and coffee shops react to the incentives is by exchanging money. That doesn't matter. The point is, they react to the incentives.)

let us continue this discussion in chat

Have added a comment to the question summarising my perspective of the results of our discussion.


text:
What is a good way for someone to purchase Mining Bonds?
GLBSE is down, and so is PureMining, which used to give deterministic hash rate yields.
What are the alternatives? If someone wants to invest in Bitcoin mining, but doesn't want to own & operate a mining rig, what is a good way for him to do this?

You could use https://btct.co/ which is a virtual stock exchange similar to GLBSE.

Are there good mining bonds? Anything deterministic and reputable?

I hold Cognitive bonds. Up until now I got payed regularly. Whether this is the best investment I don't know. (I'm not affiliated with Cognitive).


text:
What is a 'Satoshi'?
I am aware that Satoshi Nakamoto is the author of the paper that originated Bitcoin and the creator of the original bitcoin client. However, I often hear the term Satoshi as if it was a monetary unit.
What is a Satoshi?

A Satoshi is the smallest fraction of a Bitcoin that can currently be sent: 0.00000001 BTC, that is, a hundredth of a millionth BTC. In the future, however, the protocol may be updated to allow further subdivisions, should they be needed.
Further examples of units

1 BTC = 1,000 mBTC (millibitcoin)
1 BTC = 1,000,000 μBTC (microbitcoin)
1 BTC = 100,000,000 Satoshis
1 mBTC = 100,000 Satoshis
1 μBTC (microbitcoin) = 100 Satoshis

Note that it's possible that future protocol versions will introduce amounts smaller than a Satoshi, if deemed required by the community. I'm not sure how likely this is. http://bitcoin.stackexchange.com/questions/122/will-we-ever-need-smaller-amounts-of-bitcoin-than-a-satoshi

@eMansipater It might be worth editing your answer just a touch to ensure that people don't think that there is a limit to the number of decimal places possible.

It's Michael's answer, but I updated it anyway.

Isn't one BTC a HUNDRED million Satoshis?

yes 1 btc is divided into 100 million satoshi

1 uBTC = 0.000001 BTC = 1 bit

@ripper234 not likely, when 1BTC = US$1,000,000 then 1 Satoshi will be exactly 1c.

@ripper234, I think the protocol would only update once 1 Satoshi is worth more than 1 cent or smallest denomination in one of today's fiat currencies since it would be needed by that culture that used BTC.

While not in raw Bitcoin, we are seeing milli satoshis now in Lightning Network

1 mBTC  = 0.001 BTC
1 mBTC  = 100,000 Satoshis

1 uBTC  = 0.000001 BTC
1 μBTC  = 100 Satoshis

1 Satoshi       = 0.00000001 BTC
100 Satoshis    = 0.000001 BTC
1,000 Satoshis  = 0.00001 BTC
10,000 Satoshis = 0.0001 BTC

1 BTC = 100,000,000 Satoshis
1 BTC = 1,000,000 μBTC
1 BTC = 1000 mBTC

1 uBTC = 0.000001 BTC = 1 bit

A Satoshi is 0.00000001 BTC and currently the smallest transaction unit.
If a Satoshi was equivalent to one penny, a microBTC would be equivalent to one dollar, and one BTC would be equivalent to 1,000,000 dollars.
With one BTC on the order of $1,000 USD, a Satoshi is equivalent to .001 penny

@Murch -1 on your comment. He words it different and different readers respond differently to different wordings. He apparently explains it the way he thinks about it. Not all readers have a high enough IQ to see all wordings as equivalent, thus there is value in multiple answers. See also my comment to Lohoris. Vertical screen and database space are not scarce resources. The Knowledge Age is a post-scarcity antidote to Malthusian propaganda. I tried to obviate your down vote, but another person down voted after I wrote this comment. Democracy is the LEAST common denominator.

@ShelbyMooreIII We disagree: You find it useful, I don't. That's quite alright though.

Most informative answer to someone who hits Google for "1 satoshi", e.g. for someone who encounters the term but knows little of BTC.

A Satoshi is a one hundred millionth of a Bitcoin.
Bitcoins are delimited to eight decimal places so even if Bitcoins are worth $1,000,000 each, you can still do penny transactions.

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.

@JohnBensin it doesn't add anything to the accepted answer, and it has been posted much later. Also, it includes a pointless "if (when?) Bitcoins are worth $1,000,000 each".

@Lohoris -1 on your comment. "Not adding anything" to prior answers doesn't constitute "not an answer". Clarifying that Satoshi is intended to be analogous to the penny if BTC attains sufficient valuation is addressing the question "What is a Satoshi?". I wish I could downvote your comment.

@ShelbyMooreIII but you can't, ha! That being said, no, I reiterate that repeating what has been already said is polluting the site and should be removed.

@Lohoris then your redundant comment should be removed for polluting the site as you've just restated part of what you wrote in the earlier comment. Also his answer is not redundant, e.g. see my comment to Murch under capecoralhobo's answer. P.S. note who I am, I've dealt with your poor Malthusian logic on PoW recently in Bitcointalk.org as AnonyMint in rpietila's altcoin thread.

If you need formula
108 Satoshis == 1 BTC
or in Python
def btc2satoshi(btc: float) -> int:
  return int(btc * 10**8)

BTC = 1.0
print(btc2satoshi(BTC))

@JeanMonet thanks for the fix! That was a dumb mistake, indeed. )

A 'Satoshi' is the smallest unit of the Bitcoin cryptocurrency and is named after Satoshi Nakamoto, the pseudonymous creator of Bitcoin. One Satoshi represents 0.00000001 BTC, or one hundred millionth of a Bitcoin.
In relation to Bitcoin, the concept of Satoshis allows for more precise transactions and flexibility in value, especially as the price of Bitcoin fluctuates. It enables users to transact with very small amounts of Bitcoin without needing to send a whole Bitcoin or even a large fraction of one.
Here's a detailed explanation of Satoshis with examples:
Denominations: Bitcoin can be divided into smaller units, much like how a dollar can be divided into cents. The smallest possible unit of Bitcoin is a Satoshi. To give you an idea of the relationship between Satoshis and Bitcoins:
1 Bitcoin (BTC) = 100,000,000 Satoshis
0.01 Bitcoin (BTC) = 1,000,000 Satoshis
0.001 Bitcoin (BTC) = 100,000 Satoshis
Transaction examples: Let's say you want to buy a digital product online that costs $1, and the merchant accepts Bitcoin as payment. If the current value of Bitcoin is $50,000, the equivalent value in Bitcoin would be 0.00002 BTC (1/50,000). In Satoshis, this would be 2,000 Satoshis (0.00002 x 100,000,000).
Microtransactions: Satoshis enable microtransactions, which are small transactions that may not be economically feasible with traditional currencies due to transaction fees. For example, if you wanted to tip a content creator 50 cents worth of Bitcoin, you could send them 1,000 Satoshis if the price of Bitcoin is $50,000 (0.00001 BTC).
Price precision: As the value of Bitcoin increases, using Satoshis becomes more relevant, allowing for more precise price representation and smaller denominations. For instance, if Bitcoin's value reaches $100,000, a $1 purchase would only require 1,000 Satoshis (0.00001 BTC) instead of 2,000 Satoshis at a $50,000 valuation.
In summary, a 'Satoshi' is the smallest unit of Bitcoin, enabling precise and flexible transactions, especially for smaller amounts and microtransactions. It also helps accommodate Bitcoin's fluctuating value, making it more practical for everyday use.


text:
How do I accept bitcoin payments at a real world store?
From what I understand, there are some requirements for using bitcoins at a physical store:

Both the store owner and the client must have Internet access
The client must have a cellphone or a laptop to issue the payment
The seller must have a way to confirm that the coins were sent.

The biggest problem is the confirmation. Since it is risky to accept transactions with 0 confirmations, it will take around 10 minutes before a single confirmation occurs and allows the real world transaction to be completed.  The more confirmations that occur, the less risky it is.
That said, what is the best way for a store owner to securely accept bitcoins?

Here is a proof of concept of a Bitcoin Point of Sale system.

I guess that you are talking about the title, cause the text clearly ends with a question. In this case, just suggest an edit of the title, don't vote to close.

I think this is is an excellent question and if you have a problem with it, edit it and contribute or just go away.

Green address technique from Instawallet. System sends bitcoins from well known address called Green Address and if recipient trusts Instawallet or any other major organization that uses same technique, then he or she can accept payment without waiting for confirmations. This is what already implemented but it solves only the third problem.
Instant TX for established business relationships is in early development stage but it can solve all three of the problems, with an exception that only retailer needs to have internet access. For example, transaction could be printed by customer on a piece of paper, handed over and accepted instantly by retailer, and it still would be secure. The idea is very promising because such transaction could be sent over internet or by any other way directly from buyer to seller and won't use any of Bitcoin Network resources, and it would be economically fisible to make automatic payments for a service that costs several micro bitcoins.

One thing people fail to realize when saying "0 confirms are risky" is that risk is all relative.  A lot depends on how valuable the goods are.  While 0 confirmation may have some risk it is very low for low value transactions and likely far less than credit card fraud.
Say you are selling a sandwich for whatever $5 is worth in BTC.  When you get a 0 confirm it has indicated that your client sees that address has sufficient value to complete the transaction.  The risk is simply that before confirmed someone else could purchase something with the same address, a hypothetical "double spend".
Still remember the window of attack is very small. The AVERAGE block completion time is 10 minutes but ~50% of blocks are completed in less than 6 minutes.  That means if two attackers timed it so they started their attack right after a block was discovered they have roughly 50% chance of getting both transactions completed prior to next block verification.
To be defrauded BOTH transactions would have to be fully completed and the attacker gone within that window.  For low value transaction especially in the real world that is incredibly unlikely.  No attacker is guaranteed any sort of "minimum window" the next block might be verified in 10 minutes or in 9 seconds.
Now if you are selling $100K worth of gold then maybe you should wait for 6 confirmations but a customer moving $100K worth of gold likely would understand the need for security.
Unless your physical world business involves both fast transactions AND high street value I wouldn't worry.  A bitcoin ATM however would be a good target for double spending thus some other mechanism would be needed to verify the transfer.

What could be a secure mechanism to verify the transfer in a bitcoin ATM scenario? It wouldn't be feasible to have the customer wait for 10 minutes before she can grab the withdrawn cash, let alone an hour.

On related note, the Subway sandwich restaurant near my university do accept bitcoins with zero confirmations.

For transactions of under $100 or so, I don't think it's unreasonably risky to accept transactions with zero confirmations. For one thing, it doesn't matter unless the customer is attempting a double-spending attack, and it's unlikely someone would want to attempt such an attack and try to physically get away within 10 minutes or so just for $100.
For under $1,000, 1 confirmation is sufficient. That takes 10 minutes on average.
In general, face-to-face transactions just aren't all that risky.

Accepting bitcoin is easy. Create an account on coinbase.com
Go to:
Linked Accounts -> Link a bank account.
then
Merchant Tools -> Merchant Settings ->
Check, "Instantly exchange my bitcoins to USD and credit my primary bank account once a day."
Add this to your event description:
"Bitcoin Accepted w/ coinbase to info@yourdomain.com"
If you want a bitcoin logo you can use this: http://i.imgur.com/s7YQ2.jpg
Here are examples of other companies accepting bitcoin:
http://blog.coinbase.com/post/48102298494/okcupid-starts-accepting-bitcoin-using-coinbase
http://en.blog.wordpress.com/2012/11/15/pay-another-way-bitcoin/

Create a "We accept Bitcoin!" display:
http://ma.eatgold.com/accept/
If you want to verify that bitcoins have been received you can look on blockexplorer.com.  The format is http://blockexplorer.com/address/1At6LdqJsMJ11kkujzU4NR5cbD5NhLj3Ay . You can see a list of all transactions received on your wallet address.
You can get a receiving address from online exchanges or wallet services. I recommend you find one you can trust because they will be holding your coins.
My recommendation is ExchB:
https://www.exchangebitcoins.com/en/r/howmanycoins
Another option is to download the bitcoin client from bitcoin.org. You must make sure your computer is secure from trojans or viruses or you could lose your coins. Or you could use an android based application for your mobile phone. Bitcoin Wallet is the most efficient app currently. Here is a link to it: https://market.android.com/details?id=de.schildbach.wallet&hl=en . Take care your phone is secure from viruses or malicious applications that could steal your wallet. Transfer any large amounts of coins off of your phone and to a secure address elsewhere.
To check the exchange rate for converting your product prices you can pull up the current price at http://coin.ly/ , or many other sites have this information as well.
You can also use a merchant services company such as bit-pay.com to handle all this stuff for you in an automated fashion. They offer additional features such as converting bitcoins into USD immediately so you dont have to deal with all the extra details and risks of handling bitcoins on your own.

downvote with no comments? UPVOTE!!!!


text:
What are checkpoints?
I often read that checkpoints protect the network from a 51% attack because an attacker cannot reverse transactions made before the last checkpoint.
How exactly does this checkpoint mechanism work? And who creates the checkpoints?

The checkpoints are hard coded into the standard client. The concept is, that the standard client will accept all transactions up to the checkpoint as valid and irreversible. If anyone tries to fork the blockchain starting from a block before the checkpoint, the client will not accept the fork. This makes those blocks "set in stone".

So a checkpoint is usually created everytime the client is updated?

As far as I know, yes, but it is all in the hands of the developers.

Would there be any way to make this behavior official? Something like "If the block was published to the network over a year ago, it is set in stone" which does not rely on the developers? This seem to be one of the few places where Bitcoin developers have a lot of authority, and it seems they generally work to keep that authority minimal.

@DanielH I don't see why some automatic algorithm couldn't be implemented that would be choosing suitable checkpoints during each code update. I guess you can propose such a feature on the forum or the github project page.

We really plan to get rid of checkpoints, or at least significantly reduce their power. They don't actually add any security (if they would actually affect the chain, the system is already broken).

@PieterWuille@ThePiachu: I didn't find any checkpoints hardcoded in main.cpp, checkpoints.h, checkpoints.cpp...Can you tell where the first checkpoint is placed?

They are chain-specific data, and have thus been moved to chainparams.cpp now.

@ThePiachu Thanks for the answer. But, the question is, in a case where there's no checkpoint,  why would client accept a chain shorter than what he already has?

Update on this as of time of writing, just to clarify more specifically upon the other answer: dependence on checkpoints in the security model has been significantly reduced, they are only used in one very specific case now. That case is just to ignore forks from the chain early on, before the most recently seen checkpoint. When a node has seen a block it recognises as a checkpoint, any further blocks received below that height will be ignored.
You can see this here: https://github.com/bitcoin/bitcoin/blob/0dfc25f82a01d9fec26380d95915df31e1fe2c02/src/validation.cpp#L3107
It is a long term goal of removing the checkpoints entirely, because they are a source of confusion over the security model and power the developers have. But currently the role they serve is to prevent low difficulty header flooding attacks, and there has been no alternative solution proposed yet (that I know of).

so every node maintains a list of checkpoints? who decides which blocks get added to the list of checkpoints?

@Auburn the list of checkpoints is hardcoded here: https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp#L153-L167
No new checkpoints are ever added anymore, the last was added on Jul 16, 2014

there has been no alternative solution proposed yet (that I know of).

Sure there have been. E.g. increasing the minimum difficulty for any alternative chain. Or changing the logic used to fetch headers to be able to explorer a competing fork without saving it.

2022 update: an alternative technique to prevent low difficulty header flooding that does not rely on checkpoints (only on the even weaker minchainwork value) has been merged: https://github.com/bitcoin/bitcoin/pull/25717

Bitcoin consensus algo is probabilistic (rather than deterministic) so in theory there is always the possibility of reversibility. The checkpoint  gets around that by setting how far back it with even consider looking for blocks to verify.

AIK there‘s one big use case so far for checkpoints and there‘s actually no golden path to achieve that otherwise.
Let‘s say one has a really really lot of computing power and intentionally or accidentally starts mining at a very low difficulty. Then all nodes were „forced by the rules of consensus“ to check that blocks for validity even there is praktically low to now chance they catch up the entire blockchain. On a time critical node that kind of behaviour could at least create disturbance.
Checkpoints are a tool against that. The node will only check higher blocks than the last checkpoint anf hence „focus on real (trans)actions on the net“.

This hasn't been the case since the introduction of headers-first synchronization in 2014 (https://github.com/bitcoin/bitcoin/pull/4468), which meant that blocks won't even be fully downloaded in case they're not on a chain of headers that leads to a tip with a promising amount of work. This did leave open a weaker version of that (header spam), but that has been addressed since the introduction of headers presync (https://github.com/bitcoin/bitcoin/pull/25717) last year.

Thanks for the deeper insights @PieterWuille it is hard to keep pace with the developments. I appreciate to get deeper understanding.
Well, checkpoints are now obsolete. Are they already removed? The Go implementation btcsuite/btcd still supports it.

They're not removed no; there is little harm in leaving them around, but they'll likely be removed from Bitcoin Core at some point. I also don't think btcd has anything like Core's header presync logic, but whether particular software implements and/or keeps something like these checkpoints is their own decision.


text:
Java library for Bitcoin Client Application
are there Java libraries for Bitcoin available to develop client applications?

BitCoinJ
In addition to @D.H's answer, BitCoinJ provides the following for developers

open source through Subversion
easy to use Java API
easy to integrate via Maven
access to either release or snapshot editions depending on your risk profile

BitCoinJ also uses the Bouncy Castle encryption algorithm implementations. Some of these were missing or poorly implemented in Android which necessitated the inclusion of these libraries into BitCoinJ (currently via the Maven Shade plugin to allow updates to Bouncy Castle to be introduced when they occur).
These inclusions makes it a very useful library to get started with than simply rolling your own against the JSON API of the standard client.
Disclaimer: I'm a contributor to the BitCoinJ project so I'm a bit biased regarding it's utility.
BCCAPI
A transaction and balance monitoring API for Java.
From the website:

The BCCAPI (BitCoin Client API) allows you to create a light-weight
  secure Bitcoin client in Java. The BCCAPI connects to a server that
  holds the block chain, and which tracks the client’s wallet balance on
  the clients behalf. The server only has knowledge of the clients
  public keys, and is in no position to spend funds owned by the
  client’s wallet.

This could be useful if your application does not require the client to spend coins through your system.
Off topic: A note on Bitcoin clients in Java
Although it's not a library as such, you may benefit from looking at the source code for the MultiBit project to get you started in creating a Java Swing based Bitcoin client based on BitCoinJ with internationalisation and QR code support.

BitcoinJ is the most mature library to my knowledge (though it is still at an early development stage). It has been developed by Google employee Mike Hearn.

BitCoinJ implements the "simplified payment verification" mode of
  Satoshis paper. It does not store a full copy of the block chain,
  rather, it stores what it needs in order to verify transactions with
  the aid of an untrusted peer node.

The above makes it especially useful for mobile applications.


text:
What are the risks of exchanging Bitcoins via Near Field Communication?
What are the risks of exchanging Bitcoins via Near Field Communication? The transaction Parameters might be negotiated via NFC and the actual transaction via Internet.


text:
Are the miners to decide if a consensus rule is accepted or not? Or are the buyers in power?
I get the impression that every time a consensus rule change is suggested then people assume that the miners/mining pools have the last word if this rule accepted or not. But isn't it up to the buyers?
Take the blocksize limit for example: A lot has been talked about which pool would go for which approach regarding the blocksize. Now let's assume one part of the miners would got for approach "big blocks" and the other would go for "small blocks". This would result in a fork of the blockchain: Bitcoin would essentially be split into two currencies: BigBlockBitcoin and SmallBlockBitcoin.
If I where to buy some Bitcoins after such an event, then I'd expect Bitcoin exchanges to offer me these two coin types. I would be able to buy the coins mined under the rules I like, it would not matter if they where mined by 90% of the miners world-wide, or by 10%.
Eventually one approach would lose traction and the coins value. So isn't it ultimately up to the buyers to decide if a coin is successful or not?

Yes. Even more direct: owners of Bitcoins before the fork will suddenly own both types of coins after the fork and can start selling the side they don't want.
However, in general, this is a very messy and damaging way of deciding consensus: in times of uncertainty a lot of people will decide to move to USD to sit out the storm (causing both sides to drop in price). Another fact is that a lot of people do not follow all the day to day drama and will not notice the fork until they're too late. Those people will take the largest losses.
Those things combined make it a further red flag for people considering investing in Bitcoin in the first place: why invest in something that radically changes course every x years through dramatic and damaging civil wars? Where you could be the one losing out if you blink your eyes. A currency needs stability to become trustworthy.
Also: Miners do have to make a choice fairly quickly after a fork, if they mine the wrong side, they will lose a lot of money. And yes users should not want to stay on a 10% mined chain very long: 10% security means that a 51% attack is incredible easy, so that coin would not have enough security to really survive.
All in all it's much better if consensus is reached in a peaceful manner. Luckily the long term goals of both miners and devs are fairly well aligned with the long term goals of users, so those coming to a consensus says a lot. As well as that users (as a group) have a lot of influence over what devs do or don't do (as is the nature of open source), as well as pressure over miners.

Miners can decide which forks to mine, but they still have electricity bills to pay.  The suppliers of that electricity only accept fiat (for now), so that means miners rely on exchanges in order to stay in business.  If a miner's exchange doesn't acknowledge the fork they are mining, then they can't use their revenue to pay their expenses, and will go out of business.  Exchanges, however, don't have the final say either.  They make their money from the fees paid by the users of the exchange, so they make their money by volume.  If they have to choose between forks, they will choose the one with the most customer demand.  That demand, in turn, is determined by merchants who accept bitcoin.  They, like the exchanges, will choose forks based on customer demand.
So yes, customers have quite a say in the matter, even if indirectly.  Bitcoin is an ecosystem, and there is no single decision maker within an ecosystem.  If the electric company starts accepting bitcoin directly, the exchanges will be less relevant...unless the electric company needs to pay for coal in fiat.  Things can and will change, but ultimately, it's the market as a whole that decides.
The whole thing reminds me of a riddle from A Clash of Kings.


text:
Bitcoin Block Size - What are the rules?
What is the maximum size a block can be?
Is there a minimum size?
Can you have a block with 0 transactions included?

The current maximum block size is 1MB (but it could be increased in the future with a protocol change), there is no minimum size per se, but the block needs to have all its components to be valid (check Protocol Specification). Each block needs to have at least one transaction - one paying the miner the reward for mining the block.

1MB is sufficient for roughly 2400 transactions (or 4tps).  The exact size of an individual transaction depends on the number of in/out addresses.  Over the last 1000 blocks, block size has averaged 17KB with 40 transactions putting average transaction at ~420 bytes each.  The protocol can support larger block sizes.

"Each block needs to have at least one transaction - one paying the miner the reward for mining the block.". How does that work once mining has stopped? Of course, that is still a while off...

When the mining stops, there won't be blocks to generate;). Mining won't stop, due to the transaction fees and what nots. I'm guessing that over 150 years from now, when new coins won't be created any more, and on an odd block that won't have any fees, the first transaction will be sending 0 coins to yourself.

@Thilo Mining (better term is hashing) never stops.  Hashing blocks into the block chain is required part of Bitcoin network.  The "end game" goal of Bitcoin is for transaction fees to pay for the cost of the network.  Currently fees are insufficient so miners get a block reward which is essentially a subsidy. Those subsidies will slowly decline and be replaced with transaction fees.  There is always a coinbase transaction (reward + fees).  As ThePiachu pointed out if the block reward & fees are 0 that transactions still exists and simply be 0 BTC sent to the miner.

Since the segwit upgrade, Bitcoin blocks are restricted to 4,000,000 weight units. Witness data counts towards that limit 1:1 (one byte is one weight unit), while non-witness data counts towards that limit 1:4 (one byte is four weight units).
While theoretically a block could therefore be up to 4,000,000 bytes if it consisted only of witness data, there are a few parts of transactions that are never witness data. Many blocks now exceed 1 MB with the average blocksize being around 1.3 MB these days (end of 2022). The biggest block so far was 748,918 with 2,765,062 B.
As ThePiachu explained, every block must have at least the coinbase transaction to be valid.
Update in November 2023:
Since May 2023, the average block size has been around 1.65–1.7 MB. The biggest block so far was 786,501 with 3,978,938 bytes.
You can find a chart of average block sizes on transactionfee.info.


text:
Nonce size - Will it always be big enough?
If I understand correctly, the block only has 4 bytes (32 bits) for the nonce.
Is it possible for the difficulty to become high enough that there are no nonce solutions?
If so, then what options does a miner have?

Since David already has a solid answer I will just make a trivia comment.  Even with a difficulty of 1 there is a 36.7% chance of not finding any valid hash in the entire nonce range (2^32).  At 1 million difficulty there is a 99.999905% that you will not find a solution in the entire nonce range.  Luckily any other change to block header allows you another 4 billion tries.

The difficulty is already to the point where it requires over a quadrillion hashes to solve a block. 2^32 is only 4 billion. Fewer than one in a billion times will there be any nonce that makes the block valid.
A miner simply has to try every possible nonce on a different block. He can vary the coinbase, the transaction set, and/or the block timestamp. Any change to any of these things results in a new chance for there to exist a valid nonce.
Often the best choice is to bump the timestamp, a practice called NTime rolling.
The block timestamp doesn't have to be exact anyway, so you can back the timestamp back, say, ten seconds before you start mining and then bump it up 20 times before giving up and getting a new block. At worst, your block timestamp will be off by a dozen seconds or so -- nobody cares about that.
After that, you probably want to get a new block because there might be some new transactions to include -- this not only improves the efficiency of the network as a whole but reduces the chances you'll miss out on a transaction fee.

By my calculations, a miner at 270Mhash/sec will run through 2^32 nonces in about 15 seconds! Are these techniques you speak of performed by the bitcoin server or the miner?

Typically these changes are done by the Bitcoin node (eg mining pool server). The timestamp could potentially be changed by the miner but I don't think that's done. Changing the extraNonce in the generation transaction is harder, but I think requires only its Merkle branch and not the entire block. Adding new transactions definitely requires the node.

@MeniRosenfeld While tranditionally these changes were performed by the pool it is highly inefficient. The NTimeRolling option allows the miner to locally increment the timestamp.  The pool only needs to calculate new headers on block change, periodically for new transactions, or when NTime rolling expires.

Seems to me that the nonce should have been designed to be at least 64 bits not 32.  Surprised by the lack of foresight here.  Perhaps the block header could be redesigned?

Whether or not there is a solution depends on the contents of the block as well as the possible values of the nonce.
The transaction block can be altered if necessary which essentially means you get another 32 bits of nonce values to try. There is an additional component of a transaction block called the "coinbase" that can be altered without altering the actual transactions within the block. This has been in the past to insert short messages into the block chain.

The Coinbase value can be used to insert a small string, such as described here: http://bitcoin.stackexchange.com/a/26/516

but you would need to re-calculate the Merkle root if you change the coinbase tx? Or it doesn't change its hash?


text:
How is the bitcoin 21 million cap implemented?
Just to check what would take for that limit to be changed. (not that I want to be changed, quite the opposite). I know the total number of bitcoin reward is halved every 4 years.
So does the verifying nodes check if the number of rewarded bitcoins match the distribution schedule?

Every node in the Bitcoin network checks every block it receives and validates any transactions in it. As coin generation is a transaction that is included in the block, it is also checked. Same as a node would not accept a transaction that does not balance its inputs and outputs (for example, by spending more coins than it has), neither would it accept a block reward different, than the one that is scheduled to occur (50 coins currently, half of that for some number of blocks, and then other fractions of that amount). The nodes know what rewards to expect based on the block number, as it is set to half based on that number.
To change it you would have to (convince people to) change all the clients, exactly like any other protocol change.

The software in the bitcoin client verifies that each transaction follows the algorithm that is part of the protocol.
Now even if the developers of the client were to somehow conclude that increasing the limit was a good idea and were to then push that client out for distribution, those holding bitcoins would likely not accept the new client.  There would then be a fork in the blockchain as the limit increase would devalue the currency already issued and therefore it would be rational to those holding bitcoins already would protect the value of their currency by not accepting transactions from the new fork.
So to change the limit you not only need to get the developers to make the changes that fork the blockchain but also you need to get exchanges and merchants to accept transactions using the fork -- something that, in this case, is irrational.

Bitcoin source code: https://github.com/bitcoin/bitcoin/blob/master/src/main.cpp#L1053

@StephenGornick In order to see the code that limits bitcoin to 21 million, am I supposed to read down from line 1053?  Is there an english translation of the code anywhere for non-coders? thanks

Well, the source code is continually changing, so a pointer to a specific line of code in "tip" (the latest code that exist) will be obsolete in a short amount of time.

The code to look at is the GetBlockValue function.
The block subsidy started out at 50 but is halved every 210,000 blocks.  So the english translation basically is "if block 1 through 210,000 then award 50 XBT per-block, if block is 210,001 through 420,000 then award 25 XBT per-block, if block is 420,001 through 630,000 then award 12.5 XBT, etc.   Eventually (like a hundred some years from now) the reward is so small, there is no block award remaining to issue.

An updated answer.
First, check out the block subsidy calculation: https://github.com/bitcoin/bitcoin/blob/v23.0/src/validation.cpp#L1417
CAmount GetBlockSubsidy(int nHeight, const Consensus::Params& consensusParams)
{
    int halvings = nHeight / consensusParams.nSubsidyHalvingInterval;
    // Force block reward to zero when right shift is undefined.
    if (halvings >= 64)
        return 0;

    CAmount nSubsidy = 50 * COIN;
    // Subsidy is cut in half every 210,000 blocks which will occur approximately every 4 years.
    nSubsidy >>= halvings;
    return nSubsidy;
}

An important constant: consensus.nSubsidyHalvingInterval = 210000 comes from this file here:
https://github.com/bitcoin/bitcoin/blob/v23.0/src/chainparams.cpp#L67
Right now the current block height is 704673 (you can look it up here if you like: https://blockexplorer.one/bitcoin/mainnet)
halvings = int(704673 / 210000) == 3
So the current reward 50 >> 3 == 6.25
The sum of a series that halves like that is a/(1-r), where a is the first value (50) and r is the ratio (0.5). See: https://en.wikipedia.org/wiki/Geometric_series for more info.
Thus 50 + 25 + 12.5 + 6.25 + 3.125 + 1.5625 + … + 0.000000001 = 100
Since the same amount is given per block, you need only multiply that by the total number of blocks issued per halving:  210000
210,000 * 100 == 21,000,000
Bitcoin is an open source consensus protocol.  It's not a company, there is no "foundation", and the code can be reviewed by anyone with about a high school level of knowledge of math.


text:
What is the block maturation time?
I was reading the wiki article about the blockchain and I didn't understand the part in bold:

When a block becomes an orphan block, all of its valid transactions
  are re-added to the pool of queued transactions and will be included
  in another block. The 50 BTC reward for the orphan block will be lost,
  which is why a  network-enforced 100-block maturation time for
  generations exists.

I don't know the details behind block creation and acceptance, so how does the block maturation time work? Is the block only accepted after a while?

Generated coins can't be spent until the generation transaction has 101 confirmations. Transactions that try to spend generated coins before this will be rejected.
The reason for this is that sometimes the block chain forks, blocks that were valid become invalid, and the mining reward in those blocks is lost. That's just an unavoidable part of how Bitcoin works, and it can sometimes happen even when there is no one attacking the network. If there was no maturation time, then whenever a fork happened, everyone who received coins that were generated on an unlucky fork (possibly through many intermediaries) would have their coins disappear, even without any sort of double-spend or other attack. On long forks, thousands of people could find coins disappearing from their wallets, even though there is no one actually attacking them and they had no reason to be suspicious of the money they were receiving. For example, without a maturation time, a miner might deposit 25 BTC into an EWallet, and if I withdraw money from a completely unrelated account on the same EWallet, my withdrawn money might just disappear if there is a fork and I'm unlucky enough to withdraw coins that have been "tainted" by the miner's now-invalid coins. Due to the way this sort of taint tends to "infect" transactions, far more than 25 BTC per block would be affected. Each invalidated block could cause transactions collectively worth hundreds of bitcoins to be reversed. The maturation time makes it impossible for anyone to lose coins by accident like this as long as a fork doesn't last longer than 100 blocks. If a fork does last longer than 100 blocks, then the damage caused by invalidated transactions would likely be a huge disaster. (However, something else would have to be seriously wrong with Bitcoin or the Internet for a fork to last this long.)

Actually, the network rules require a difference of 100 between the creating block and the spending block, which corresponds to 101 confirmations.

@theymos What is the exact purpose of this? Why is the usual 6 confirmations for a transaction not sufficient?

@Jori I updated my answer with that info.

It's unclear why this "disappearing coins" argument works. Temporary forks can also affect regular transactions that were made during a temporary fork. When the temporary fork is abandoned, these transactions are reversed, causing, again, "coins to disappear". Wallets (such as EWallet in your example) should wait for k-deep confirmation before showing coins as confirmed, whether these pertain to coinbase coins, or normally transferred coins. Even lacking a double spending attack, a temporary fork can cause coins to disappear in case the blocks in the canonical chain are full.

@PieterWuille: If the consensus rules require a difference of 100 blocks between creating block and spending block wouldn’t that mean that the coinbase output has 100 confirmations when it’s spent? Otherwise, it would be able to be in the block that gives the 101st confirmation to the coinbase output.

A coinbase UTXO created in block number n can be spent in a txin in block number n+100. The creating transaction, in block n, at the time it is included, has 1 confirmation. 100 blocks later, it has 101 confirmations.

@PieterWuille: I guess our crossed wires are about “when an output gets spent”: at the time that you create the spending transaction and it gets included in the block template, the coinbase output only has 100 confirmations. When the transaction that spends the coinbase output gets confirmed, the coinbase output gets its 101 confirmation.

@Murchisonstrike Right, I was talking about consensus rules. They don't care about when you create a transaction or when it can get relayed.

FWIW, when I commented above, in 2012, non-final transactions (ones with a locktime far in the future, e.g.) were still relayable and accepted into the mempool of the reference client (changed in PR 2223, in Jan 2013). I'm not sure whether that was also the case for immature spends.

A block is accepted immediately (assuming it is valid) the maturation time applies to the coinbase reward to the miner found in the block (bock subsidy + tx fees).
The purpose is to prevent a form of transaction reversal (most commonly associated with "double spends") if the block is orphaned.  If a block is orphaned the coinbase reward "ceases to exist".  The coins are produced from the block and when a block is orphaned it is the replacement blocks version of the coinbase tx which is considered valid by the network.
Transactions which use non-coinbase coins as an input are not affected.  If a block is orphaned then any tx which was confirmed in the orphaned block and not confirmed in the block which replaced it will return to the memory pool and be included in a future block.
Generated coins however cease to exist when the block is orphaned.  If the network allowed miners to spend them immediately it would be the recipient of the coins not the miner who would suffer a loss from the miner's block being orpahned.
So to avoid that undesirable situation the network requires coinbase tx (rewards to miners) to "mature" or wait 100 confirmations (the client makes this 120 confirmations but only 100 is required by the protocol).  If a block is orphaned before it gets 100 blocks deep into the chain, then only the miner is affected.

We require a maturation period for coinbase outputs, because any two blocks at the same height will condemn at least one coinbase transaction to never exist in the best chain. If users were able to immediately spend coinbase outputs, perhaps even in the same block, even short reorgs could invalidate entire trees of transactions descending from the coinbase outputs of an extinct chaintip. This would create a big attack surface for scams, and incentives for reorg attacks.
While a reorg might return some non-coinbase transactions to the mempool, in organic chainforks block content would largely overlap anyway, and any transactions not included in either tip, would simply still be in the mempools of nodes following that chaintip. For the most part, a reorging miner would only be able to delay confirmation, but not permanently invalidate any transactions created by third parties. Transactions would only get invalidated in the case that a sender is actively creating conflicting transactions to doublespend while there are competing chaintips. In contrast, coinbase transactions could be written out of existence by a third party, rather than the original transaction creator.

Generated coins can't be spent until the generation transaction has
101 confirmations.

I find the quoted phrase from the accepted answer confusing, especially because it is easy to get lost in a meandering philosophical debate about when exactly a UTXO is spendable, when an output is spent, and at what point the confirmation count increases.
A transaction that spends an output of the coinbase transaction at height h, is eligible to be included in block h+100 or higher. Transactions that are eligible to be included in the next block will be accepted in the mempool, used to build block templates, and relayed on the network. This means that miners may include such a transaction in their block template when their chaintip has a height of h+99.


text:
What are "bitcoin days destroyed"?
The concept of bitcoin days destroyed has been proposed as a measure of bitcoin volume. However, I don't think the bitcoin wiki really explains the idea very well.
What is the purpose or advantage of knowing this statistical value?

Update:  that would be http://news.ycombinator.com/item?id=3008672 apparently.

@eMansipater also the transaction page on blockr.io (how I arrived here!)

The idea of "bitcoin days destroyed" came about because it was realised that total transaction volume per day might be an inappropriate measure of the level of economic activity in Bitcoin.  After all, someone could be sending the same money back and forth between their own addresses repeatedly.  If you sent the same 50 btc back and forth 20 times, it would look like 1000 btc worth of activity, while in fact it represents almost nothing in terms of real transaction volume.
With "bitcoin days destroyed", the idea is instead to give more weight to coins which haven't been spent in a while.  To do this, you multiply the amount of each transaction by the number of days since those coins were last spent.  So, 1 bitcoin that hasn't been spent in 100 days (1 bitcoin * 100 days) counts as much as 100 bitcoins that were just spent yesterday (100 bitcoins * 1 day).  Because you can think of these "bitcoin days" as building up over time until a transaction actually occurs, the actual measure is called "bitcoin days destroyed".  This is believed to give a better indication of how much real economic activity is occurring on the bitcoin network.
So how well does it work?  Well, it's still not perfect, because the other day I moved some coins out of a wallet they've been in for several months without spending them or giving them away.  And some genuine businesses have very rapid turnover in bitcoins, so they're not being measured well by this method.  But it does do a good job of filtering out the "noise" of bitcoins that are just "bouncing around" without really going anywhere.  The graph of overall bitcoin days destroyed is believed to show that the genuine level of activity in the Bitcoin economy is continually increasing--it's not just one person experimenting by rapidly sending the same coins back and forth, flooding the network with meaningless chatter.  Looks pretty good, hey?

Image from the Bitcoin wiki.  The above graph is in percentage of bitcoin days destroyed and a little out of date--for a regularly updated version in bitcoin days destroyed check out Bitcoin Days Destroyed - Active Chart instead!

+1 for excellent explanation! What are the dates for the start and end of the graph?

Details are available at the wiki, as well as a larger version.  It's by block number, but it goes from 0 to about June 17th.

Thanks!  But note that the graph is not of bitcoin days destroyed, bur rather of the percent of total possible bitcoin days-to-date destroyed.  And there's probably a better way to say that :)

Link to banana.mine.nu is 404.

@Aldekein yeah, does anyone know an equivalent link I can replace it with?

Unfortunately it seems the current link to  'Bitcoin Days Destroyed' is no longer valid. Fantastic explanation.

It seems that a regularly-updated graph of Bitcoin Days Destroyed is at http://banana.mine.nu/daysdest.html
But note it differs from the graph on the wiki in that it seems that it graphs "bitcoin days destroyed", rather than "percent of bitcoin days-to-date destroyed".  The latter is what ABE labels "% CoinDD", which he reports as 36.1245% as of block 145677 at 2011-09-17 06:18:18.
But the calculations seem to have other differences.  E.g. the ABE result for block 131400, which was also around June 17 2011, was "Cumulative Coin-days Destroyed: 35.1672%", but the value from the wiki graph is about 28% on June 17.  The corresponding value on the banana.mine.nu graph is about 900,000,000 bitcoin days.
I'd say that in general a graph of "% CoinDD" seems much more helpful than a raw number which always goes up.  Note e.g. that according to ABE, the percent value has barely increased between June 17 and Sep 17. Is there any regularly updated source for a percentage-based graph?
By closely watching this metric you can identify upward spikes which are likely times where early bitcoin adopters may be "cashing out" or spending their early coins.  But note that they could also instead just be moving coins around internally, e.g. moving coins to a better-protected wallet.  But "% CoinDD" is still less affected by such movements than the overall transaction volume metric is.

Hope you don't mind nealmcb, but I'm just going to incorporate this into my answer.  Upvoted anyway for the useful link!  I don't know of any regularly updated source for the percentage version, but the conversion is fairly straightforward.

@eMansipater Sure - it's all CC licensed :).  Thanks to Andrew Jones for the pointer, from http://bitcoin.stackexchange.com/questions/919/bitcoin-usage-charts

One big thing here, neal--ABE is measuring "cumulative bitcoin days destroyed" which is quite different from percentage bitcoin days destroyed each day.  The latter, which is graphed above, measures daily activity and can easily go above 100% (more bitcoindays destroyed in a given day than are created) while the former measure, being cumulative, is essentially measuring the average age of bitcoins sitting around, relative to the highest (100) and lowest (0) amounts possible.  If I have a chance I may update my answer to explain this in more detail.

Graphing
Bitcoin Days Destroyed weights the past dormancy of coins that have been transferred over any chosen period. The histogram of the percentage of Days Destroyed graphs distribution of dormancy over the measured period.
The graph is a histogram showing the percentage of total Days Destroyed from the measured period for each block. Thus it is a distribution of dormancy over the period, since block numbers are ascending forward in time.
Hoarding
Bitcoin Days Destroyed can tell us the percent of total coins are trading over any period of time, to the granularity (resolution) of a day. So for example, we can ask what percent of total coins have traded within the past day, or a specific day, week, month, year, or any period in the past.
So it can give us an indication of lower-bound percent of hoarding and duration of hoarding, but it will always understate the actual hoarding and duration, because due the anonymity there is no way to know if a Bitcoin transaction was a transfer to self.
Velocity of Money
Velocity of money is calculated w.r.t. to a measure of total goods and services transacted (e.g. GDP), and due to anonymity there is no way to know in a P2P currency which transactions were for goods and services. Thus Days Destroyed is an upper-bound on the velocity of money, and will always overstate the actual economic activity.

Bitcoin Days destroyed cannot show exactly how many bitcoins are in dormant. An interesting related measurement is called Dormant Bitcoin Chart, which shows the dormancy of all bitcoins.

Bitcoin Days Destroyed (BDD) is a metric used to measure the economic activity and age of coins being spent in the Bitcoin network. It gives more weight to the movement of older coins, as they are considered to be more significant in terms of economic impact.
The concept is based on the idea that spending older coins has a larger impact on the market than spending newer coins, as it might indicate long-term holders are selling or moving their holdings.
To calculate Bitcoin Days Destroyed, you need to consider two factors: the number of bitcoins in a transaction and the age of the coins being spent (i.e., the time since they were last moved). The formula is:
Bitcoin Days Destroyed = (Number of Bitcoins in Transaction) x (Age of Coins in Days)
For example, if someone spends 1 bitcoin that hasn't been moved for 100 days, it would result in 100 Bitcoin Days Destroyed (1 x 100).
By tracking Bitcoin Days Destroyed, analysts can gain insights into the behavior of long-term holders and the potential influence of their actions on the market. A high BDD value may indicate a significant change in sentiment, as it suggests that a larger number of old coins are being spent, which could have an impact on the price and overall market dynamics.
A simpler way of explaining Bitcoin Days Destroyed is a way to measure how important it is when people spend their digital coins called Bitcoin. Imagine you have a toy you haven't played with for a long time. When you finally decide to play with it, it's a big deal because it's been waiting for so long. The same thing happens with Bitcoin: when people spend coins they haven't touched for a long time, it can be a big deal.
So, Bitcoin Days Destroyed counts how many coins are spent and how long they've been waiting to be spent. The longer they've waited, the bigger the deal it is when they're spent. This helps people understand what's happening with Bitcoin and if big changes might be coming.


text:
Has Apple stated its view on legality of apps using alternative electronic payment systems?
An article entitled "Why Apple is Afraid of Bitcoin" discusses Apple's interest in online payments. It also talks about the removal of 2 Bitcoin apps, Blockchain Wallet and BitPak, from the appstore.

The explanation given by Apple was that “apps must comply with all
  legal requirements in any location where they are made available to
  users.” Apple further stated, “it is the developer’s obligation to
  understand and conform to all local laws” and the developer was
  referred to the legal department for an exact explanation of which law
  it violates. Clearly, they will not be able to cite a law as no laws
  prohibiting bitcoin currently exist in any jurisdiction.

Though the author of the article claims that no laws prohibit Bitcoin, Apple obviously disagrees but was very unhelpful in explaining which law it might be referring to. Has Apple discussed its stance regarding legality of apps using Bitcoin or other alternative payment systems?

Linkbait title. I don't think Bitcoin is on Apple's radar, and they are certainly not "afraid" (and the other assertion that Bitcoin support would drive iPhone sales is equally bogus). Either way, Apple will not allow alternative payment systems of any kind, legal or not, for their own (business) reasons.

@Thilo, I agree about the title. However, there must be a cut-off point somewhere relating to the degree-of-alternativeness of each particular app. If they allow say, Paypal, but disallow say, Dwolla, then I'd like to know the reasoning.

They don't really allow even PayPal. There is a PayPal app to manage your own account (and major banks have similar apps), but the much more interesting PayPal API, which other apps could use to handle donations or in-app-purchases are still forbidden. Why don't they kick out PayPal and those banks altogether? Because they are big. If they weren't Apple would probably throw them out. (Maybe they still will if Apple really gets into payments in a big way). Don't think they care about providing "reasoning". You certainly don't have to be "illegal" to not get in the store.

As I read here Google does not allow 3th party merchanting services:
https://stackoverflow.com/questions/10217727/apple-android-3rd-party-merchant-services
I'm quite sure that Apple wouldn't allow them either.
Although, by law, Bitcoin is not considered as a payment, since law does not recognize Bitcoin as a currency.
So by the rules i don't think they can ban you for using Bitcoin, but as we all know, Apple just decides itself what it allows and what not.


text:
What are the obstacles to pegging the value of bitcoin to an established stable currency?
Many people will not touch bitcoin due to it's historically extreme volatility. Many new currencies have pegged their value against an established currency until such time as it is sufficiently established to be decoupled.
For example the Irish punt was linked to the Sterling pound until they joined the European Monetary Union in 1979.
Would it be possible perhaps by way of a financial service organisation that guarantees a value against a stable currency such as the swiss franc for example, this using bitcoin as a form of promisory note?
Is the agreement of a fixed rate against an established currency like type of future or option in the stock market?
I think this could help speed adoption.

This is possibly a related question: http://bitcoin.stackexchange.com/q/256/136

$21m is pittance compared to the amounts bandied about in the debit crisis, and well within the capacity of many rich individuals around the world.

related: Will the price of Bitcoin ever be stable with the USD?

You could fix the minimal value of Bitcoin if you had some money and you wouldstate: "I have X$, I will buy each and every Bitcoin you offer me at the rate of X/2100000$". The only problem is that people need to trust you and you have to have enough money. So, if you get en established company (for example, Google) to secure the funds you can fix the minimum price of Bitcoins at any arbitrary rate.
Fixing the maximum price, however, is impossible, as you can't generate Bitcoins at a whim to sell to anyone offering you money. As with anything with limited supply, the sky is the limit.

I think a fractional reserve would be possible :-P

@barrymac the problem with fractional reserves is that they can only inspire fractional confidence. In other words, if I guarantee that I'll buy bitcoins for $1 each but I only have enough money to cover 10% of the total bitcoins in existence, there is still a chance my reserve could be bought out and allow sub-$1 prices. Anything shy of 100% backing can inspire some confidence, but in my opinion at least, not enough.

@barrymac - well, if you would have enough people doing fractional reserve, eventually you would back up the coins in 100%. Then again, the more people that claim they will buy Bitcoins for X$ per coin, the higher each coin is worth. You can establish some network of trusted entities that would pool their resources and thus establish a higher minimal value of Bitcoins (for example, having X$ and Y$ from two people, each coin would be worth (X+Y)$/21M).

@David Perry I take it you don't trust your bank very much then either! I can understand that, especially given recent events

The only way to fix an exchange rate is to constantly trade at this rate. This requires unlimited funds.
So assume you want to peg BTC against CHF as in your example. For simplicity, we aim at 1 BTC == 1 CHF. Here's a simple recipe.

Have unlimited Bitcoin and unlimited CHF.
Find a Bitcoin exchange.
Offer to buy an unlimited amount of Bitcoin for 1 CHF/BTC.
Offer to sell an unlimited amount of Bitcoin for 1 CHF/BTC.
Observe how everyone will accept 1 BTC/CHF as the official rate.
If you run out of Bitcoin or CHFs, give up.

Unlike any other fiat currency, bitcoin money supply could not be manipulated, therefore it's not possible to fix its value in any way but good old buy and sell orders which would require a very heavy investments.

It's probably possible to calculate how much capital that would require as a function of the current market volume. Any ideas?

Take a look at "Bot to operate a price bloc to stabilize price of BitCoins" - https://bitcointalk.org/index.php?topic=39792.0

@barrymac look at BTC Watch in the top left corner you'll see "Total BTC" - multiply that number by the price you'd like to guarantee (we'll call it n) BTC does not dip below and that's how much money you need. 7200 new coins are mined per day so add 7200n dollars per day for a number of days to ensure they stay backed for the foreseeable future.

...or at least, that's an upper limit on how much money you would need.  In practice you share the "load" of guaranteeing the bitcoin with any other people willing to value the bitcoin at this level, and repeatedly blocking any dips with massive, massive buys will tend to make the market at large pretty confident about that bottom.

The discussion about using a price bloc bot network is very  interesting!

I think that trying to tie the value to some arbitrary standard is artificial - for one thing, the value may depart substantially from that other standard and needs to be allowed to vary in order to stablize at an authentic (ie reflecting supply/demand etc) rate.
However, reducing extreme volatility would indeed make BTC more appealing as a medium of exchange or investment.  The extreme volatility seen in June was due to illiquidity of the bitcoin market in the face of a sudden increase in demand.   It's just like a 'penny stock', where few shares are traded and there is no market-maker or institutional investor.
Picture a cup of ice cubes, vs the same volume of water.  If you add or remove the same amount of water, the level in the ice-cube cup will jump in increments, vs the level of liquid water varying smoothly.
Liquidity of the BTC market would improve if many traders were always present to make small transactions on mtgox, and if several institutions or big investors would step in to 'make a market' in bitcoins.  Making a market would require holding a BTC reserve large enough to satisfy most requests to buy OR sell BTC in a current day.  Examining bitcoincharts.com, we see this would mean holding about 250K BTC each.   The market maker(s) simply post active Bids and Asks slightly wider than the spread, so they are always making some profit just buying and selling.
It would also help if the bitcoin exchanges consolidated to one, or what will happen is someone will build arbitrage bots which exploit 'flipped markets' - eg situations where a bid on one exchange is higher than ask on another exchange.
Thirdly, it would help if a venture fund existed to invest in businesses which accept BTC payments or build BTC technology... people would then invest in that fund and act to protect their interests in BTC succeeding.  I am working towards creating such a fund but can't talk about it yet.

The larger issues isn't can it be done it is why would anyone do it.
Central banks buy and sell opposing currencies to keep the value pegged.  Generally speaking they lose a ton of money doing this however it provides a public good and being a central bank they can simply create or destroy sufficient money to accomplish the goal.  Any losses the central bank accrues or gains are simply felt by overall economy via inflationary and deflationary pressures.
There is no central bank thus any entity which tried to do this would be facing significant and continual real losses for no benefit.  Sure the entire Bitcoin economy benefits but that isn't something that can be monetized by the entity taking the risk/losses.
The only situations that even seems possible is some benefactor who willingly suffers massive and continual market losses to provide a narrow trading range for Bitcoin and that isn't very likely.

" Generally speaking they lose a ton of money doing this however it provides a public good" -  I don't think it can be stated as a fact that it's a public good. A public good is defined as one that can only be provided by collective action. Reducing risk from price volatility can be achieved by individual market participants through the use of options and futures contracts.

Indeed the massive and continually growing currency reserves that governments of many large economies is seen by some leading economics as a failure of modern money systems! For example the way china supports the dollar, fed prints dollars, china buys them to keep it's exports strong. crazy.

The easiest way to immediately see why this would be extremely difficult, if not impossible, is to imagine this: Suppose you decided that the price of an ounce of gold today in dollars (or relative to a bundle of goods, or whatever) was the perfect price for gold. What could you do to keep it stable?

The main "obstacle" for this idea is that few people would like it. The central advantage of Bitcoin is that it has no central point of failure - or at least not single organization that is liable for it.  With a peg, there is necessarily an organization that is liable to maintain the peg - they have to keep their promise.
So if Bitcoin were pegged in such a way, it would be no better than prior digital currencies like Beenz or egold.

Instead of pegging the currency use futures or options to cover a potential drop in value (hedging). A well trodden path. As everyone expects bitcoins to go up over time and it is quite volatile would make the cost of hedging low. It would be interesting if a website provided this service on easy to understand terms.

Is this an answer to the question?

Bitcoin value is based entirely on speculation, specifically on the expectation that its price in an established currency will rise indefinitely. The instant that it has its price in an established currency fixed, or that concrete items are priced in Bitcoin, that expectation is destroyed. So it's hard to imagine where the support for this would come from, unless it is sought as kind of bailout for holders who are concerned that they face losses without it.
Think of Bitcoin as shares of stock in nothing (or perhaps, shares in a virtual utopian libertarian project). As long as those shares, for whatever reason, are expected to increase in price as denominated in actual currencies, people will buy Bitcoin using those currencies. Pegging the price of those shares is like suddenly converting those shares into shares in an actual company: it is now clear what they are actually worth. That's not something that would be appealing to many holders of Bitcoin.
But more importantly, what would the mechanism be? Who would guarantee and enforce the peg? If a government were to do it, it would essentially amount to a bailout of Bitcoin holders, since the actual value of Bitcoin is zero, money would have to be transferred from the real economy or printed to do that, or taxes would have to be levied. The irony of that might be lost on Bitcoin holders, but not on citizens or central bankers, with whom the idea is also not likely to be popular.


text:
Can I damage my computer by mining bitcoin?
I have been mining Bitcoin for a while on a few systems, some CPU mining (which has proved to be basically useless) and some GPU mining. The GPU miners are workstations, which have midrange graphics cards built in. I have not done any modifications or built high-end mining/gaming systems. One is an Apple iMac with an AMD Radeon HD 6770M 512 MB built in. I typically mine with the Phoenix miner and AGGRESSION=3 for at least 12 hours a day.
Can the GPU handle this load, or is it possible I will damage my computer by mining bitcoins without a dedicated high-end GPU?

It is possible to damage your computer by mining in the following ways:

the computer will degrade more, as it is used more (you will have to replace it sooner than normally)
the computer will overheat and some components will fail because of that (if for example, the computer is dusty. If the parts are well-maintained and the computer is not boxed in, this shouldn't be the issue)
you will overload some part of your computer with the mining and it will short circuit or blow a fuse (mostly relevant if your power supply is weak, this happened to me once)

Number 3 you should notice quite fast if you run your miner at top speed, full load. If you are already mining, this probably won't happen unless you increase your load, or are operating close to the limit of your hardware. If something flashes, smokes, or the computer doesn't turn on any more, this was probably the cause. Replace hardware.
Number 2 you should notice if you run your miner for about an hour, once everything heats up well. Again, if you are already mining and this doesn't happen, it probably won't if you keep your computer clean and give it some air. If your computer turns off suddenly, but runs fine after cooling down, this probably was the cause. Clean your computer chassis, possibly add some fans or replace hardware.
Number 1 you won't notice for months or years.
Mining with lower-end GPU should be fine in all the regards, asides maybe 1 (leaving your computer on for longer to mine will ear it down more). Usually it means you won't use as much power and generate as much heat, so you should be fine.

It is heat that kills.
You need sufficient airflow and good case design to keep the GPU and VRM (voltage regulators) cool.  Most commercial workstations have insufficent airflow.  Likely it has one or two small intake and one small outtake fans.  Sufficient airflow generally requires much larger fans and more open case design.  Things like cases which mount powersupply upside down (so it exausts hot air outside the case), large diameter case fan mounts, and side panel cooling is especially useful in getting enough cool air into the case and hot air out of it.  "Reference" card designs (more below) also help with proper airflow.
You need a utility to monnitor your temps.  Be sure to use a utility like "GPU-Z" which provides VRM temps.  The VRM control voltage supply to GPU and memory and under load get very hot.  With insufficient cooling they can exceed 100C which reuduce their lifespan.
You need to also check the other temps in your case.  While you aren't stressing the CPU and motherboard if the case design isn't properly exuasting the hot air outside the case the ambient temp around CPU and motherboard will rise making cooling less efficient and could lead to damage to those components.  CPU are far more suspetible to instability at high temp than a GPU.  While 90C can be considered a high temp for GPU a CPU temp should generally be kept below 70C for long term stability.
Unrelated to heat an poorly built powersupply may be insufficient to handle the high 24/7 load but any premature failure is more a manufacturing defect (promising more than it can deliver) than an issue with mining.  Some lower quality manufacturers bet on the fact that most computers aren't run at 100% load 24/7 and users buy larger powersupplies than needed and use that to cut corners.  Mining can be brutal on a powersupply.  It will be pushed ot high % of it's peak power and the load will be continual with no breaks.  Cheaper built powersupplies just can't handle that abuse.  Stick to major brands with good reviews and solid warranties.
About AMD "reference designs":
These cards are usually the first design released by AMD and are designed to handle high load with multiple cards in a single case.  They tend to be more expensive to build so card companies are always look for ways to cut cost as more users with single card don't need that level of overengineering.  The reference design is visually very easy to identify as it will have a single squirrel cage fan near the interior end of the card, a closed heat shroud, and a vent which exhausts hot air outside the case.

(source: bestofmicro.com)

Thanks! Also, Just an FYI, you're not the only unhandled exception in town :-)

Yeah but does he have a flying toaster?  I rest my case.

Nope. He has a collection of crowdsourced gravatars :-)

"Its the heat that kills" ...... I wrote that my wall

Controlling the computer's temperature is really important. Excessive heat may cause hardware damage and constant crashes. High end cards tend to consume more power and produce more heat, but any system can overheat if not properly ventilated. iMac's are known for their terrible airflow and there are reports of people running into problems by mining on them.
You should install a program to control your fan's speed and monitor your GPU temperature. The miner software also has configurable parameters to reduce the GPU load. In your case, consult the Phoenix thread and choose the appropriate aggression level (try a few different values and check the temperatures/hash rate).

That's very helpful; thanks! It frightens me to read reports of iMac dying like that, yet I have been mining for months with no problems. I suppose that's because I keep the aggression so low like you said.

If you are concerned some miners also give you the option to idle the card periodically (i.e. 10ms per second). This can significantly reduce heat load.  Each 10ms of idling reduces the hash rate by rougly 1% but can be effective in controlling internal temperature.

For people reading through this in 2017+:
Times have changed and a lot of higher end cards are now far more power efficient. I'm mining ethereum with a 1070 FTW card and I get a solid hashrate around 25-26 Mh/S and my temperatures never break 65 degrees (C) even with an 100 Mhz memory overclock and 75Mhz GPU overclock.
As is common knowledge these days, leaving a computer on doesn't necessarily damage your computer, in fact frequently turning off/on your computer actually causes slight physical damage to your machine every instance. The most accurate thing in this thread is that it's true: heat is what kills hardware.
If you treat your hardware well, it's going to last a while. This is why people's laptops generally die out from a variety of costs in a few years - they're made poorly: the airflow is generally bad, the hardware is pushed to its limits in simple repetitive tasks (I'm looking at you, Netflix!) like power-up etc.
I've left my computer on for days on end and have not experienced any problems. It's important to monitor your hardware's temperature while mining, especially taking into consideration things like voltage, fan speeds, and usage statistics for CPU/Memory/GPU. If you can reduce stress on the systems that are working the hardest, you can increase your runway.

But having laptop switched on for longer periods wll have adverse effect on the battery, you would be recharging much sooner, the battery would deteriorate in a year or so.