text:
How do I calculate the value of some amount of bitcoins in my native currency?
If I know the exchange rate, how can I calculate the value of some amount bitcoins in my native currency?

I didn't know this was the grade school math SE

@DaveC There's no need to be rude to him.

Dave, i just wasnt sure and i dont know why i got negatives for this, it was an honest question.

While it is baffling to me that someone would have to ask about that, it's just been asked again (for the n-th time), so I am proposing to create a lightning rod question here.

{Bitcoin Amount} * {Exchange Rate} would give you the value of BTC in USD.  You'd have to add transaction costs to that, which depend on your exchange.

Sure it would. lol ;-) I think this answer is a bit old. Answer is simply {BTC AMOUNT} * {Your exchange rate} (Without using static amounts.)

Well yes.  Since I wrote the answer the question was changed (18 months later) to remove the values that were in the original question and to which my answer referred.

I will explain how to calculate the value of some amount of bitcoins in terms of USD, but obviously the USD can be replaced by any other currency, and the corresponding exchange rate.
There are three figures involved in this calculation:

The value in USD.
The exchange rate, which gives you the relation of USD to BTC.
The amount of bitcoins.

If you look at the units of the figures, you can figure out the following formula:
value in USD = exchange rate * amount of bitcoins
Or expressed in the units of the terms:
[USD] = [USD/BTC] * [BTC]
As you can see, if you multiply the exchange rate [USD/BTC] with the amount of bitcoins [BTC], the units of the right side will be reduced to [USD], which is what we are looking for.
Example:
We have 0.005 BTC and the exchange rate is 200 USD/BTC.
exchange rate * amount of bitcoins = 200 USD/BTC * 0.005 BTC = 200 USD * 0.005 = 1 USD
You can also turn the equation around to calculate any of the other terms:
To calculate the exchange rate, you take the amount of USD you paid, and divide by the amount of bitcoins you received.
exchange rate = 'value in USD' / 'number of bitcoins'
To calculate the number of bitcoins you might buy with a given amount of USD at a specific exchange rate, you divide the amount of USD by the exchange rate:
number of bitcoins = 'value in USD' / 'exchange rate'

Let Preev help do the math for you!

Calculating the price of Bitcoin based on the Bitcoin/USD exchange rate will probably not give you the exact actual cost of Bitcoin in your native currency. The price in your native currency is set by the supply and demand on a local exchange that deals in your own currency. This can vary by as much as 10-30% e.g. South Africa & South Korea at times.
So, you ask, would that mean there is a difference in value between Btc/USD, Btc/Native and USD/Native? Yes, that is what arbitrage is based on and many take advantage of the difference to make a profit wherever Btc is valued higher. So bottomline, if you're looking for exact exchange rate look on a local exchange.

Let exchange rate = a;
Amount in BTC = b;
Amount in your native currency e.g Naira = a*b.
For instance:
You are given exchange rate to be BTC/NGN = 380 and you have 0.00548 BTC,
The Naira value will be 380 * 0.00548 = 2.0824NGN.thanks

{BTC AMOUNT} * {Your exchange rate}
Further: Google/Searching would have been the proper place to get this answer.
(Hint: "currency conversion math" as some keywords.)

Just multiply both. Because 1 BTC (Bitcoin) = 50000 (Not now), and you have 0.04, (you have 0.04 of Bitcoin) 0.04 x 50000 = Your Ans.


text:
Is bitcoin-gold more ASIC-resistant than Litecoin?
Bitcoin Gold's main point for existence has claimed to be ASIC-resistant in order to have mining power more distributed.
But wasn't this tried already with Litecoin via Scrypt mining algorithm? I've heard there are already Scrypt-capable ASICs, so is Bitcoin Gold now a better alternative?
What's Bitcoin Gold algorithm? Can it become minable by ASICs at some point too? Could Litecoin switch to this algorithm to be ASIC resistant again?

This appears to be old but to correct the above answer, Bitcoin Gold used to use the Equihash algorithm but recently forked to the Equihash-BTG proof of work algorithm in order to keep in line with the protocol's main objective, ASIC resistance.
As for which protocol is better? I suppose for some that is a matter of opinion but if you ask me (and the majority of the ecosystem as evidenced by the price), LTC has it all over BTG in terms of developer interest, liquidity/volume, price, propagation, potential use cases, etc.
The GPU-mining ship sailed long ago for LTC.

To answer some questions to the best of my ability:
But wasn't this tried already with Litecoin via Scrypt mining algorithm?
Yes, this was tried with Litecoin.
is Bitcoin Gold now a better alternative?
This is a matter of opinion.
What's Bitcoin Gold algorithm?
They forked to the Equihash-BTG algorithm.
Can it become minable by ASICs at some point too?
Yes, every algorithm can be mined by ASICs, but some algorithms are more expensive to produce specialized hardware for, than others.
Could Litecoin switch to this algorithm to be ASIC resistant again?
Yes, Litecoin can switch algorithm if there is consensus to do so. Whether or whether not Litecoin would become ASIC resistant, is a matter of opinion, as ASIC resistance is a very debatable topic about whether it is possible or not.

I just started reading The Definitive Guide to Gold, a free 65-page ebook that talks about how gold is an important part of financial success. It’s pretty interesting to see how technology is changing the gold industry.

this question was about bitcoin-gold, not gold

(downvoting because it also smells as spam)

source: Stack Exchange

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

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

sort: votes


text:
Sending and Receiving Mechanics
I'm new to Bitcoin and am considering allowing people to pay for my software with them. Before I continue I would like to clarify some things. My googling did not get me the answers I was after.
I understand that you can create new addresses for each transaction. Say I have 1BTC paid to A and 1BTC paid to B.
On the overview tab of the default Bitcoin client, the balance would be displayed as 2BTC. I can only assume it has simply added up all the amounts in A and B address?
But when I send 2BTC to address C, does it create a new 'sending address' X and move to amounts from A and B to X and then send to C or send two transactions, one from each account A and B?

There really aren't "sending addresses" in Bitcoin. The client creates a transaction that gathers all the inputs and sends them as an output.

The coin selection that the client does is performed behind the scenes, the client takes care of the details.
But if you are curious to know what happens behind the scenes:
INPUT:

Address: A  1.0 BTC
Address: B  1.0 BTC

OUTPUT:

Address: C  2.0 BTC

FEE (derived as inputs - outputs): 0.0 BTC
This is assuming you didn't pay a fee.

Let's say instead you only were to pay 1.5 BTC, and a 0.0005 BTC Fee.
INPUT:

Address: A  1.0 BTC
Address: B  1.0 BTC

OUTPUT:

Address: C  1.5 BTC
Address: D  0.4995 BTC

FEE (derived as inputs - outputs): 0.0005 BTC
Address D was an address from your own wallet that the client chose to receive the change transaction.  Your balance in your wallet will then show 0.49995 BTC.

Here's a technical explanation:

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

A Bitcoin transaction can have multiple inputs (and multiple outputs). In the scenario you described, a single transaction will be created, which will include as inputs both the payment to A and the payment to B.
Usually, the receiving party will not care what are the inputs of a transaction, he will care that the output will include the expected payment to his own address.

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


text:
Protocols for use between mining clients and mining pool servers
Which protocols are there for mining clients to communicate with mining pool servers? How do they compare?

Stratum: the server gives the client templates that the client can use to generate its own work. Only the block header and first transaction (generation transaction) are included. Stratum uses the least bandwidth of all the protocols. Stratum also makes it very fast and efficient to switch to new work data when there is a block change, which can help keep down the reject ratio caused by stale work. Unlike the other protocols it is not HTTP, so it won't work over an HTTP proxy. There is no real specification. There is a document that explains the core features and for the rest you have to read the source code for "stratum mining proxy" and/or old posts on bitcointalk.org.
GBT (getblocktemplate): the server gives the client templates that the client can use to generate its own work. The client is given full block data and (if supported by server and client) this allows the client to modify the block. For instance the miner could choose which transactions to include in a block. Because of these features GBT needs to transfer more data than Stratum, so bandwidth usage is higher. These features are not supported anywhere yet, as far as I know. GBT is well documented through detailed specs.
Plain getwork: the way mining was done originally. The server gives the client a block header without any transactions or any way to modify the block except for the nonce value. The client is limited to trying all possible nonce values and will then need to request more work from the server. This causes massive bandwidth usage for modern mining hardware. Like Stratum it doesn't give the miner any control over what is mined. You get the worst of both worlds.
getwork with rollntime extension: allows the client a limited way to generate work by modifying the timestamp on the block header. If you process 10 nonce ranges per second (42.9 Ghps) you'd want to request 10 block headers from the server. As each second passes you update the timestamp on those block headers, allowing you to reuse the same work for the next second. Bandwidth usage goes up with hashrate. 429 Ghps would require 100 small request-response exchanges with the server to get enough work after every block change. Compare with GBT where bandwidth usage goes up with the size of the transactions (one big request-response exchange per block change). Which uses less bandwidth depends on your hashrate (getwork) and the size of the block you are hashing (GBT).
TL;DR: getwork is the old way. The rollntime extension gave it back some life, but it won't scale as mining devices get faster. There are two new protocols to improve mining: Stratum which focuses on low bandwidth usage and GBT which focuses on allowing the miner to control what goes in a block.

There's two major protocols, getwork and Stratum. There's a very good comparison on the Stratum introduction page. Some miners can also use Get Block Template (GBT), which allows them to both pool mine and to choose their own transaction content. Not many pools support this, choosing to only offer Stratum instead.


text:
How will a massive increase in hashpower affect orphan rates?
Difficulty always lags behind a little. It is also limited in how large adjustments it makes each time. What if the (global) hashrate doubles overnight? What if it quadruples?
How much can we expect the orphan rate to go up? By orphans I mean blocks on a block chain fork other than the main chain (longest chain).
How large would the losses then be for PPS pools and other pools that pay for orphaned work, before the difficulty catches up?
What about a solo miner? What about P2pool? In both cases many of the miners may not be well connected to other block generating nodes on the bitcoin peer-to-peer network.
Perhaps there is useful information available from alt coins that have gone through something similar or just have a higher rate of block generation.
The question is of course motivated by the imminent shipment of ASIC-based mining equipment with hashpower that will dwarf anything seen so far. If you do an estimate, feel free to use any numbers you feel are realistic. I have no idea what amount of ASICs are currently going into production. The question could also apply to next generation ASICs, quantum computing or weaknesses that may be found in the SHA-256 hashing algorithm.

If the average time to find a block is T, and the typical time for a found block to propagate in the network is t, then the proportion of orphans among all blocks will be roughly 1/(1+T/t). As long as T>t there's not much risk for the network; however it could be a challenge for orphan-paying pools, for example If T=9t then 10% of the block rewards will need to be paid out of pocket.
If a PPS pool pays B/D per share, it is in fact using an artificially low difficulty - the difficulty metric measures how hard it is to find a block (orphan or not), when in fact what is relevant for calculating the due reward is how difficult it is to find a valid block.
If the network hashrate increases by a factor of X, then until difficulty catches up the average time for finding a block is (10 min)/X. I doubt the transition to ASIC will cause a discrepancy by a factor of over 10; this would give T = 1 min. With a conservative value of t=5 sec you will get about 7.7% loss for paying orphans. The actual numbers for both X and t will likely be much less (especially since concentrated hashrate lowers t), so I don't think the loss during the transition period will be prohibitive.

What if the (global) hashrate doubles overnight?

Then blocks take five minutes instead of ten.  And continues to do so over the next days until the difficulty adjusts, and then it is right back to one block every ten minutes.

What if it quadruples?

Then blocks take two and a half minutes instead of ten.  And continues to do so over the next few days until the difficulty adjusts, and then it is right back to one block every ten minutes.
Now I see where you are going with this.  Let's say it goes up an order of magnitude (10X). Well, blocks will fly by about once a minute and in less than 48 hours difficulty will readjust but it the algorithm tops out at a maximum 4X increase per adjustment period.  So the resulting blocks after the adjustment will be solved at about once every four minutes -- until less than a week later when the next adjustment period takes it back to once every ten minutes.
i.e., This isn't a problem that the Bitcoin network can't handle.
There will of course be a few more orphans, but they won't generally be extended very far.  Orphans already happen regularly with a decentralized architecture like Bitcoin.  And other than the miner or pool who was prematurely celebrating, orphaned blocks don't pose a problem.  Merchants accepting on 0/unconfirmed or even less than two confirmations might want to be more vigilant when ASICs first start hitting, but there aren't very many merchants who do accept on unconfirmed transactions today.


text:
Faking blockchain data in bitcoin-core
Let's say I found a tarball with blockchain data files which I load to my datadir and start my Bitcoin Core client, what sort of attacks am I vulnerable to? Could the files contain fake balances? If yes, what will happen if another peer requests a block which has altered data in it, how will that other peer handle this situation?

Let's say I found a tarball with blockchain data files which I load to my datadir and start my Bitcoin Core client, what sort of attacks am I vulnerable to? Could the files contain fake balances?

It depends. If you're just importing blocks (so no chainstate/ subdirectory with UTXO set), there should not be any possible attack. The client will validate those blocks at startup time, just as if they were being received from the network, to rebuild the chainstate. If one of the blocks was modified, it would be rejected as an invalid block at this time, and the correct blocks would be requested from the network instead.
However, if you accept a chainstate from someone, anything is possible. They can convince you they have unlimited amounts of money, or convince you they have paid you in the past. For any future transactions relying on such faked funds, getting to confirm them would require cooperation from a miner that is willing to build an invalid chain to defraud you (or others, in case many people used that chainstate "backup").

If yes, what will happen if another peer requests a block which has altered data in it, how will that other peer handle this situation?

Blocks can't be altered without invalidating them, so other peers downloading blocks from you can't be affected. Similarly, a -reindex would fix any problems for yourself as well.


text:
Do HTLC transactions work today or do they need a new soft-fork?
I thought that HTLCs were just a kind of a script construct that would allow to unlock funds for a period of time, which can be unlocked to anyone that provides the original string that matches the hash. Does it need new opcodes that are not working in Bitcoin yet?
I ask this because I can see the BIP where this is proposed, linked from here: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-July/012894.html . However, neither the pull request nor the BIP inclusion seem to have had any activity.
Does this BIP need a soft-fork that hasn't been implemented/deployed yet?

Both hash locks and time locks exist in bitcoin today.
It looks like the BIP in question relates to wallet support and HTLC transaction structure, rather than changes to bitcoin's opcodes.

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


text:
What is the rationale behind Bitcoin mining?
I don't understand the logic of "mining", if bitcoins are a digital currency, why do we need a GPU to "make 'em"?

Similar question: What exactly is Mining?

Why do we mine?
We need to all agree on who owns which coins.  If your idea of who owns what is different than mine then how can we trade?
To achieve this, the Bitcoin protocol keeps its ledger of all transactions in a series of blocks, with each block recording a collection of transactions.  Since we don't have a central authority to declare which blocks are valid, we run a 'lottery' instead.
Each miner bundles up all the new transactions he knows about, adds in an extra transaction which creates some coins out of thin air and pays them to the miner, mixes in a random number and hashes the whole thing.  If he gets a hash less than a certain number, he wins and his block is added to the blockchain.  If not, he tries with a different random number, over and over.  Everyone else can verify that his random number with his transactions hashes to a low enough number, so they accept his block.  The network periodically adjusts what this target "low enough number" is, in an attempt to keep the average speed of block generation at about 10 minutes.
Why do we need a GPU, not a CPU?
You generate coins by calculating hashes.  Each hash you calculate has a certain chance of making a block, and earning the associated reward, which is currently 50 coins.  The faster you can calculate hashes, the more chance you have of generating 50 coins.  It just so happens that ATI GPUs have the right kind of hardware in them to calculate sha256 hashes many times faster than an Intel CPU can do it.  That's why people use GPUs instead of CPUs.
The Bitcoin network automatically adjusts the "chance per hash" to try to keep the global rate of generation at one block every ten minutes.
In the beginning, before GPU mining started in earnest and not many people were mining, CPU mining worked just fine.  But as more people joined the network and hash rates became faster, the network difficulty increased to keep the blocks coming along every 10 minutes or so.  As a result, CPU mining became less rewarding per CPU.
Then when it became more common for miners to use GPU hardware to mine because it is so much faster and more energy efficient than CPU mining, the global network hash rate increased still further eventually making it completely useless to mine with a CPU; the expected rewards are less than the power consumed by the CPU.
Maybe one day FPGAs or ASICs will render GPUs useless for mining, like GPUs already did to CPUs.

I'd avoid phrases like "before GPU mining had even been thought of". In all likelihood, it was clear that GPUs would be better for the task even before the genesis block was generated. Contrary to popular belief, Bitcoin didn't invent GPGPU.

Thanks for this explanation, but could you also tell us why the hash needs to be less than a certain number?

"network difficulty increases to keep the blocks coming along every 10 minutes or so".  If there wasn't some kind of criterion to decide which blocks are valid there would be thousands of blocks made per second.  The "less than x" is to make it hard enough to find a block that on average they are found only once every 10 minutes.

@WillSheppard This sentence in the answer should answer that for you: 'The network periodically adjusts what this target "low enough number" is, in an attempt to keep the average speed of block generation at about 10 minutes.'  It's just an arbitrary way of making it 'just hard enough' to find a block.

"Maybe one day FPGAs or ASICs will render GPUs useless for mining" - and the day has come.

Bitcoin blocks have been deliberately made difficult to mine. The point is:

To prevent the network to be flooded with a ton of  valid blocks that have to be checked for validity and stored. (The difficulty to mine them is dynamically adjusted so that in average, worldwide, one block is generated every 10 minutes.)
Also, this gives time for newly created blocks to spread across the network. Typical millisecond latencies can then be ignored. If latencies were not negligible, the mining 'game' would be unfair to poorly connected miners.

And to finish answering your question, the purpose of mining is not to distribute coins, but to collectively build a reference transaction history. Coin distribution is just a reward to those who participate. Please refer to How does the mining process support the currency?

It wasnt made deliberatelydifficult. Its difficulty is a result of the size of the network to keep it proportional.

Stop the nonsense please.

And (maybe most importantly) 3: To make it impossible for any one party to create a majority of blocks. With hash mining, you can only expect to get a number of blocks representing your fraction of computing power across the whole network. That way the block chain ends up with a transaction ordering that the whole network agrees on, and sustaining a network fork over a long time becomes practically impossible.

And maybe 4: Since hashing is so difficult that block generation is spread "evenly" across miners, this process can be used to generate new coins (mining) and distribute them across all invested participants (as opposed to having started with 21 million coins up-front sitting all in Satoshi's wallet).

The logic behind mining Bitcoins is similar to the one behind all the security features used in all currencies - to prevent people from counterfeiting them.
Traditional money uses special fabric, paint, serial numbers and highly detailed design patterns to prevent people from making their own copies and thus flooding the market. If you'd get rid of all that, anyone could write down "10$" on a piece of paper and use it as currency.
With Bitcoin, the problem is a bit harder - as there is no central authority, mining was chosen to be the way for money to be created and transferred. The cryptographic problem that is being solved with each new block is a proof that someone went through the effort of mining that particular block. The process of legitimately creating Bitcoin takes both time and computing power and counterfeiting Bitcoin takes roughly the same amount of work, encouraging people to be fair.
Without mining we would either need a central authority to manage the amount of created Bitcoins and how they are transferred (which defeats the purpose of a decentralised cryptocurrency), or we would be stuck with worthless bits that anyone could make in any amount.

Bitcoin cleverly combines two functions via mining:

Ensuring an "equitable" distribution of currency during the (current) generation phase of the Bitcoin economy.
Providing a secure distributed time-stamping function to provide a trusted ordering of all Bitcoin transactions.

The creator of Bitcoins realized that there would have to be some way to get Bitcoins into circulation.  Since it is decentralized, he did not want to issue coins from a central authority.  So, he enticed others to "mine" for Bitcoins by exchanging computation power for Bitcoins.  The mining process is quite similar to a lottery, where you buy "tickets" by computing hashes; the more hashes you compute, the more likely you are to win 50 Bitcoins.
This scheme has the economic benefit that value is not created out of thin air - Bitcoin miners have to trade one valuable resource (their computing time and energy), in exchange for another (Bitcoins).  This helps establish a correlation between a "real world" value, and the value of a Bitcoin.
It just so happens that mining also is used to establish a well defined ordering of Bitcoin transactions; so we kill two birds with one stone, and provide incentives for people to contribute resources to keep the Bitcoin network operating.

The genius of mining and the block reward is that it provides an incentive for people to provide enough proof of work to keep Bitcoin payments secure before transaction fees will be valuable enough to do it on their own. Otherwise, someone would have had to bankroll the Bitcoin system or it would have been insecure.

Bitcoin mining is the process of adding transaction records to Bitcoin's public ledger of past transactions or blockchain. This ledger of past transactions is called the block chain as it is a chain of blocks.
Bitcoin mining is intentionally designed to be resource-intensive and difficult so that the number of blocks found each day by miners remains steady. Individual blocks must contain a proof of work to be considered valid. This proof of work is verified by other Bitcoin nodes each time they receive a block. Bitcoin uses the hashcash proof-of-work function.
The primary purpose of mining is to allow Bitcoin nodes to reach a secure, tamper-resistant consensus. Mining is also the mechanism used to introduce Bitcoins into the system: Miners are paid any transaction fees as well as a "subsidy" of newly created coins.
Miners do expensive computation to solve puzzle and they broadcast it over the network. It contains a number called nonce which can be used to easily verify that actual work was done. This is called proof of work. The solution takes lot of trials and is computationally difficult but it can be easily verified by other nodes on network. Any evesdropper, if tries to alter any block or transactions, will need to do alter all following blocks in blockchain that will get exponentially difficult. Thus it makes alterations in block impossible and a secure and tamper resistant ledger is created on blockchain.

The term "money doesnt grow on trees" springs to mind. Ask yourself these questions for now.

Where do we distribute wealth?
What gives it value?
How can we stop people making forgeries?

All these problems can be resolved by requiring complex computational algorithms that require you (or your hardware as the case may be) to work out.
Using cryptography we can use a distributed system, give it rarity due to the supply at which they can be created and highly improbable for someone to make a forgery (or double spend a transaction in this case).
These are only a few of the possible scenarios which rely on cryptography to solve problems with Bitcoin.

Thanks for your answer.
I think i need more time to process this, but im loving this project.

This answer is definitely misleading and unaware of the workings of bitcoin.

It was ment as a high level concept. Judging by the question it was not looking for an ovely technical answer on the working of the network.


text:
Why are coin miners (such as GUIMiner) a "threat" in Windows Defender?
I opened up my GUIMiner and I got a rather unfriendly "Win32/CoinMiner" threat of "Medium."
I installed this program knowingly, so should I be concerned? Is this just a problem because people have been installing miners on people's machine unknowingly (which would be a bad thing)?

people have been installing miners on people's machine unknowingly (which would be a bad thing)? - Correct.


text:
How to save bitcoins as paper?
I would like to save some of my bitcoins on a piece of paper with QR code printed on it. What would be the easiest way to do it without using Mt Gox. or similar. Just bitcoins (I'm not afraid of some programming if it's needed).

Currently the most popular method is to use something like pywallet to export your public/private keys and simply generate a text QR code for them. Typically separate QR codes are generated for the public key and private key so that one code may be used to receive payment without giving away the private key which allows spending from the account. There are some alternatives, however, depending on your paper wallet needs.
Casascius' Bitcoin Address Tool is an excellent way of saving bitcoins in an easy to recover format. Though it doesn't yet support QR codes it does have the ability to generate a paper wallet from any passphrase. Once generated you could store the public and private keys as QR codes using any of a number of applications or online generators. Additionally, you could store the passphrase in a QR code and use it to recover your addresses at any time.
I specifically suggest this as opposed to simply exporting keys with pywallet and QR-ing them because this method would let you store more than one wallet address using a single QR code since any passphrase can generate up to 999 addresses deterministically in such a manner. Of course having a simple public key in QR code form also lets you scan the address with a smartphone or computer to send coins, so ultimately the solution depends on your usage.

The short version of the underlying mechanism is this: You generate a random string of characters. You use the hash of those characters as the private key. You send the coins to the corresponding account address (hash of the corresponding private key). You print the string of characters on the paper.

Exactly. You could certainly print the string of characters on the paper in plaintext but I recommend also having a QR code - by doing BOTH you ensure that you have a computer-readable value for convenience but should the QR code become too degraded to scan, the text may still be readable by the human eye - especially if you use a passphrase instead of a bunch of random characters since even whole words obliterated may still be recoverable from a passphrase.

Can I select any string of characters? How do I use the bitcoin-application to select what "random string"s bitcoins I should access? What kind of hash is used (md5?)

@KristofferNolgren for any given string of characters x, there is a hash sha256(x) which almost certainly represents a valid private key, so yes you can select basically any string of characters, though you should treat that string like the world's most secure password since anyone guessing it gains access to your Bitcoin account. The functionality to generate a keypair in such a way is not built into the standard client but it can be done with the tools mentioned above, specifically Casascius' bitcoin Address Tool.

A cool but somewhat foolish idea is actually to use a poem etc as your key-string. If you use two of them, the password strength is probably strong enough. Also you don't have to keep any written records... Low tech security is often underlooked, specialy by us techy people...

@KristofferNolgren I've mentioned it elsewhere but I use a combination of actual entropy and remembered entropy for my keys. I have a set of dog tags with sets of random characters labeled 0 thru 9. I remember a PIN of variable length and use the PIN as a guide to concatenate the randomness together into longer randomness. My mental PIN is useless without the tags, the tags are useless without the PIN.

I've decided to write my key on a enchanted staff and hide it in various parts throughout the northern wildlands...

Use bitaddress.org. It is a single HTML file so you can save it and generate addresses offline for extra security.

For a PDF wallet give StrongCoin.com a try. The PDF wallet will have your private keys encrypted (AES 256bit) with a pass-phrase you supply.
The encryption is done with JavaScript on the client side so your private keys are not exposed to the servers.

My favorite method:

grab out a old/unused pc/mac
install a linux over usb (maybe Talis) (make sure your USB stick is clean!)
download a recent version of bitcoin-core (check hash, verify gitian signatures)
copy bitcoin-core over usb to your offline machine
start ./bitcoind
./bitcoin-cli getnewaddress (gives you a new public key)
./bitcoin-cli dumpprivatekey (gives you the corresponding private key)
print or write down both strings (address can be recreated from private key, but print it anyhow)
verify the printed or written down strings
try to delete printers cache (power off, reset)

Now you could delete/format the pc/mac.
But maybe it's worth keeping your new offline computer to generate new addresses or sign transaction in a "cold space/wallet".

I have tried to print a paper wallet before, but after print came out. No QR code is printed on it. QR code boxes of both public and private keys are blank.

Better use WIF private keys instead of a QR Code.

Can you do the 12 words type key back up using this?

I think this is highly inadvisable. Unless you really know what you're doing, this will cause you to lose money through change addresses not being part of your paper wallet.

An alternative is to buy BitBills or something similar. That is much safer (because the key is not visible unless you break the bill) and can also be used as "cash" (you can give it to someone).

You don't want to "save" an existing address as a paper wallet, and instead you want to create (securely) an address (e.g., using BitAddress) and then make a payment that spends your coins to that address.

I read all of your answers, and I couldn't help wondering... whats wrong with writing down the actual private keys on a piece of paper?
What I did was following: I ran listunspent in the console first, to obtain the list of addresses worth safeguarding. Then I ran dumpprivkey for each and every address. I printed out what I got... did I do anything wrong?
To optimize the whole process, I could do a payment to myself to a fresh address of mine, to transfer everything I got to that address. After necessary confirmations, listunspent would retrieve only one address, wouldn't it?
Call it a poor man paper wallet, but this is pretty simple and straightforward, isn't it?

What's wrong is that if you make a mistake you won't be able to spend your coins. What's even worse is that you won't learn you made a mistake until you go to spend your coins i.e. in the distant future. So in the meantime you'll be living your life and spending money with this mistaken belief that you have this stash of coins saved up that you can use should you ever need to.

What possible mistake I can do?

If you copy a character or two incorrectly for example. There are like 50+ characters in a privkey and if you make a mistake and get one or two wrong it is basically useless.

Bitcoin Armoury is the best thing out there for this.

What you want to do is create a new wallet with armoury, create a receiving address and send your BTC there.
The best thing is you do not need to even be connected to the network, synchronized or anything. Armoury can run offline in the dungeons far underneath the earth (like your cellar :) )
You then create a paper backup and print it out 2 or three times. Go and store it in your bank, in your important documents and at your mums house.
Delete armoury. (Yes, but make sure you have your paper backups stored safely!)

Your coins will hang in limbo (on the network) without any transaction history or block chain tracking. COmpletely anonymous and unclaimed.
Now- You might feel like you just threw your coins into thin air and have this uneasy feeling of you will never get your coins back! I know I did. So this is what I did.
I followed the whole process I mentioned above. Created a test wallet. Went to another computer somewhere else and did the same, except I imported the wallet from the paper backup. SYnchronised to the bitcoin network. Viola - The coins appeared in the transaction blocks and in my wallet ready to spend

It is also good for managing many online wallets at the same time. One for savings, possibly donations from your websites or blogs, and a personal one, and even offline unsynchronized for the long term anonymous storing of coins.

As long as the bitcoin network will be running you will never lose offline transactions. Just make sure to keep your paper backup in atleast 3 secure seperate place- and no. Do not store it on picasa albums or gdrive.. keep it offline in a bank, locker and at your nans house under the bed, laminate it, put it in a box and bury it in your back yard next to the tree house.


text:
Quick and easy mining on OS X
I am new to Bitcoins, and I'd like to get started mining, but I'm on OS X. I've tried several different mining applications, and none of them have worked for me. I've got nothing but errors. Is there a mining application that has quick and easy setup?
I have tried DiabloMiner, RPC Miner, and one other that I can't remember the name of. I will put it up here if I find it.

Why don't you list the ones you've already tried, to start everyone off on the same page?

what errors are you getting with RPC Miner? The CPU miner should work for you, but you won't get much with a CPU. I would warn that Mac laptops seemed to become hotter than would be safe for the hardware when GPU mining and iMacs are probably the same... at the very least run smcfancontrol and ramp up the fans if you want to mine on a mac

Try the DiabloMiner app. It uses an older version of Diablo Miner that should work. The developers behind bitcoin mining software usually do not put much effort into Mac compatibility mainly because of two aspects:

Most Macs (iMac/Macbook/Macbook Pro) are not suited for mining because they have poor ventilation, which causes overheating issues.
Apple's OpenCL implementation is not very good. There are constant complaints about its inefficiency and incompatibility with mining software.

I ran it and got: ERROR: OpenCL platform Apple contains no devices

@daviesgeek what is your computer model and OSX version? You might not have OpenCL support in your card.

I have a MBP 8,1 and OS 10.6.8

@daviesgeek You have an Intel HD Graphics 3000 so you can't mine with that. Check here for a list of supported GPUs


text:
What is replace-by-fee?
https://bitcointalk.org/index.php?topic=199947.0
Can anyone explain what replace-by-fee means?

This thread explains it.
It's a method that allows replacing an already transmitted transaction by transmitting another transaction with a higher fee. This only works on transactions before they are signed by miners (0-confirmations).

So basically it floods the mempool with multiple transactions that only differ by fee. It seems this creates more "noise" for miners than necessary.

@Geremia the miner's are economically incentivized to discard the lower fee transaction. It should add more load to the network but shouldn't increase the size of the mempool.

If the fee is so high that makes sense for someone to mine on old blocks, surely it would also work for 1+-confirmations?

Normally a miner will pick the one with the highest fee. Some explorers continue to show the older double spent even after the new one has been confirmed.

After 6 years, Now I want to tell you what is Replace by Fee :)
This feature was proposed in BIP125 and implemented in Bitcoin Core 0.12.0.
In simple words, by enabling (Replace By Fee) RBF in a transaction, if a transaction doesn't get mined, it can be resent by the sender with a higher mining fee with keeping the input data of the UTXO(Unspent Transaction Output) same as before.


text:
Is P2Pool vulnerable to pool hopping?
Some pools / payout mechanisms are vulnerable to pool hopping.
Is P2Pool vulnerable?

From the Wiki on P2Pool:

Each share contains a generation transaction that pays out to the previous n shares, where n is the number of shares whose total work is equal to 3 times the average work required to solve a block, or 17280, whichever is smaller. Payouts are weighted based on the amount of work each share took to solve - proportional to the p2pool difficulty at that time.

So it works like a PPLNS pool, which is not vulnerable to pool hopping.


text:
Could ASICs be used to mine a "BitcoinX4" blockchain?
Bitcoin, on average, has a block every 10 minute. There are advantages (pdf) to having a higher "clock rate", e.g. Litecoin's block every 2.5 minutes. I call "BitcoinX4" the theoretical blockchain that is achieved by speeding up block creation time (hardfork), without affecting the total number of coins (block reward reduced by a factor of 4).
It is conceivable that at some point in the future, a "split" or "hard fork" will be made in Bitcoin, such that its blocks will be generated with a different (higher?) frequency, possibly while keeping a mining majority. For this to happen (hash power majority), ASICs need to be able to crunch the new "BitcoinX4" chain.
So, my question - are the known ASICs today compatible with changing the block speed?

There are also disadvantages to a higher clock rate, like more block reorgs (and hence lost rewards for miners).  While a change like this might be conceivable, it's not very likely.

@eMansipater - more lost rewards for miners doesn't affect a single miner's expected benefit. It's a slight disadvantage, yet, but the downside is practically zero for such a small speedup factor. Anyway, this question is about how we could mine such blocks, not whether it's a good idea or not.

since we're being technical, it would negatively affect miners having poorer latency with respect to new block discoveries, and overall provide very slightly less security for the same amount of hardware cost.  Nonetheless, there's a reason this was a comment instead of an answer.

@ripper234 problem is that to be safe you don't need "6 confirmations", you need "1 hour of confirmations", which incidentally now is ~=1h. If you increase block speed, you'll need more confirmations to consider a transaction safe, hence you'll have gained next to nothing.

@Lohoris - false. Please read the discussion and paper by Meni Rosenfeld, which I linked to.

@ripper234 I'd like to, but it's a broken link :/

@Lohoris - bitcointalk is down. I added a direct link to Meni's paper. https://bitcoil.co.il/Doublespend.pdf

Any mining device can be used without alteration for mining a specific alt-chain, as long as the chain's proof of work is the same (double-SHA), and the size, encoding and position of the timestamp and nonce fields is the same in a block. The latter ensures that devices that increment those fields internally would not be altering other parts of the block header. As block speed is not a part of the header but an external constraint put on the specific cryptocoin, ASICs and other devices should be able to mine such blocks without a problem.

ASICs just calculate double SHA256 (using the correct data size of 80 bytes, and linking between the two hashes as described here). They do not care about protocol rules regarding transactions. ASICs can be used to mine many potential Bitcoin alts/hardforks, as long as the core Proof of Work algorithm remains double SHA256.

Technically it's not just double SHA256--see http://bitcoin.stackexchange.com/questions/7236/bitcoin-mining-asics-used-for-cryptographic-application-rainbow-tables/7264#7264


text:
Can I save mining fees when doing transitive transactions?
If I create two transactions:

Send BTC from output X to Y, no fee is attached.
Send BTC from output Y to Z, fee is attached (this depends on the previous tx).

Would nodes propegate these two transactions? Would miners mine them?
In other words, if transaction T2 depends on T1 and I want to broadcast both together - can I save some fees on T1?

Probably not. Clients can set whatever rule they like for transaction fees, but they normally adhere to the Satoshi client rules described at https://en.bitcoin.it/wiki/Transaction_fees. However, note the section on transaction priority; if you have an address holding some old coins, it's quite likely a transaction out of that address will have high enough priority for you to avoid transaction fees by default.
To implement what you describe, you would need a client that does something like hold all low-fee transactions in a small pool and watches for new transactions out of their output addresses. That's certainly possible to implement, but it seems to me that it would be the sort of service you'd pay a premium for, not receive a discount on.

FYI another user just told me he tested it and it does work ... I guess testing this is the best way to understand whether it works or not, rather than relying on theory.

Maybe a lucky connection to a pool like Eligius that accepts no-fee transactions? I agree, testing is the way to go. Too many variables.


text:
What is needed for Bitcoin to become the reserve currency of the world?
Bitcoin's characteristics seem to make it a prime candidate as a reserve currency, given it has fast transactions to anywhere in the world at a low cost with little to no price manipulation or export/import controls.
Imagine a traveller arriving in a foreign country, having bought 100 Bitcoins in his country. Rather than go through a middle-man currency exchange, he finds someone who wants Bitcoins (or even a Bitcoin ATM) and sell his Bitcoins for local currency.  When he is ready to leave, he simply sells back his local cash for Bitcoins without being hit twice by the currency exchange's transaction fees.
What would have to happen to make this a reality?  Is it feasible?

related: Could Bitcoin work as a world currency?

You would be hit twice by the currency exchange anyway if you were to buy Bitcoins for your local currency, and then buy the foreign currency with Bitcoins. If you would perform those transactions at exchanges ran by large companies, there is little difference from a traditional model. If instead you would use exchanges like Mt.Gox, the spread would go back to the people, rather than a company. The spread might be smaller or bigger, it all depends on the market.
Banks and companies like Visa often allow you to withdraw foreign money at a local ATM in the foreign country, sometimes even not charging you anything for the operation asides the money conversion spread. You perform only one conversion for the bulk of your money, and whatever is left over you can sell back at the money exchange. So by bypassing Bitcoins, you can save money (if the banks operated at a comparable margin as the Bitcoin exchanges, be they owned by a single company or not).
Most Bitcoin exchanges offer you money withdrawal to a bank local to the currency. If you were a tourist, this would not be convenient for you, as you wouldn't have an account in any bank like that. An alternative would be a service like OKPAY, but as it is to handle both Bitcoins and other currencies, there is no need for other exchanges.

So all in all, your proposed idea does not seem to be plausible at the moment. Main advantage of using Bitcoins for such a task is lowering the spread, which could also be accomplished without Bitcoins (say, an online community currency exchange). The proposed idea would however be more plausible if a whole country would adopt Bitcoins as its official currency, which is very unlikely to happen in the nearest foreseeable future (governments seem to move away from currencies tied to a limited resource, like gold or silver, to fiat currencies to enable easier growth).

Problem is right now most of the world would say "What's a bitcoin?" If you were to go to even a high tech center like say Tel Aviv I expect that most people would say "What's that?" On the other hand if you show up with Dollars, Euros or Pounds those are easy to change.
It should also be pointed out that what you are describing is not a reserve currency. A reserve currency is what governments and banks hold to protect themselves against currency variations and other market forces.
Current reserve currencies are more or less the US Dollar and the Euro and a few others(Swiss franc, Japanese Yen, Pound Sterling). In order to be a reserve currency a currency has to be backed by a very large economy.


text:
Does encoding Namecoin/messages into the blockchain bloat it?
I read today twice concerns about inflating the blockchain:

NameCoin
Bitcoin Message Service

So, does using these services "over inflate" the blockchain? The way I see it, if another protocl rides on top of Bitcoin but obeys by its rules and pay all the proper transaction fees / mining time, then it's "legit". My question is how can such a "legit" protocol inflate the blockchain more than a regular miner would?
Does it introduce spurious transactions? If this actually became a problem, wouldn't increasing the minimal transaction fee solve it?

NameCoin merged mining adds no more than 49 bytes to the size of the block.  Namecoin messages aren't stored in the bitcoin block chain, instead the hash of the most recent namecoin block is stored in the Bitcoin block providing continuity between a potential hash and the Namecoin block chain.
So yes it technically does "bloat" the Bitcoin blockchain but it current is ~4% and that percentage will decline as transaction volume increases, as that fixed 49 bytes is measured against increasingly larger blocks.
As for "how" can it be done.  The coinbase transaction (which transfers rewards and fees to miner's address) contains a field called coinbase.  Without merged mining this field is used to generate entropy for hashing process (extra nonce) which alters the block header each time it is changed.  Allowing a miner to try nearly infinite number of hashes.
This field is not used by the blockchain for anything other than entropy so adding namecoin hash to the field doesn't collide with any Bitcoin transaction.  Once a block is signed the field is never used for anything other than verifying the block valid (by verifying the hash is correct and is smaller than required target).

So ... how much extra data could we put in a block? I'm sure there's an upper limit.

Asked as a separate question: http://bitcoin.stackexchange.com/questions/1438/is-there-a-limit-to-how-much-extra-data-can-be-put-into-blocks-via-scripts

Also, there is a maximum block size which keeps this "non-transaction" stuff from getting too large.

Of course you can simply encode a message as the amount of bitcoins sent in a transaction. And like any transaction, a transaction increases the size of the blockchain. Could that bloat, that is could it add a significant amount of "undesired" data to the blockchain? You can bloat it up to a point where the "value" of your message is smaller than or equal to the transaction fee (including the "value" a disruption of Bitcoin itself might have to you).
If this results in an increase of the size of the blockchain faster than hardware vendors (hard disks, CPU, internet bandwidth, ...) can keep up with then the transaction fees will increase, too. Whether at this point "normal" transactions have become unfeasible - I don't know. I guess that comes down to the question how scalable the Bitcoin protocol is and will be.

Stack Exchange is not a forum. Please post questions as separate questions and not answers. Later, when you have a bit more rep, you'll be able to post comments as well. See the FAQ - http://bitcoin.stackexchange.com/faq

@ripper234 I think asking a question whether this question is insufficiently answered would have been a silly thing... And I don't have a proper answer either. I've spent an hour trying to figure out how to write it as a comment instead of an answer (the FAQ does not mention it) but only found this weird "not-an-answer" tag suggestion and that someone else would convert it to a comment...

@ripper234 Ok, thought about it some more and maybe writing it as a comment is not the thing I'm looking for - I'll try to rewrite it as an incomplete, but disjunct answer. (I guess someone else can improve/merge/... answers later, right?)

Yeah, this looks more like an answer now, thanks (-1 removed).


text:
Who controls the Bitcoin software?
Is there anything comparable to a "board of directors" for Bitcoin or is the software on complete cruise-control?

possible duplicate of Is there a list of core Bitcoin committers?

Was this closed and reopened? Anyone care to explain?

http://meta.bitcoin.stackexchange.com/questions/238/why-was-this-duplicate-question-reopened

Having push access to the GitHub repo doesn't necessarily make a "board of directors" - though it does confer some degree of power over the codebase. I'd suggest that as a distributed project, anyone who can get 51% of the network to use their version of the client could usurp any existing power structures and as such no "board of directors" model could exist. In any case, I don't feel that "who writes the code" and "who controls the direction of the software" are necessarily identical, though if you'd like to cast votes the community is welcome to contradict me :)

Another related question: http://bitcoin.stackexchange.com/questions/2094

There are a number of "core" developers. And the ones who have access to commit directly to the Github project obviously have more "power" than other people. Since the software is open source you can of course make your own copy of it and modify it to your likings but you won't be able to change any of the "rules" of the network unless you get the rest of the Bitcoin world to follow you and use your client.
According to bitcoin.org the core developers are Satoshi Nakamoto, Gavin Andresen, Pieter Wuille, Nils Schneider and Jeff Garzik. According to a recent message on the Bitcoin Development mailing list Wladimir (J. van der Laan?) is now also part of the core development team. Obviously Satoshi is not anymore, so I don't know how accurate the list on bitcoin.org actually is.
The ones who have push access to the Github project are according to this message:

Gavin Andresen
Nils Schneider (a.k.a. tcatm)
Pieter Wuille (a.k.a. sipa)
Jeff Garzik
Alex Waters

Gavin, who is the lead developer is active here so I'm sure he can give us a clearer answer himself. Also see Is there a list of core Bitcoin committers?

You control it.
It is open source, so if you want to modify the copy you're running, go right ahead.

The list of project mainters who have commit access is listed here: Team of bitoin core
Currently they are

Wladimir J. van der Laan
Jonas Schnelli
Marco Falke

In some sense don't the miners control the software? If there are some changes made to the bitcoin code and the majority of miners (by hashrate?) don't upgrade for what ever reason then    the changes won't be implemented.

Even if a large number of miners switched to a new rule set, everyone running the bitcoin software would ignore them. The blocks from the miners who are still in agreement with the community would be accepted. So if any miners were to try this, they would only lose out on revenue and be ignored.


text:
Who currently pays the miners for processing transactions?
The graph: Bitcoin mining cost per transaction leaves an ambiguity. Who pays the transaction costs?

According to the list of available charts, that chart is showing "miners revenue divided by the number of transactions".  That is, it's the average amount a miner earns for each transaction they process.  "Bitcoin mining cost per transaction" isn't a very good title for the chart.
So far, the vast majority of miners' earnings comes from the 50 BTC per block rewards, with a tiny fraction coming from the transaction fees paid by the people creating transactions.
So to answer your question, nobody pays the vast majority of the cost; it is created out of thin air as the reward for mining a block.  You could see it that each new block generated inflates the money supply and so devalues all existing Bitcoins, in which case you could argue that everyone holding Bitcoin is paying via inflation.  But the inflation is predictable, and so already priced in.

I disagree, it's a very good naming. The cost of mining is shared by everybody. There is nothing "created out of thin air", the cost is compensated by the growing interest in bitcoin.

In a transaction, you pull in funds from one or more sources and send out funds to one or more places. A transaction may not send out more funds than were paid into it. The transaction fee is simply the difference between the funds sent out and the funds pulled in.
For example, look at transaction 31b39c2bed53253561f5c4957aea68644877efe7c2a9fb2f642837029de30e2a. It has five inputs, each .5 bitcoins, for 3.5 bitcoins. It has two outputs, one .01 bitcoins and one 2.48 bitcoins for 2.49 bitcoins total. So the transaction pays a fee of .01 bitcoins.
The transaction fee is paid from the transaction inputs. Each entity in the Bitcoin system can make its own decisions about transaction fees. When a transaction is formed, the program creating the transaction typically decides what the fee will be and constructs the transaction accordingly. When a server receives a transaction, it can decide if the fee is high enough to justify relaying it or it can refuse to relay it. And a miner can decide which valid transactions to include in blocks it mines based on transaction fees however it wants. The Bitcoins system does not require any agreements on transaction fees.

So the fee is automatically deducted? According to what rules?

When you form a transaction, you specify the inputs and the outputs. Any funds in the inputs that are not spent by the outputs become the transaction fee. I'm not sure what you mean by "according to what rules". Are you asking about how transaction fees are typically computed? Or what they have to be to be relayed? Or how to get miners to accept transactions? (See my updates.)

Off-topic answer?

I know this is an old question, but in case it is useful for anyone else...
From the graph is not instantly clear to me whether how this "reward" is being calculated. But simply put, the reward a miner gets every time it successfully places a block into the blockchain is composed of 2 parts: 1) the fee that transaction originator wishes to pay to the miner and 2) the reward "the network" awards to the miner.
Focusing on the first part of the reward, a miner will include your transaction on the block he is building based on whether a) your transaction has an attractive payment offering (or fee) attached to it or b) he believes on the decentralized economy and thus is simply trying to contribute to its functioning rather than doing money, in which case he could take transactions with 0 fees attached to them. It could also be that he is just randomly selecting transactions. At the end, it is really up to the miner to decide what transactions he wants to add to the forming block. Most of the miners will select the transactions on how high the fee is; so the more you are willing to pay the miner to post your transaction, the higher the possibilities that your transaction will be posted soon into the blockchain.
Moving on to the other part of the reward for the miner, every time a miner solves the required algorithm he can claim bitcoins for his work. To do so, he attaches a new transaction to the same finished block, where he awards himself some bitcoins (currently set at 12.5 bc, but this parameter is halved every 210,000 blocks created -about every 4 years-, so it will be 6.25 after 2020 and so on).
This transaction is unique in itself because no one is sending the miner these bcs, nor they come from an ethereal pool of available bitcoins waiting for miners to claim. In that sense, yes, they are newly minted bitcoins produced out of thin air. It is worth noting at this point, though, that there is a limit to the total amount of bcs that can ever exist, which is set at 21,000,000, thus making bitcoins a "limited resource". This limit has still not been reached, what is planned to happen around the year 2140.
The validity of this final transaction rests on the fact that the other miners can validate whether he really solved the block or not. When everyone has validated this, they add this block to their own blockchain and propagate the info, effectively recognizing among the whole network composing the blockchain that this miner has now 12.5 more bitcoins to spend.
Can these newly created bitcoins help devaluate the existing coins? I guess so, just as with any normal currency when more bills and coins are created by its respective central bank. On the other hand, I also guess that people loosing their private keys and thus the funds assigned to it also counter this devaluation.
Bottom line: Who is paying for the fees of the transaction? the person requesting the transaction to be put on the blockchain. This fee can even be 0. Who is paying for the mining of the block? No one. These bcs are new and assigned to the miner at the moment.


text:
Does the amount of the transaction fee affect the priority of a transaction?
I've been reading about transaction fees here.
From the aritcle,

Transaction priority is calculated as a value-weighted sum of input age, divided by transaction size in bytes:
  priority = sum(input_value_in_base_units * input_age)/size_in_bytes
  Transactions need to have a priority above 57,600,000 to avoid the enforced limit (as of client version 0.3.21).

There are rules for determining the transaction fees needed depending on client etc.
My question is does paying a fee increase the priority or else how does it increase the chances that the transaction will be accepted by the network. If it changes the priority, what is the formula for determining priority. If you pay more than the default fee does it increase the priority even more?

Currently no.  Any "required fees" are enforced only by the client not the network or protocol.
It is up to each individual miners which transactions to include in a block.  If forced to make a choice a miner would choose a paying transaction over a nonpaying one however current transaction volume is so low that all transactions (paying and otherwise) can fit into next block with significant room to spare.  If you used a modified client with no fees most miners would simply include your fee transactions.  Some pools (Eligius) will exclude free transactions that "should" (based on mainline client rules) have a fee.
As for what fee is the minimum to guarantee access to the next block.  Most miners and mining pools prioritize transactions by fees and then priority.  If you include any fee (even 1 satoshi) even if it is less than what is required by mainline client it likely will be included in the next block. Paying more is likely of negligible value as paying anything almost guarantees access to the next block.  The block size limit isn't much of a capacity constraint to warrant higher fees (and move further up transaction list ordering).  I can't see any miner excluding a valid paying transaction from any block at current transaction volume.
The current fee structure (or lack thereof) brings up some scalability issues when block reward aproaches zero.  The development team has indicated an improved fee structure is something planned for later releases.  It is an issue which will need to be addresses as left as it is now one could simply include 1 satoshi fee with every transaction and it would drive block fees down to ~ (transactions per second) / 166,667 BTC per block.  Even at high volume of say 1,000 tps it would be a tiny number and thus network hashing power would fall to a tiny fraction of current hashing power leaving the network vulnerable.

Thanks. I'm really thinking about a possible future with much higher transaction volumes and there is competition to be included in a block - I believe the maximum block size is 1MB. So say there are more transactions than can be included in a block (sum of the transactions is >1MB) and the miner has to prioritize transactions, would it be correct to say the ranking would go largest fee to smallest, then largest priority to smallest. i.e. a transaction with even a 1 satoshi fee would trump a transaction of large priority with no fee.

@kirian  Yes if the block was capacity constrained any smart miner would choose 1 satoshi fee over no fee and thus unless there were so many transactions that not all 1 satoshi fee transactions would fit it would guarantee a spot in the next block.  Of course this dynamic leads to the problem in my third paragraph as everyone is likely to do this.

There's a very nice visualization of the most recent 4 hours' worth of transactions and whether they paid a fee or not, and how long it took each one to be confirmed:
http://bitcoinstats.org/
Sometimes it looks like fee-offering transactions have a significant advantage over no-fee transactions, other times it looks random.


text:
How much Bitcoin will I mine right now with hardware X?
Say I have a given piece of hardware (CPU/GPU). Where can I find out how much Bitcoin will I mine per day?

Bitcoin Mining Profitability Calculator: http://bitcoinX.com/profit

BitCoin Mining Hardware profitability. By the way due to the rising hashrate of the bitcoin network caused by the introduction of ASICs to the market, CPU/GPU mining Bitcoins has become impracticable, you'll spent more money in energy than you gain in Bitcoin.

Go to http://bitminter.com/test and click the "test start" button. If you have Java installed the miner should launch. Click "engine start" on your GPU(s) to start mining and the GUI will show how many bitcoins per day you will make (on average).
Note that you are actively mining in a pool without getting paid. This test page launches a version of the miner which is only meant to be used for a short time for testing.
Update for 2015: CPU and GPU mining are both long dead. When you buy ASIC mining hardware you will know its hashrate before you buy. Don't buy if you don't. Google "bitcoin mining calculator", input your hashrate, and it will tell you how much you can earn right now, on average. Note that the difficulty will change in the future so your earnings will not stay the same. Also note that with most pools actual earnings vary with luck. Finally, avoid the typical newbie mistake of confusing TH/s and GH/s. 1 TH/s = 1000 GH/s.

2018, GPU for btc is dead but not for other currency.

There is a list here that is kept relatively up to date with the possible hashrate of various CPUs and GPUs
https://en.bitcoin.it/wiki/Mining_hardware_comparison
Once you know the number of hashes you can generate, you can use an online mining calculator and calculate the numbers of bitcoins you can mine per day (on average) and the current price of those bitcoins in other currencies.
http://tpbitcalc.appspot.com/
It is worth pointing out that when most people talk about "mining" bitcoins these days, they are talking about pooled mining. Depending on the fees of your pool you can make anywhere from 2%-10% less than expected. If you mine by yourself, the bitcoin you are expected to make has a high degree of variance.
https://en.bitcoin.it/wiki/Pooled_mining

These days when you say. do you mean 2018 or 2011?

D = Difficulty
H = MHash/s
C = Reward (currently 12.5 BTC)

24 / (D * 2^32 / (H * 10^6) / 60 / 60) * C = BTC/day

Take note that the last figure (50) in this formula is the block reward, which at some point will halve to 25 and continue halving until it reaches zero, at which point mining will be subsidized only by transaction fees, which this formula also ignores. It's not unreasonable to ignore them for the time, since they're a very tiny fraction of mining income, but still :)

Can you explain or reference what the 2^32 number is from and how its calculated?

A difficulty of D requires on average 2^32D hashes to solve. In fact, that's not entirely accurate. The exact number is 2^48/65535D.

@Pieter Wuille...So is his formula correct, because PEMDAS matters? I am trying to build my own calculator on my web page, for my own use, where ALL inputs are required. Many of these online calculators do not include, or allow input of variable items that are important.

What is PEMDAS?

Operation order; parentheses, exponents, multiply, divide, add, subtract

@Pieter Wuille...PEMDAS is operation order; Parentheses, Exponents, Multiplication, Division, Addition, Subtraction. I believe the correct formula is ...(DaysInMonth * Hashrate * BlockReward * SecsInDay) / (Difficulty * Exponent)  ..to get the monthly mined coin rate

The formula is correct, but one of the constants is slightly off (by about 0.0015%).

this doesn't make sense .../60/60 means that the two 60 cancel out.... and so you end up with 24/(D2^32/(H10^6))*C

@Naz No it does not.

Where does the 24 come from?

If:
D is the current difficulty
H is your hash rate in Mhash/s
B is block reward in BTC

Then you can expect to earn:
  (H*B/D) * (60*60*24 * 65535 * 10^6 / 2^48)
= (H*B/D) * (5.662224e15 / 2^48)              BTC per day (1)

or roughly:
  (H*B/D) * 20.11626                          BTC per day (2)

The current block reward B is a little over 12.5 BTC if you take transaction fees into account. (The transaction fees vary block by block; the core reward halves periodically, e.g. to 6.25 in mid-2020.)
(1) is exactly correct
(2) is an approximation, correct to 7 significant digits
This answer is slightly off due to assuming 65535 == 65536.

So what's the values of D, H, and B? There's a load of multiplications but none of them show 12.5 so it's impossible to disassemble this.

Yet another bitcoin mining profitability calculator - detailed and including a decline factor to compensate for mining hardware advancement (I am the author).

You should consult this wiki entry to know how many hashes per second can you generate with your hardware. Afterwards, just input the value into a bitcoin mining calculator and you will have an estimation of your payout ratio.
Please note that this calculator does not take difficulty into account so your earned value is likely to change over time. There are other calculators that try to predict the evolution of the difficulty, but they are not very accurate. Right now, difficulty depends on too many factors to be correctly predicted for a period longer than a couple of months.

I was confused by the profitability calculators I saw because I find it hard to get a feeling for how the difficulty influences my yield and also for where I can expect the difficulty to go, since it's such an abstract value.
So I now use what to me is more intuitive: there's a (more or less) fixed number of 3,600 BTC gained from mining each day, until the block reward halves in 2017. Those coins can be viewed as being shared by the whole network proportionally to the computing power of each player.
So, let's assume a network power of 360 Thash/s, which seems not far away as I write this, and makes for easy calculation, then for every Ghash/s that your equipment brings to the table, you get 0.01 BTC per day.
If you're solo mining, this is overly simplified, but the general direction of solo mining is that your actual yield will only on average match the theoretical one, so if you're much much smaller than the network (likely), then your variance gets so high that it becomes a lot like a lottery.

NiceHash has a nice calculator that will give you expected return on crypto mining, based on hardware and electricity price

If you are interested in how your profitability will change as the network hashrate grows this calculator is the best IMO.
http://bitcoininsight.com/2013/04/05/bitcoin-mining-profitability-calculator/
Although you will have to make some guesses about how the network will grow, it should be more accurate than just a plain guess as to what the difficulty will be in X months time.

This page 404's for me. Do you have a link that doesn't?

I found the correct link and submitted an edit to this answer: http://bitcoininsight.com/2013/04/05/bitcoin-mining-profitability-calculator/


text:
What is a Mining Pool, what is it good for?
What advantages / disadvantages does it offer over solo mining?

A Mining Pool is a protocol for a group of miners to work together, in order to smooth out their mined coins. A miner working alone would generate a block (= 50 Bitcoin) whenever he is the first to find a correct hash. In practice, this happens quite rarely for a single miner.
When several miners are working together in a pool, their earnings are split among all miners (with the pool usually taking some commission). This guarantees an even spread of earnings over time instead of "all or nothing" in solo mining.
One disadvantage of a mining pool is its centralicity - most pools today have central nodes that can be DDOSed, and if not configured accordingly when a DDOS happens the miner will just sit idly instead of reverting to a different pool or to solo mining.

Exactly. It's just like a lottery pool. Your odds of winning a lottery are very low, so you team up with a bunch of other people and agree to split the winning. This makes your odds of winning much higher, but the amount you win much lower.

Is there some sort of system that guarantees the owner of the mining pool will redistribute equally the gains if a block is successfully mined ? What prevents the pool owner to claim the entire reward of a block for himself without letting know the contributors of that pool ?


text:
How can P2Pool charge a fee?
P2Pool is an open source peer to peer mining pool. It currently charges a fee of 0.5%.
Is it possible to just fork P2Pool protocol and eliminate the fee? Has this been done? If so, how can P2Pool still retain users when a cheaper alternative remains? If this hasn't been done yet, why not?

Since November 17, 2011 no fee is charged.  Instead an optional donation of 0.5% is sent to the author of P2Pool to support future development.
If you don't want to donate to the author you can run P2Pool like this:
python2 run_p2pool.py --give-author 0.0 [USERNAME] [PASSWORD]

The 0.0 is a percentage of your earnings and can be set to whatever percentage you like.

Maybe more appropriate to call it a 'donation' than a 'fee' these days, since it is optional.

You may split the project and create your own distributed pool, but you choose to reap no rewards from doing so (the first 0.5% fee), and without a bonus to the block finder (the other 0.5% fee).
The pool combines both fair share rewards and a finder's bonus to compete against other pools. The initiator has so far earned 0.75 BTC for his development and promotion efforts. If you feel this is too much for a system that eliminates centralized downtime (connectivity and stale issues) and centralized trust (delayed payments, locked funds) you should not use this pool.
An added benefit of p2pool is that all addresses receive funds from the generation transaction directly to their public key. This means until you spend those funds your funds are completely anonymous and untraceable.

I'm not a miner myself, I just asked this out of curiosity. I wanted to know what competative edge there is to the system that prevents others from simply forking it and dropping the fee.
I think @David's answer is right on.

This answer is more correct than David's.Somebody could indeed fork P2Pool, but it would be difficult as the fee is pretty small. In addition, the fee is planned to be changed to an opt-out donation, which will help too :P

It wouldn't be that hard to start a new p2pool if you were prepared to outlay some btc's.  ie donate to the pool so it pays out 105% of expected payout, doing that would attract some big miners.

In a proportional pool the fee isn't the only factor that influences adoption.  Size is also important.   Larger pools result in lower reward variance and this creates a dynamic which makes it difficult for small pools to grow.  Small pool remain unattractive because of high volatility thus can't grow to reduce volatilty and remains small pool.
So even if tomorrow you forked p2pool and launched p2pool-free unless you had sufficient hashing power it would be difficult to attract miners.  It creates a pradox of needing sufficient hashing power to gain more hashing power.  The desire of low variance is a strong one; three largest pools have mandatory fees yet they have attracted the majority of network hashing power.
To grow the pool large enough to create a self sustaining growth cycle would likely require some outside capital.  Capital could be used to provide bonuses or to rent hashing power outright from large miners.  The quandary is that by adopting a 0% fee the investment will never be recovered directly.  The investment may worthwhile indirectly because one potential outcome would be a large decentralized 0%-fee pool that has self sustaining growth.

P2Pool has a unique design due to its proprietary p2p protocol. However, it is inevitably just another pool. Its decentralized block creation feature was originally released by BitPenny using a Bitcoin-like protocol, and is now also supported by pools running on Eligius's Eloipool poolserver. Just as with all pools, however, P2Pool does have a centralized point-of-control calling the shots. On the other hand, just like with any pool,  someone can always fork it and make their own pool.


text:
Getting orphaned Blocks from the Blockchain
I'm very interested in doing some analysis of orphaned blocks, but to do so I'd have to have a good way of accessing them. Blockchain.info seems like a good place to start but I don't want to abuse their API by scraping the entire Blockchain. Another attempt was to use ABE but after parsing nearly all the blockchain from my Disk (several days of work) I am unable to find a single orphaned block, and I'm starting to fear that the satoshi client prunes old orphaned blocks, which would be a pity.
Will I be able to find orphaned blocks with ABE, and if not what alternatives are there?

Orphaned blocks are stored in blkxxxx.dat files forever, though each node will know about different orphaned blocks. Bitcoin will print a list of all known blocks, including orphans, to debug.log if you pass it -printblocktree.

Uh, I didn't think about them not being stored on nodes that haven't seen them in the original broadcast. So nodes that weren't online when the orphaned blocks still had a chance of becoming legit will never see it? How long has the orphaned node to be abandoned until it is no longer announced?

@cdecker Blocks are only relayed across the network once; nodes won't relay a block if it has already been seen or if it doesn't extend the currently-longest chain. So nodes that aren't online when a block is broadcast won't see it unless it becomes part of the main chain.

That confirms what I was seeing. So if there is no archive that kept a log of all transactions I won't be able to reconstruct forks at all, right? Blockchain.info only has forks back to block 142257. Any idea where I can find more?

@cdecker Here's my printblocktree output on a node that's been running for a very long time: http://www.mirrorcreator.com/files/1EB4UZDD/printblocktree.txt.bz2_links

Regarding Abe, it should load orphan blocks from the blockchain if you use the blkfile loader... I haven't looked in detail the use of the orphan_block table but it's empty on both my db's despite the fact I do have orphan blocks in them (I can't say it's a bug yet but it sure looks fishy).
You can search orphan block by hash in Abe, but to find the hashes you need to look directly in the database. This query works for me on MySQL, using binary hash storage (hence the HEX() function); be sure to remove it if you store hashes as CHAR hex strings (used to be the default).
SELECT block_height, HEX(block_hash) FROM block b
  LEFT JOIN block_next bn ON (b.block_id = bn.block_id)
  WHERE bn.next_block_id IS NULL
  ORDER BY b.block_id DESC LIMIT 1,10;

The LIMIT 1,10 is to skip the most recent loaded block which is most likely the tip; it has no block_next_id but it's not orphan neither.
If you use the RPC loader, you can only catch orphan blocks while loading the latest blocks; it won't receive any orphan from bitcoind unless if it hasn't yet been orphaned! You may catch some using abe_loader and eventually with some code I'm still testing that will allow constantly loading mempool and blocks.

From what I can see, ABE works pretty much like the BlockExplorer in regards to orphaned blocks, which is to say it forgets them. It appears that only Blockchain.info actively stores orphaned blocks, and even displays them in a neat list.
The only other way to analyse orphaned blocks is to keep a history of the last couple blocks and constantly keep checking whether they changed. This is the approach I used for testing a simulated 51% attack on the TestNet in my master thesis. However, orphaned blocks don't occur all that often. You can look into a question on that, or go directly to the stats.


text:
What happened to Krad Miner (the first javascript GPU miner)?
Krad Miner was the first javascript miner that supported GPUs. Now, the website yields a 502 error, and there has been no response to post #57 in the thread asking about it being dead.  Does anyone know what happened to it?

Maybe you should ask in the forum thread? I'm not entirely sure this is what stack exchange is for. This is more of a "have you seen person X" question.

@Evil post #57 in the thread already asks that question, and I've made an edit to reflect that (though the edit may take time to be accepted).  I don't see any problem having a discussion here about various interesting clients.

@nealmcb the problematic word there is "discussion." StackExchange is a question & answer site, not a forum. It's meant for questions, answers and comment on those questions and answers - not discussion. That said, others have asked questions as to the status and whereabouts of other Bitcoin projects and systems and we've answered them without argument so it seems that unless I've missed a big discussion on meta this question should be acceptable so long as it's actually answerable.

Alrighty, maybe so. I withdraw my complaint.

Good point, @David - I agree that discussion is not useful here - but I also think I slipped when I used it, since this question is suitable for being answered, not just discussed.

Sorry guys, I forgot to prefix my title with "What happened to". Isn't this a legitimate question now? If I were to ask "what happened to MyBitcoin, that wouldn't have been legit?" If there are answers in the forum already, feel free to link to them.

@ripper234 Actually it looks like when I was making another edit, I started to try to improve the lead-in to the question title, but forgot and just deleted those words - sorry.

Oh. No worries, as long as it's fixed now. @nealmcb.

I purchased Krad Miner from the creator for the bounty cost of 50 BTC, and have released it as open source (Apache 2.0 license) on Github. Since the author has other projects using the Krad label, I have renamed it to Tumen Miner. I would currently consider it alpha-quality; I have not run it, merely cleaned it up as best I could.
In the short term, I plan to fund some minor testing and development on it. Longer term, I may start coding on it myself, if I ever find the free time. I welcome donations in the form of bug reports, code pull requests, and BTC to pay the coders.
Merry Christmas, coiners.

The creator took the service down after coming under DOS attacks. He offered to open source the software for a bounty, and eventually brought his offer price down to 50 Bitcoins. The message with the offer was on the kradminer website until a couple of weeks ago, and only recently has the site been inaccessible.