text:
How can a single person operation keep a collection of online wallets secure?
While this question is similar to others about securing wallets, I think it merits a question of it's own.
One thing that has dissuaded me in the past from running an online wallet service of some kind is the worry that I could be compromised (rubber hose, extortion, intimidation etc) and by extension permit full access to a large collection of bitcoins that I don't own. If I'm running an operation with potentially millions of dollars worth of bitcoins and my contact details become known (not that hard to find really) then I'm naturally a risk to my clients.
I've heard of multi-key encryption so that no one person has complete access (client PIN etc), but I'm not sure if that would solve the problem.
So my question becomes how can a single person operation ensure that they are unable to compromise the wallets under their care? Ideally the answer would not require any technical knowledge on behalf of the client beyond a passphrase.
(If such an approach became commonplace then it could act as a deterrent because attackers would simply see that the website uses that approach and slink away.)

Couldn't this be done with client side encryption? You could create a software to access your service that encrypts/decrypt client side. You would have no way to access the client's coins without knowing the passphrase. Wuala uses something like this for encrypted online storage. You must launch a Java applet from the browser to access your files.

@nmat I was hoping to avoid the need for this kind of requirement by the client.

Been reading around this subject over on the Security SE blog and found this entry: http://security.blogoverflow.com/2011/08/12/qotw5-defending-your-website/

And another one: http://security.stackexchange.com/questions/3584/how-do-you-compare-risks-from-your-websites-physical-perimeter-staff-etc

Interesting approach by @Plato

I've decided to go with @Fellow Traveler for the accepted answer in light of the work s/he has done in the area.
I thought I'd add some of my thinking to the answers under a community wiki to allow others to help grow the solution. Once I'm happy with the first draft, I'll post it up (should be in a day or so). I'd like to thank everyone for their efforts with this tricky question.

This draft is much harder than it first appears, so I've appealed for help from the crypto exchange folks: http://crypto.stackexchange.com/q/746/812

It would appear that there is a way, involving shared secrets, OpenID and a bunch of co-operating nodes. Work is ongoing to solve this problem.

My solution in Open-Transactions is to create a voting pool between participating transaction servers. (I noticed people discussing the project here so I wanted to make sure it's clear that this has only been proposed -- I haven't coded it yet.)
When Alice bails into an OT server, instead of sending her BTC directly to the server, she would send it to the voting pool.
===> My proposal was, whenever she wants to bail back OUT again, she sends a signed request to the server, and then she forwards the server's signed reply to the members of the pool. IF the pool members have a record/audit of Alice's account (which must be in a DHT they share) and IF the two signatures both verify on the receipt, and IF the request is within the allocation for that server and its maximum bailout-per-day, then the pool members vote ON THE BLOCKCHAIN to release the funds back to Alice.
===> This can also have a time delay on it, like a 24-hour bailout if necessary, and it is also subject to all pool members having access to audit data of the other pool members. (The other transaction servers.)
===> In the event where a server is HACKED, it will still be unable to move any of Alice's Bitcoins, because the other pool members won't vote for it without Alice's signature.
===> In the event where the server uses a dummy account (hidden from the DHT) to inflate the internal currency, the other pool members won't vote for such bailments out because it can't get past the real-time or daily audit.
===> In the event where a server refuses to answer Alice's bailout request, she can submit it to the pool members, which triggers a message to the offending server. If there is no reply, after a timeout, then they can vote 9 out of 10 (or whatever) to release the funds. This makes it possible to recover funds even from servers that have disappeared outright.
I work on OT in my spare time so it will easily be a few months before the above protocol is actually operational. But that's the basic plan.

+1 for the careful thinking. Would you mind explaining how "bailing" works in the context of the shared pool, and how currency inflation could take place?

It is possible, in Bitcoin, to send a transfer to a list of Bitcoin addresses, instead of to a single address. Then the recipients can vote (on the blockchain) to transfer the funds out again. This is made possible via the Bitcoin script language itself. Once the Open-Transactions side of the protocol is written, then it will take advantage of this built-in capability of Bitcoin.

As long as the pool members make audit information available to each other (preferably in real time), then they will always know whether/when a server exceeds the amount of funds in circulation than it actually has in the pool. An OT server cannot normally change your balance, or forge any of your transactions, since it cannot forge your signature on the receipt. But the server COULD potentially create a "dummy" account (that it controls) and then sign FALSE RECEIPTS with that account, thus inflating the currency. BUT--this could NOT escape notice of the afore-mentioned audit protocol.

This is a great goal, which many people will assume just can't be done.  But remarkable strides are being made in the field of secure cloud computing via homomorphic encryption.
These schemes allow servers in the cloud to perform computing tasks (currently only a limited set of arithmetic) on encrypted values without decrypting them.  See more at In what ways does Full or Partial Homomorphic Encryption benefit the cloud? - IT Security - Stack Exchange
A question about applying this to Bitcoin clients on Less Wrong is here: Homomorphic encryption and Bitcoin but they seem to be confusing homomorphic encryption with a form of secret splitting between two computers, which would not meet the goal outlined here.
I'm guessing that current homomorphic techniques are inadequate or too slow or both for bitcoin, but I'm not sure.  But further research may make it practical.

+1 this does indeed look promising. However this is far beyond the capabilities of the vast majority of startups.

@Gary Indeed - as I noted the current state of the field probably renders it impossible or at least practical at this point.  It is an open research area and currently it is beyond the capabilities of most researchers, if not all of them.

Then why post an answer that's not technically possible yet?

@david Even if it is not possible now, as I said, the OP describes a great goal.  Bitcoin is new enough that people haven't always figured out how other technologies apply to it, or what lines of research should be pursued.  This seems like a good line of inquiry to follow, and besides that is likely to be of interest to geeks that like bitcoin.

Fair enough, I suppose.

Further explanation of Homomorphic Encryption: http://www.americanscientist.org/issues/pub/2012/5/alice-and-bob-in-cipherspace/1

One piece of technology that may provide an answer lies in federated servers, made possible by fellowtraveller's Open Transactions libraries. This is the same M of N signing that David Perry is talking about in his answer.
As a small e-wallet provider, you would join up with some colleagues, forming a network of wallet operators.
Using the scripting capabilities of Bitcoin, user Alice can create a special transaction and post it to the blockchain. This transaction is basically an IOU - it has an expiration date, and some instructions. If the instructions are met before the transaction expires, the transaction takes place, and the Bitcoin network agrees that the money is transferred.
Alice can specify multiple parties (i.e. you and your colleagues) to be the executors of the IOU. Her script can say "I require 9 out of these 10 wallet servers to sign this transaction."
So, this collection of federated servers must reach a consensus to make the transaction happen. If one, two, or eight of the ten servers are hacked, or the operators are forced to reveal the keys entrusted to them, the attacker won't be able to spend Alice's bitcoins, because he won't have the consensus.
I encourage anyone interested to check out the github repo and contribute. Fellowtraveller has done all of this work on his own so far and needs help.

+1 for what sounds exactly what what I'm looking for. You see, this is why I like Bitcoin so much - there is always a way.

Thinking about this a bit more it appears that some kind of back channel is required to inform others in the federation to sign or not. For example, what if I'm held hostage for a few days getting the passphrase beaten out of me. I can offer up a plausible deniability passphrase that releases some low value funds, but alerts others that I've been compromised so they stop confirming. However, this alerts the thieves and that's the end of me.

Even having some kind of pre-arranged transaction value/volume per hour type arrangement is no good because if I reveal I'm under duress I've got no bargaining position with the thieves. I must rely on an outside, automated process that I can't influence making the decision that my signature on the transactions remains valid. Perhaps I have to turn up in person somewhere secure to renew the signature every X days or it expires. X must be low. Even then the problem is that it may not be me directly being compromised, perhaps family instead.

An easy way around it is some kind of Bitcoin insurance for small businesses - that's pretty much what a traditional bank would do.

It all depends on your definition of what an online wallet is.
You can make an online wallet service where the server side only knows your public keys and does all the heavy lifting required to track the block chain including the bookkeeping necessary to determine which transactions belong to your wallet. The client side is the only entity that has your private keys, and is the only one who can spend coins.
If the server side vanishes into thin air you can always take your private keys to another provider or import them into a classic client.
This kind of online wallet requires you to have a small piece of client side software running, such as a smart phone.
The BCCAPI is an example of such a service.

While certainly not as advanced as nealmcb's writeup of homomorphic encryption, a solution offering a reasonable level of security against "rubber-hose access" could be built via a combination of cold storage, M of N signing and plausible deniability passwords.
Basically, you keep most of your bitcoins in one or more offline wallets which are kept in a physical format at a secure location - in order to compromise those coins/wallets you would have to be coerced into physically travelling to that location which is much riskier to the thief than simply beating a password out of you. Second, if there were three "signers" on the main account and two of them were required to make a transfer, beating the passwords out of at least two of them is twice as hard as beating the passwords out of just one, especially if they are geographically distant. Finally, it would be a simple matter for many existing sites to make username/password combinations their unique constraint rather than just username. This would effectively allow users to create one or more "dummy" accounts that could be compromised without compromising their entire balance. Since they all share the same username it would be difficult to prove how many accounts someone had without a full compromise of the site itself, hence providing at least some level of plausible deniability.

Very interesting. I'll have to think through that quite carefully...

The big one, in my opinion, is the "cold storage" option since it means that someone attempting a "rubber-hose attack" would have to force you to begin the withdrawal, then wait the 24-48 hours it takes to get coins out of cold storage and then force you to initiate a transfer; double the amount of coercion necessary and an exponential increase in time-on-scene (which no criminal wants)

I wish I could give you a more helpful answer, but the truth is that this is a very hard problem. Part of the solution is to separate your Bitcoins into a "working stash" and a "storage unit". Bitcoins in the working stash are easy to access and can be manipulated fully automatically. Bitcoins in the storage unit require manual intervention to release. YOu keep the working stash as small as practical to reduce the risk of a compromise.
If you have a very large number of Bitcoins, you may need multiple levels of storage with different levels of security/inconvenience. The goal is to lock up as many Bitcoins as possible as tightly as possible because you only very rarely need them.
Ideally, the ultimate "storage unit" should be offline. When you need to get Bitcoins out of the vault, you create a transaction to take that number of Bitcoins out of the vault and transfer them to the working stash, returning the change to the vault. You then walk that transaction to the storage machine which signs it. You then walk the signed transaction back to the online machine that commits it to the network.
The idea is that the offline storage machine's sole purpose is to sign transactions. Everything else is done by other machines. (Make sure it displays the amount and destinations before it asks you to sign!)
This just presents the problem of how you secure the offline storage signing machine and what you do if it breaks. The latter problem is the easier one -- you can lock a paper copy of the master encryption key in a vault.

+1 for raising some of the practical difficulties involved with this. I just wish there were some way to automate the owner out of the process.

Generally in the private industry, this isn't done. You trust that these industries do it right, but usually they don't.
Security is difficult, really difficult. Securing against yourself (thumbscrew and rubberhose access :p) when you have direct access to the hardware makes it even harder.
You might have the client use a password that is not stored, but is used as an encryption key to secure their wallet, and only them providing that key would unlock it. Of course you could always intercept that key, plus you have access to the encrypted data and algorithm used.
Honestly I wouldn't trust any public wallets.

It's having access to the root of the box that is the fundamental problem. Once that is compromised then all else can follow.

The answer is client side encryption.
Basically it works something like this.

You register with the e-wallet service.
CLIENT - You then create your first Bitcoin key pair. This is done with Javascript running in the browser.
CLIENT - You are asked for a strong password to secure this key pair.
CLIENT - The private key is encrypted in the client with Javascript.
SERVER - Finally the public key and the encrypted private key are sent to the server for storage.

The e-wallet service doesn't have access to your private keys.
When you need to spend coins from your address.

Select the Bitcoin keypair to spend from.
CLIENT - You are asked for the password to decrypt the private key. Again this is done client side.
CLIENT - The payment transaction is signed. (In the browser)
SERVER - The transaction is sent to the server and forwarded to the Bitcoin network.

Again the e-wallet service never sees your private key.
There are still risks with this approach.

Keyloggers or malware could capture the passwords you use to encrypt the key pairs. It would be prudent to use a browser on a clean operating system or on a system not prone to malware e.g. A Kindle.
You have to trust the e-wallet service to not change the Javascript and capture your passwords. An external 3rd party could validate the Javascript via checksums perhaps.
A server breach could allow an attacker to change the client side javascript. The service should provide it's own mechanism for verifying the integrity of the code delivered to the browser.
The wallet service should keep secure offsite backups.

This is the approach being taken by a number of new wallet services such as StrongCoin and BitcoinJS.

Thanks for your answer, but it's not quite what I'm looking for. Running the service this way still leaves me vulnerable to being forced to add malicious code which compromises my clients. They should not have to trust me. I want to be provably out of the loop.


text:
How do mining pool payout methods affect the cost of executing a block withholding attack?
I'm wondering how each payout method (PPS, DGM, PPLNS, Proportional, etc) influences the cost of executing a block withholding attack.
Does it matter how the payout method places variance between pool and miners? With DGM this is a setting that can be adjusted by the pool operator. With other payout methods it is inherent to the system.
Does a block finder's bonus influence the cost of an attack? By that I mean part of the block income being reserved for the miner who created it, before the rest is distributed according to the pool's chosen payout method.
Are other factors important?
Which systems would be expensive to attack, and which would be cheapest?

Do you mean "block SOLUTION withholding attack"?

Yes, that's what I mean. Since every bit in a block is part of what makes it valid I don't see a big difference between a block and its solution.

@Dr.Haribo As you asked here - http://bitcoin.stackexchange.com/q/4943/323 - there is a difference between withholding a block and withholding a block solution. Generally the latter is relevant to miners in a pool, whereas the former - to the whole network.

@ThePiachu - good point, I'm talking about the scenario when mining in a pool.

@StephenGornick, P2Pool and Eligius are also vulnerable.

Related: http://bitcoin.stackexchange.com/q/1338/516

Generally, the higher the variance for the miners of a reward method, the higher the cost of sabotage attacks (and I think also the potential profit of lie-in-wait).
In PPS there is no variance; and the cost for sabotage is negligible, it is merely the reward of 1 share.
In a typical method with no risk absorption and moderate variance, withholding a block means you lose your portion of its reward, which is h/H, your portion of the pool hashrate.
If you take an extremely high-variance reward method such as "pay per last 10 shares", withholding blocks means losing 10% of the reward, since if you submit a block then by definition you have a share in the last 10 shares, no matter your hashrate.
And of course, when solo mining, block withholding means losing all of your mining reward.
A block finder bonus is added multiplicatively to the other costs. For example in PPL10S with 20% finder bonus, when withholding you lose both the 20% bonus and 10% of the distributed 80%, for a total cost of 28%. However, finder bonus is a poor way to combat block withholding because it creates a lot of variance.

I think that specifically the distribution of risk between miner and operator doesn't play a big role, but I'll need to think about this.

source: Stack Exchange

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

sort: votes


text:
What is a simple explanation for how the number of bitcoins in circulation is determined?
Often times when I explain to someone that there is a limited supply of bitcoins available that need to be divided across all the people who want to have bitcoins, the people who are computer illiterate will ask how I know that the number of bitcoins in circulation can not be changed or manipulated. They usually just get a glossed over look on their face when I start talking about decentralized protocols. Has anyone come up with a good way of phrasing it or an good analogy to get people to understand how these limits are determined, enforced, and protected?

You could explain the coin limit like this:
When Bitcoin started, its creator set a rule - "No more than 21 million Bitcoins will ever be created, and they will be given out gradually for creating blocks" (Add further explanation of block reward or proof-of-work here if needed). Everyone who joined Bitcoin knew about this rule, and they were all for it. As everyone can see all the money created by solving the blocks, everyone can check if someone tried to go against the rule and cheat. If cheating is detected, nobody will accept the solution, instead looking for one that follows the rule. Because everyone is checking everything, nobody can cheat and create more Bitcoins than is allowed.

You download a program that "generates" random numbers again and again and again (millions of times per second depending on your computer speed). Think lottery.

Two different people will not get the same random number, because each person has his own predefined set.
For a very simplified example, numbers from 1 to 1000 belongs to "me", and numbers from 1001 to 2000 belongs to "you". If you decide to generate a random number from 1 to 1000, you are helping me win the lottery.

If the random number matches a "pattern", it is accepted. If it doesn't match the "pattern", it is rejected.
For a very simplified example, if the "pattern" says we accept only even numbers, then ~50% of the random numbers will "hit lottery" and 50% will miss. If the pattern was so easy to match, I can simply generate the numbers 2, 4, 6, 8... and get a 100% hit rate. Apparently in the real case, even the simplest "pattern" is so hard to match that we can't simply work backwards and try to derive a number that will match the "pattern". The only way to get a number that will match the "pattern" is though trial-and-error, which is why its exactly like lottery.

If the pattern is easy to match (relatively speaking), we will get many hits. If the pattern is hard to match, we will get lesser hits. The pattern changes every 2016 hits to ensure that we get roughly 1 hit every 10 minutes. If we hit too quickly, we get a harder pattern to match (so future hits will be slower). If we hit too slowly, we get an easier pattern to match (so future hits will be faster).

A cheater can't just invent a "simple pattern" to follow, because everyone agrees on what pattern to follow. If his pattern differs from the majority, it means that the majority wouldn't accept it (we don't recognize the coin he generates).

This is how we ensure that batches of BitCoins are created roughly once every 10 minutes and a cheater can't simply decide to generate them every second.

Bitcoins are misnamed: a bitcoin is not an object, not even a virtual
object. There is one global bitcoin ledger, containing a history of
all bitcoin transactions.
Everyone can see and check the ledger.
The ledger is made of "pages" (they're actually called "blocks").
Creating a valid page in the ledger has been made artificially very
difficult, needing on average many days of CPU time - this means that creating
a whole fake ledger (actually called the "block chain") is even more difficult, so nobody can do it.
Each page has to identify the previous page in the ledger, which you
have to do before you do the difficult work. That means you can't make
random pages, you can only make the next page in the ledger.
To get people to do this very difficult work, each person who makes a
page is allowed to put one special transaction in the page, crediting
themselves.  This is the only way new credits get onto the ledger, as
normal transactions just move credits from one account to another.
Making these ledger pages is called "mining", and anyone can do it,
but it requires a powerful computer.
By the rules, the first 210,000 pages can have a special credit of 50
bitcoins.  That halves for the next 210,000, and again for the next
210,000, for ever.
If a page has a special transaction that adds more credit than the rules
allow, then it's not a valid page and nobody will use it as part of
the ledger: their software will reject it.
That means that mathematically, the total of special credits, which is
the total of all the bitcoins in circulation, can never reach 210,000
x 50 x 2, or 21 million.

2.1M -> 21M. Great description, btw :)

This would be great for the "Simple English" Wikipedia.

How about this.  Think of the mining process as being like a variation of the game Bingo.  Let's call this variation proof-of-work (POW) Bingo.  POW Bingo is almost a reverse of how Bingo is normally played.
Let's say that for each game of this reverse Bingo, a dozen numbers are dropped from the drum of numbers and all twelve numbers are shown all at once.
And then there are many tables in the Bingo hall, each with a huge pile of Bingo cards on it.  There is one table used per Bingo game.
So when a game starts each person playing grabs a card from the pile and looks to see if the card contains a winning Bingo.  If it doesn't, the player tosses the card aside and grabs another card.  This is the "work" being performed ... searching for a winning Bingo card.  There is likely more than one card in the pile that would win the Bingo game, but the race is on to be the first player to find a winning card for that game.
The player who does find a winning card yells BINGO, notarizes the batch of transactions in the bitcoin ledger (which have been accumulating since the beginning of the game), and asserts ownership of the prize (currently a 25 BTC reward).
All players then want to move on to another table to start playing the next Bingo game but knowing which table to go to is something pre-determined by the ID of the winning card at the game that just had the winning Bingo.  There's a chance the player claiming to have a winning card had lied or was otherwise mistaken so each player will first want to confirm the validity of the card that supposedly is a winner.  The checks performed are that the card truly does have a Bingo (based on the numbers that dropped from the drum), that the prize claimed is no more than the amount allowed to be claim for that particular game, and that each transaction in the batch of transactions is valid (funds had not previously been spent in prior batches).
If that all pans out then at a later time the player who called the Bingo is allowed to spend the bitcoin reward earned from that game.
After verifying the winning Bingo card each player then knows which table of cards to move on to next.  At that next table is another drum of numbers.  That drum too now has its twelve numbers dropped so the next game of this reverse Bingo can start.
After each Bingo game is completed one result is that there exists a trail going from the current table back to the previous table, and from there back to that game's previous table and so on all the way back to the very first Bingo game that was played.
So there is this chain of games that were played, each dependent on the results (discovery of a winning card) of the prior game.  The current Bingo game always occurs at the "tip" of the chain, and that chain's length will include each table along the path back to the very first Bingo game played.
It is possible in a game for there to be more than one person to have a valid winning card.  When that happens there are multiple calls of "Bingo" and these could be yelled out at about the same time.  This introduces a conflict because there ultimately needs to be only one winner per game.
The approach to solving this conflict occurs in a unique way.  When there are two Bingos that are each valid for the same game, some players will move on to the next table pointed to by one of the winning cards while other players will move on to a different table as that was the table pointed to by the other winning card.
Thus in that instance the path for the chain of successive games will appear to have an end with a split.  This is referred to as a fork.  Some amount of work (players looking for winning cards) will occur on one side of the fork and some other amount of work will occur on the other side of the fork.
Eventually a Bingo will be called on one of these sides or the other and the conflict is resolved as whichever side is the first with a winning Bingo ends up  being the side which extends the path for the chain further.  The rule observed by all players is to recognize the chain's path which includes the most number of tables as the path to follow.  If a player finds that some other path (generally the other side of the current fork) becomes longer (i.e., has a higher number of successive Bingo games in the chain) then the player abandons the current path and joins the others at the game table at the tip of the path that has the longest chain.
For the most part, this longest chain will be the one in which the most work (sorting through Bingo cards) is performed.  Luck can be the reason why one side of a fork happened to win even though it had fewer players than the other but overall the longest path ends up being the link of games in which the most amount of work had been performed.
Because there is money that is earned from the per-game award, word gets out and more people will arrive at the Bingo hall to help sift through the cards.  As a result of a growing number of players (and thus, more work being performed) it starts taking less and less time with each game before a winning card is found.
To counter this, periodically the quantity of Bingo numbers that are dropped from the drum is decreased, from say a dozen numbers to just eleven numbers.  This decrease makes it more difficult to find a winning card because it generally takes more work to find a winning Bingo card from the table's pile when only eleven numbers are dropped versus the the amount of work needed when there were twelve numbers dropped.
It really doesn't matter which set of numbers are dropped, because for each round, nobody has an advantage -- everyone has equal access to sift through each table's pile of Bingo cards.
The end result is that no matter how many people are sifting through the piles, roughly the same number of Bingo games are held each day (targeted to 144 games per day, with one game occurring every 10 minutes).
This approach is what ensures that there is no cheating that would cause a significantly greater reward to be issued and why more miners arriving won't cause currency inflation (i.e., a higher production of the per-game award).

Personally, I think it's useless to explain or to mention this limit (it's just an imaginary limit anyway, new chains with better properties will appear before it is reached!).
So, you'd rather just mention that bitcoin generation is limited to some fixed amount per day. This limit is guarantied because people who want to join the game of money creation have no other choice than to follow the pre-existing rules (and this includes everyone, for example current miners but also future developers)… unless one manage to convince more than half of the network that rules need to be changed. Such a change would be similar to the birth of a new (improved?) currency, that everyone would adopt and which may enforce different rules.
Notice that nowadays this happen quite often. Bitcoin is still young and minor changes proposed by the developers are adopted easily.

I usually explain it like this: What constitutes a "Bitcoin" is precisely defined, just like what constitutes an "ounce of gold" is. Due to this definition, it is not mathematically possible for more than a certain number of distinct Bitcoins to exist. For example, since we all know what "a positive integer less than or equal to 100" means, there can only ever be 100 of them.
You may need to go on to explain that just as two 33's are copies of the same number, there can be any number of copies of the same Bitcoin. And in fact there are thousands of copies of every Bitcoin. Since they are copies, they reflect the same owner owning the Bitcoin.
If you need to go on to even more detail, explain that Bitcoin has an ordering rule such that a "bigger" version of the same Bitcoin "wins" over a smaller one. When I give you a Bitcoin, I get a miner to "add in" the transfer making your version of the Bitcoin bigger than mine. Thus your Bitcoin wins over mine, and so I can no longer spend it but you can. I give you the Bitcoin by announcing this "bigger Bitcoin" to the world, so nobody will ever accept my "smaller Bitcoin" again.

Don't use any big words like "decentralized".
I just say something like 'The system is designed so that roughly every 10 minutes 50 new bitcoins are generated'.
Then again, most people I dare to discuss bitcoin with are techies.
You could always try the mining gold analogy.

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


text:
How does change work in a bitcoin transaction?
It seems that when you send a bitcoin transaction, all the coins in the sending address are spent in that transaction, divided into the amount that you intended to send, and "change", which goes back to you, but at another (newly created) receiving address.
That makes it a bit difficult to track your balance on block explorer (especially since the new receiving address does not seem to be displayed in the Bitcoin client anywhere).
Does it have it have to work like this, or is this a specific implementation detail of the client software?
Also, do you have to wait for change to be confirmed before you can spend it again?

I have this same issue. The question I have, does the spec (https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki) dictate what is supposed to happen? Or is it up to the wallet to take the best guess as to what to do? And secondly, if wallets are allowed to do whatever they want, how can an app traverse all the addresses that might be used by some other wallet to transfer funds to? It seems nearly impossible because it seems like a wallet could do whatever it wants. It might hide your funds in some obscure place if it doesn't follow any conventions.

First, let's clarify the difference between accounts and addresses.
"Accounts" are used for the convenience of people to track their funds. This is primarily used to track the source of funds. Since this is just for your tracking, you can move Bitcoins from one account to another just by moving a number from one column to another. No transactions are needed. (This is like when you know you owe your son $25 for allowance, and you have $200 budgeted for groceries.)
"Addresses" are used to receive Bitcoins in transactions. The coins are sent to an address. The client associates each address with an account and adds received funds to that account. This is simply done for convenience to allow people to track indirectly which address funds were sent to. But you can have any number of addresses associated with the same account.
Change comes from the way Bitcoins are spent. To spend a certain number of Bitcoins, you must pull in Bitcoins from transaction outputs to accounts you control. Note that in the spending part, it doesn't matter what address this is or what account that address is associated with. When you spend Bitcoins from a particular account, that just means you debit that account for the amount you send. It doesn't mean the funds come from addresses associated with that account. Remember, the association between addresses and accounts is for receiving only, not sending. (Like when you spend money on groceries, it's not like you have specific bills for groceries. You just have an amount budgeted.)
So when you pull in transaction outputs, you form a pile of Bitcoins big enough for the number you are trying to send. Usually, it won't be exact since you must claim an entire output. So the excess forms the 'change'.
Since there is no address associated with sending Bitcoins, there is no particular address the change should be sent to. So, to preserve anonymity, the client creates a new one just to receive the change from this transaction. Since this address isn't really associated with an account and shouldn't be used to receive any more Bitcoins (because that would senselessly tell people the same recipient got the coins as got this change) the client does not display it.
Because the client manages coins in a particular way, it doesn't make sense to try to view coins it is managing with any kind of explorer. It's specifically trying to obscure the fact that all the coins are related. Those kinds of services are intended to monitor recieved funds, not managed funds.

The information in David's answer is correct, but it may not answer the actual question -- it's unclear whether the question is about change in general, or specifically sending change to a new address.
If the latter, nothing needs to be added. If, however, the question was about the practice of change in general, then yes, it is necessary.
The reason for this is that an output, when used as an input, must be spent in its entirety. Say someone sends you 10 BTC, that 10 BTC is a single output. You cannot spend part of that coin, the same way you couldn't slice off a part of a physical coin and have it maintain its value.
The reason for this is that an output is actually a script, and to spend an output you simply broadcast the solution to this script. That output, in its entirety, becomes an input -- and if you were to not include change, the difference between the inputs and outputs would all go to transaction fees.
What is client-specific is how to handle this change: the Satoshi client sends it to a new address, while other clients may simply send the change back to one of the output addresses.
The change is an output like any other, which means that you do need to wait for confirmations -- but you can still use that change to send another transaction immediately, you'll just need to wait for the first transaction to confirm before the second one can.


text:
In a double spend attempt, how is the valid transaction chosen?
Suppose I publish the private key of an address that contains 1 bitcoin. If two people try to transfer this bitcoin to another address before a new block is found, who gets it? How is this decision made?

possible duplicate: http://bitcoin.stackexchange.com/questions/730/what-does-the-bitcoin-client-do-when-it-receives-conflicting-transactions

When a node receives two conflicting transactions, it will only relay the first one that it received, dropping the other.  If one transaction fully propagates through the network before the other is sent, the first will prevent the second from ever reaching any miner nodes.
If both transactions are sent at roughly the same time, the network will be in disagreement about which one is valid.  This will be resolved once a miner node finds a block and includes whichever transaction it had first heard about.

Miners are not obligated to include any specific transaction in a block.
If one person gets a headstart then any non mining node will not relay the duplicate so the "first mover" will quickly cut off portions of the network from other contenders. However if both transacitons are create at roughly the same time it is possible that each duplicate transaction will reach the nodes that support mining pool(s) via different routes.
A mining pool can include any transaction they wish and tend to run customized versions of the bitcoind to optimize block generation.  It is in the miner's best interest to take the transaction with the higher fee at the detrimnent of other transactions.  Thus using a transaction fee could increase the chance of being included in the next block.
Utltimately the transaction included in the block will resolve the "race".

The network "cut off" might be bypassed by sending TXs directly to the pools.


text:
Is Blockchain.info Open Source?
I know that there is a github public repo, but I'm not seeing a license file. The Android client is GPL3. Anyone know about licensing for the main site's code?

Propose update for 2017 status.


text:
Is it possible to increase the transaction fee of a sent transaction not yet in a block?
Is it possible to increase transaction fee of a transaction that is already  sent and seems stuck?

Today? No.
There was a feature that was developed referred to as child pays for parent however few miners if any are using this patch.
There have been instances where mining pool operators have been offered a bounty to include a specific transactions, but there is no automated process for that and presumably would require a significant incentive.

No, you can't "edit" in a transaction, but you can doublespend the transaction (e.g. create a new transaction with a higher fee, but reuse the same output as the other transaction).
I'm not sure it's possible in Bitcoin-QT (without doing some ninja tricks), but you might be able to do it by using Armory to create a offline transaction (e.g. Armory don't know about the sent transaction if it only get the wallet and blockchain on a offline computer).

Won't such double spending have negative consequences? Did anybody tried it?

This wont be a double spend, because it is impossible to double spend ;) Blockchain.info (or someone else) might log double spend attempts, but I can't really think of any 'punishment' by doing so :)

Nodes that already know about the first transaction will not relay your double spend attempt, and the possibility of success depends on quirks such as a miner not knowing of the original transaction due to a restart and then takes the double spend attempt as it seemed to be legit.  Suggesting a double spend as a workaround is not good advice.


text:
Does blockchain.info retain the wallet password in client-side memory?
When you log into blockchain.info - you enter the password on the client side.
Does the password remain stored in a local javascript variable on the client side after the login process is over?
If yes, does that count as real a security risk? What kind of attack vectors does that open you to?
If not, how else does the wallet update the server side state?

http://bitcoin.stackexchange.com/questions/5249/how-secure-is-blockchain-info

I guess that it must have, because it updates the server after any modifying operation is made, without asking for a password.
That is DannyHamilton claims as well. See also.


text:
Are there enough Ripples for everyone?
There is a finite amount of Ripple tokens (XRPs). If I recall correctly the amount is 100 billion XRPs.
Opening an account requires 200 XRPs.
So, are there only enough for 1/2 billion accounts, ever? Can the numbers be tweaked later on? Could XRPs be divided below 1 XRP?
Was this problem discussed anywhere? (E.g. on the Ripple forums)

XRP can be divided into millionths. The reserve levels can be changed by consensus. By the time this becomes an actual issue, the system will be managed by consensus and there's no way to predict what stakeholders will decide to do. The rough expectation is that they'll try to keep the cost of opening an account consistent with the actual cost imposed on the network by having an additional account.
Also, just to point it out again, those 200 XRP aren't lost. You can use them to fund transactions. You just can't transfer or exchange them. The reserve is designed to discourage ledger spamming.

BTW, I recently asked for some XRP on this thread - https://ripple.com/forum/viewtopic.php?f=1&t=5&start=40 - can you spare a few?

There are two people watching for XRP requests and servicing them. I'm not one of them. We really need to get the faucet working as soon as possible.


text:
Multibit backup created partial transactions
Here's what happened. I took backup of the following:
   savings.wallet
   savings.info
   savings-data (and all its contents)

Then I connected to internet, started my MultiBit. The wallet was open by default. There was a new deposit transaction.
I closed the wallet. Opened my backup wallet, to see if it can pick up the new transaction.
When I opened the backup wallet, it can recognize only until when backup was created. It doesn't recognize the new transaction when synced.
When I have two copies of the same wallet file, one recognizes the new transaction while the other sees all transaction except the new one.
Why would this happen?

Try Tools -> Reset Blockchain and Transactions in the backup wallet.


text:
What can I do to track stolen funds?
I have mtgox account, and once I changed my android software i forgot to link another google authenticator, so to access mtgox I had to unlink it of OTP.That wwas two weeks ago
Last week, i still didn't linked new OTP, and I had my BTC funds stolen and widthdrawed to another account. I know that transactions canot be undone by can I do anything to find where are my BTCs?
Regards

Did you check transaction history at MtGox?
A key element of the Bitcoin protocol is the block chain, which is a public transaction database. This contains most all transactions made in bitcoins and also includes information such as the sending and receiving addresses. You can find historical transaction data for the past 3 months by using a block chain explorer like ABE or Blockchain.info.
As the person before me stated even if you could find where they are there is no way to take them back.

If you are not able to know the exact date and the address that was used to take the BTC from your MtGox account, I dont think there are any way to know where they went.
And even if you could find where they are (or where you think they are) there are no way to take them back.


text:
Synchronizing with network – What does it mean?
The messages:
synchronizing with network
xxx blocks remaining

what does that mean?

It's most likely you're using the client from bitcoin.org.
Synchronizing with the network refers to the download and verification of the blocks in the block chain, which is the transaction history of Bitcoin. The block chain is the record of who spent what and when they spent it, and who owns what now.
Currently, the bitcoin.org client downloads the entire block chain on installation, which is somewhere around 3GB of data. As it downloads each block, it confirms each transaction, which is a disk-intensive activity. Unless you have high spec hardware, expect it to take many hours, possibly even days.
Version 0.8 of the bitcoin.org client alters the synchronization process, which heavily reduces the time required to get the client functional. The process is faster through being less disk intensive.
Alternative clients are also available, such as Armory or Electrum, which don't use the same synchronization process. Electrum doesn't download the block chain, and the features list for Armory says it doesn't need the block chain.


text:
Between which locations are transfers using Bitcoins cheaper than PayPal for 100$?
I believe that once it becomes significantly cheaper to transfer money between countries using Bitcoins, its usage will increase significantly. My question is, therefore, between which countries will a transfer (from bank account to bank account) be cheaper using Bitcoins than PayPal. For simplicity, let's say that the PayPal fees are 2,9% + 30 cents per transaction and that the amount to transfer is 100$.
From Denmark to the US, I believe that the fees will be like the following:

My bank account to MtGox bank account in Denmark: 0%
MtGox exchange fee: 0,6%
Loss due to market spread (difference between buying and selling price/2): 1,12%
Transfer of Bitcoins: 0%
MtGox to USD: 0,6%
Loss due to market spread (difference between buying and selling price/2): ~0%
MtGox to US bank account: 0%?

This means that there will be a 2,32% fee between these currencies if there is no fee from MtGox to US bank account, while the PayPal fees will be 3,2% for 100$. This means that Bitcoins will be a cheaper method of transfer between Denmark and the US. Now I would like to know which other countries it would also be cheaper to use Bitcoins to transfer between?
The reason why I calculate market spread as difference between buying and selling price/2 is because the market price should normally be in the middle between the buying and selling price on an exchange. The spread will depend on the daily trading volume of the exchange, and since the trading volume between Danish krones is so low, the exchange cost due to market spread is a significant expense.

In the euro zone MtGox is not cheaper for small payments like $100. Depositing and withdrawing euros both include a fee of ~1.20 euro (10 PLN) + 0.60% for the transfer.
I don't know what deposit/withdrawal fees are for US dollars, neither if there are exchanges that do not require this fee. I know Intersango does as well.


text:
Trouble with getting litecoins in my give-me-coins account
I started mining litecoins yesterday on cgminer (been mining for about an hour) and so far I have got nothing in my account.
What am I doing wrong ?
Here are two screenshots one is of cgminer, the other is of my give-me-coins account:

http://gyazo.com/2fb18a76dedb71eb80c8a19126ab231f
http://gyazo.com/89ca55239de31a6da4bca25072096b4e

You need to launch cgminer with --scrypt at the command line, you will see instead of Mh/s you should be getting Kh/s.

could you teach me how to do that plz

do you have a script that you are using to launch cgminer?

im realy new to this and i dont what you mean by "scrypt" or "command line"

how do you start cgminer ?

I open cgminer.exe

are you using a config file? or did you make a .bat file to start the program

I insert the pool address, then the worker name, then the worker pw

yh i did make a .bat file

the problem is it just automatically closes itself

checkout this link it might help https://www.weminecryptos.com/forum/topic/540-guide-how-to-mine-litecoins-from-scratch-both-cgminer-and-guiminer-version/


text:
Where to get difficulty data for all crypto coins?
I need to get difficulty data and exchange rate for past 10 days for making a graph out of it (i.e., for all coins). Can anyone suggest where can I get it?

I suggest you take a look at CoinWarz's API, you can collect your own set of data for a period of time out of it (say 10 latest days, format it your own way and save it on a spreadsheet). You'll need to generate an API key on their site, and then you could either use your own scripts, or visit the API endpoint manually to collect the data, if you so desire (remember that you need your own API KEY to get the data).
Once you have the data you could generate your own graph within a spreadsheet or your  software of preference.
Recomendations: OpenOffice (info on graphs, download page), LibreOffice (info on making graphs, download page).
Here's the reference for that specific API call (quoted from coinWarz's documentation)

Mining Profitability API
The Mining Profitability API provides profitability data listed on CoinWarz.com. This >data can be for all coins or for specific hashing algorithms: SHA-256, Scrypt, Scrypt-N, >X11, X13, Keccak, Quark, Groestl, JHA, Blake-256, NeoScrypt, Lyra2RE
API Endpoint
http://www.coinwarz.com/v1/api/profitability/?apikey=YOUR_API_KEY&algo=all
API Call Usage
  This value will be deducted from your API usage limit each time you successfully call this API.
Required Input Parameters
  All input parameters are required and not case sensitive.
Parameter - Data Type - Description
ApiKey - String - Provide your approved API key for this parameter.
Algo - String    - Provide one of the the following values for this parameter:
  all, sha-256, scrypt, scrypt-n, x11, x13, keccak, quark, groestl, jha, blake-256, >neoscrypt, lyra2re

Remember that each time you either visit the API Endpoint or call it to fetch the info with a script, it'll count as 1 call out of your limit, as noted on their documentation.
Now the easiest way for you to collect the data if you're not into programming your own stuff, would be to use some REST client extension for your browser such as Postman REST client (If you use a different browser look into their respective stores)
It's fairly easy to get used to and you do not need to code your own scripts.
Here's an example of how the info would be rendered for to you:

(remember you need to place your own API key in lieu of the placeholder "YOUR_API_KEY")
I recommend you use the JSON and PRETTY options so the data is more human readable.
You can then export this to a CSV file using this awesome tool (JSON to CSV)
This site allows you to pase the JSON data and transfer each value pair to a CSV file
Here an example of how it looks:

Now you have a (set of, since you need multiple days) CSV file that you can use for graph creation using the aforementioned Office Suite Tools.
Hope you'll find this helpful, and good luck!

Are you looking for an API or for just the data?
You can't really find every last coin as more are comign each and every day.
However, coinwarz or coinchoose usually have most of the data.
coinchoose has current+historic data available via json api

Maybe your answer is in coin warz.

YoMismo, thanks for your answer. I just added a post notice because I think you could explicitly show where on "coin warz" the OP could find the information they are looking for. Thanks!

The information is exactly in the link I posted, there you have the difficulty and the coins mined up till now. I thought there was nothing else to explain since the information is right there and if that information is posted here it would be easily outdated since it changes fast.

It seems like the OP wants to use the data for making a chart though, so they probably are looking for a way to get raw data in large amounts, not just to look at the current difficulty data that is displayed on the front page of coinwarz. I agree, though, coinwarz is a great resource for this, and posting current difficulty data would not be worthwhile as it would go out of date very fast.

Going by the apis given in Coinwarz documentation, it seems that there is no way of getting historic coin difficulty data.

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


text:
How to collect Dust transactions?
Most of my initially received bitcoins were from faucets and therefore, these micro amounts ended up being dust transactions. Since then, I've bought some bitcoins which are not dust.
Now I'm trying to send 0.0005 BTC to test out Blockchain.info's "receive payment API" (http://blockchain.info/api/api_receive) PHP example (https://github.com/blockchain/receive_payment_php_demo).  But Bitcoin-QT is telling me that I must pay 0.0005 BTC transaction fee.
I found out that the fee is due to the dust transactions.  Now, I like to get rid of these dust transactions  by combining their amounts.  Can anyone suggest an easy way to do this?
I was thinking of installing Armory and then transferring all of my bitcoins from my Bitcoin-QT wallet, in one transaction, to my Armory wallet.  Will this eliminate the dust transactions by combining all of my dust amounts together?  Will my new Armory wallet contain just one input transaction, and not over a dozen transactions of small amounts?
If Armory is not the way to collect the dust transactions, can someone explain how to?

possible duplicate of How can I combine all the tiny amounts I've received to minimise transaction fees, and do I need to?

The answer at http://bitcoin.stackexchange.com/questions/5583/how-can-i-combine-all-the-tiny-amounts-ive-received-to-minimise-transaction-fee seems more complicated than UNIX.  It talks about using Eligius mining pool to consolidate the dust transactions.  But how do I do this?  I took a look at Eligius and I don't see any explanation of consolidating dust.  The answer states:  "As for combining the "dust" while leaving larger balances alone -- you would have to find a client that allows you to choose the inputs to your transaction. I don't know which clients can do that."  Does anyone know?

I have not tried it myself, but Peter Todd has a python script called dust-b-gone.py
https://github.com/petertodd/dust-b-gone

This would be great, but how do you use it, I really do not know Python, the read me says to unzip it, but I do not have a clue how to do this. Complicated for the average Joe.


text:
Is wallet.dat transferable between OS?
Am I able to transfer my wallet.dat from Ubuntu QT to Windows QT by backing up the file and pasting in the other operating system?

Yes. There is nothing OS-specific in wallet.dat file.


text:
Where can one find the listing of the 3-call letters for all of the altcoins?
There's BTC, and everything else.  But how are the call letters registered and is there a comprehensive list of them all?

As said above, there's no real, official "standard" everybody follows. Now then, you can go have a look at different exchanges and see what the call them. Cryptsy is famous for allowing you to deal with dozens of crypto-currencies, and they're constantly adding new ones (as well as taking out those deemed defunct) - you could go to their home-page and download
Be warned, though, that not all call-signs are 3 letters-long, though. Dogecoin appears as "DOGE" in most of the exchanges it appears at, and forty-two-coin is usually represented as just "42".
Some call-signs, off Cryptsy's page - notice the 4-lettered ones, the non-obvious (as eMark being "DEM" or Primecoin being "XPM") and the potentially confuse (as "LK7" and "LKY")
42   42Coin
ALF  AlphaCoin
AMC  AmericanCoin
ANC  AnonCoin
ASC  AsicCoin
BET  Betacoin
BQC  BBQCoin
BTC  Bitcoin
BTE  ByteCoin
BTG  BitGem
BUK  CryptoBuck
CAP  BottleCaps
CAT  CatCoin
CENT Pennies
CGB  CryptogenicBullion
CMC  Cosmoscoin
CNC  CHNCoin
COL  ColossusCoin
CSC  CasinoCoin
DBL  Doubloons
DEM  eMark
DGC  DigitalCoin
DOGE Dogecoin
DVC  DevCoin
EAC  EarthCoin
ELC  ElaCoin
ELP  ElephantCoin
EMD  Emerald
EZC  EZCoin
FFC  FireflyCoin
FLO  FlorinCoin
FRC  FreiCoin
FRK  Franko
FST  FastCoin
FTC  FeatherCoin
GDC  GrandCoin
GLC  Globalcoin
GLD  GoldCoin
GLX  Galaxycoin
GME  GameCoin
IFC  InfiniteCoin
IXC  IXCoin
KGC  KrugerCoin
LK7  Lucky7Coin
LKY  LuckyCoin
LOT  LottoCoin
LTC  LiteCoin
MEC  MegaCoin
MEM  MemeCoin
MNC  MinCoin
NAN  NanoToken
NBL  Nibble
NEC  NeoCoin
NET  Netcoin
NMC  NameCoin
NRB  NoirBits
NVC  NovaCoin
PHS  PhilosopherStone
PPC  Peercoin
PTS  ProtoShares
PXC  PhoenixCoin
QRK  Quark
RED  RedCoin
RYC  RoyalCoin
SBC  StableCoin
SXC  SexCoin
TGC  TigerCoin
TRC  TerraCoin
UNO  Unobtanium
WDC  WorldCoin
XNC  XenCoin
XPM  PrimeCoin
YBC  YBCoin
ZET  ZetaCoin

http://coinwarz.com and ther profitability-comparison sites also have good, long lists of crypto-currencies, with their names and call-signs

There seems to be two (BAT). Does anyone know if that is allowed?

I don't think you'll find a complete list since there are so many of them out there.  Some alt coins have changed their 3 character codes, some alt coins have used the same 3 character codes that had been used by a different coin in the past.
I've been keeping a list of my addresses on the spreadsheet below but this spreadsheet also lists a good number of alt coins.
https://docs.google.com/spreadsheet/ccc?key=0AsVWbj5CxfmHdGxmNmpycThjRzN6NUJtR0ItNnlBVUE&usp=sharing

nice work! and so nice of you to share this compilation with the world

The 3-call letters aren't standardized, all the alt coins are just modified protocols of the original Bitcoin protocol where differences can be as small as a different port. The 3-letters thing are just abbreviations people commonly use.


text:
Where can I find the bitcoind bundled with bitcoin-qt in Ubuntu?
I read that bitcoind comes bundled with bitcoin-qt, but I can't find it anywhere on my system after installing bitcoin-qt. I'm using Ubuntu.

If you start bitcoin-qt with the -server option, it also runs an RPC server, making it functionally equivalent to bitcoind.

They are two different things. If you want to install bitcoind you will need to install it
apt-get install bitcoind

But you can't run both at the same time, since bitcoin-qt is the same as bitcoind but with a nice interface while bitcoind is just the daemon.


text:
I'm in the UK, how to fund my account at mtgox?
It is getting ridiculously hard to get bitcoins in the U.K. International wires are to expensive, my bank doesn't support SEPA. I'm seriously thinking about converting ukash vouchers to cash u account, funding okpay with that. Then using that option at mtgox. There must be easier way.

I did a bank account thing with Blockchain.info. Assuming you have a UK bank account you shouldn't have a problem.

downvoting because there are no UK methods of funding the account in blockchain.info today :(

Lloyd's answer using blockchain sounds like the best if you haven't already bought the UKash vouchers.
If you do have the UKash, then an alternative is to deposit UKash at VirWoX, then convert to SLL, then to BTC. I just tried it. It was quick and easy, but I worked out that I ended up paying ~£5 in transaction fees on an original UKash value of £20, so its not very efficient.
There are also restrictions on VirWoX that you can only convert whole GBPs and you must buy a minimum of 0.2 BTC. There is a 15% deposit fee on UKash, which with £10 vouchers leaves you with £8.50 - 50p of which cannot be used because of the whole GBP restriction. Depending on the exchange rate the £8 might not be tradable if it is worth less than 0.2 BTC. (You may have guessed that I experimented with a £10 UKash voucher then had to go and buy another one).


text:
Is the realgg.nl exchange legit?
I was on a site www.realgg.nl last night, they have some attractive funding options for me because I live in UK it's difficult to get coins. (Well a lot more difficult than US). Just wondering if anyone knows whether it's legit.

Absolutely not - terrible exhange for any type of (crypto) currency.
DO NOT BUY HERE - you will receive your coins late (I received mine after 3 days of placing my order) AND they used the exchange rate of the day and time of the processing of the order - in other words I lost 60% of my purchase because they were 'having problems with their system' and took 3 days to deliver.


text:
How to download Bitcoin block headers from Blockchain.info and save to file?
I am just developing and testing Bitcoin mining application in plain Javascript
(slow but can be run off-line).
To test it to work correctly I need to download Bitcoin block headers
from Blockchain.info , 6 input parameters .
Are you aware how to call Blockchain API
https://blockchain.info/api/blockchain_api
I don't use Bitcoin address, no other mining app, just need to download
a number block headers from hashed blocks.
Any idea, demo, example or csv file coming with 6 input parameters
as described in Bitcoin hashing algorithm
https://en.bitcoin.it/wiki/Block_hashing_algorithm

ever thought of using testnet?

It might be easier to test (and more profitable to run) should you target an alt-coin rather than Bitcoin

You can download the blockchain headers using ElectrumX. The data is binary packed, but can be deserialized easily enough. You seem to be trying to solo mine, which is a bad idea at the best of times, let alone with JavaScript. You also seems to be trying to build a SPV client. An easier way would just be to use https://blockchain.info/latestblock to get the lastblock hash and use that.

Anyone have writeups on how to ingest the binary packed electrum data, or at least more info on what it is, exactly?

The data is the "block header" struct exactly -- https://en.bitcoin.it/wiki/Protocol_documentation#Block_Headers has the documentation.  It's a fixed-length binary struct described there.

https://headers.electrum.org/blockchain_headers is no longer found in DNS.
Is there a replacement?

@nealmcb https://electrum.readthedocs.io/en/latest/protocol.html#blockchain-block-get-header perhaps...


text:
What is the "Untrustworthy" tag on bitcointalk?
I just saw some people that were once labeled "Scammers" are now labeled "Untrustworthy" instead. Does anyone retain scammer tags, or was this a rename? Where was this discussed/announced?

People still have scammer tags.
"Untrustworthy" is technically different than the scammer tag - the latter is a forum position, which appears in a certain place and has a specific icon. In Matthew's case it is just a custom title, usually reserved for VIP donators who can write there whatever they want.
I suppose Matthew's tag was commuted as part of his rehabilitation process.


text:
Is there a way to access my BItcoins before Bitcoin qt syncs?
I used QT to generate an address, and have received some coins, but they're not showing up because it hasn't synced yet. It looks like syncing will take 2 days. Can I access the coins before then? Maybe dumping the wallet and importing with another client?

You can use any online wallet service that lets you import private keys.

Version 0.7.1 of the Bitcoin.org client supports a new approach to manually downloading and then importing blockchain data, through bittorrent.  And version 0.7.0 introduced -loadblock.  Those still won't make the load instantaneous but will at least be faster than the normal P2P network method.

Also, ultraprune (and LevelDB) is coming in an upcoming release of the Bitcoin.org client which will dramatically improve the initial blockchain download process and subsequent ongoing verification.

A a follow up to @StephenGornick, here is a torrent for a bootstrap.dat that will get you upto block 197,000: Torrent info hash: 0bb0521942f586ed96203c6f4d136324756f8a9a
Torrent magnet link:
magnet:?xt=urn:btih:0bb0521942f586ed96203c6f4d136324756f8a9a&dn=bootstrap.dat
Filename: bootstrap.dat
Byte size: 2491771562
SHA1: e70ca90775dfdb13fd0014425805a0bdf4a31677
SHA256: a3f258e7af030165360596e4cb0b9beb24b4ce97352c22e65349b89ad5fc5d3e

You can either import the keys into an eWallet that allows for that, or try taking your wallet to someone else who has a fully synchronised Bitcoin client. If you replace their wallet with yours (remember to make a backup!), the client should synchronise your wallet with the network and you will see your transactions. You can take the updated wallet.dat file back with you and use it until your Bitcoin synchronises.
Both of those options carry risk - in the first case you entrust the safety of your Bitcoins to a third party, and in the second case - to your friend. The risk could be mitigated (for example, encrypting your wallet will still let it be synchronised, but the private keys will be safer), but should always be kept in mind.

Blockhain.info offers a browser-based tool that will sync a Blockchain.info/wallet with your local Bitcoin-Qt wallet.dat (and vice-versa).
To use this you set up RPC on your client (bitcoin.conf contacins rpcuser=,rpcpassword=) and then run Bitcoin-Qt as a server (-server).
Then you use the browser plug-in (on Chrome, or the Blockchain verifier tool for Firefox or Safari) and perform a sync.
You can then spend the funds from Blockchain.info/wallet.

https://blockchain.info/wallet/demo-account#sync-bitcoind  <-- Demo account, don't sync with this wallet, ... use your own Blockchain.info/wallet when you do the RPC.


text:
What happens if I force quit a bitcoin wallet application before it finishes synchronizing?
I ask because upon initial install, this program (newest version) is PAINFULLY slow, and slowing down my system extremely, toward the end of the 6k block mark. I'm wondering if you force quit the application before it is completed, it will start all over again, or do something else.

The QT client at least should gracefully resume from where it left off.
I have done this many times with no issue (running a reasonably recent copy of the client in Windows 7).
I'm not sure whether the MultiBit or Armory clients work the same way though; can anyone vouch for them?

For MultiBit you should not need to force quit it in normal operation.  Saying that I have had to force quit it a few times and next time it started it just carried on syncing from when it left off. In the next version (0.4.11) I have added code to do a rolling backup of the wallet and better recovery if the blockchain gets corrupted. These are to cater for if the power goes suddenly but I imagine would also help with a force quit.

The client will continue downloading blocks from the last successfully downloaded block.
As far as database integrity when this happens -- BDB has crash recovery that generally works without any user intervention but doesn't accommodate a number of scenarios, so maintaining backups are highly recommended.
Here's more about BDB's recovery method:

http://help.bdbxml.net/html/ed539869-eebd-478f-97de-7e5377e87f66.htm


text:
What is the minimum transaction fee used for?
I have the bitcoin-qt client running on Ubuntu 12.10 and I see a transaction fee box in the preferences, but I am unsure of what it actually means - the wiki is overly complex, and I am unable to find another help website about this.
Can anyone give a easy to understand explenation of a minimum transaction fee. Do I have to pay it, or the sender? Etc.

Under Options of the most recent release, v0.7.1, reads:

Optional transaction fee per kB that helps make sure your transactions
  are processed quickly. Most transactions are 1kB.  Fee 0.01
  recommended.
Pay transaction fee: 0.00000000 BTC

What that field does is always add at least N BTC fee to every transaction.
When sending a transaction, the Bitcoin.org client will do a computation and insist on a fee to be paid if it determines the transaction will not be processed promptly unless a fee is paid.
Not all transactions require a fee.  If the amount of the payment is not small or the coins are not newly received (or both), then you can likely send a transaction using the Bitcoin-Qt client without paying a fee.
But there's always a chance that without paying a fee that your transaction will not be processed in a timely manner, as it is up to the miner or pool operator whether or not to include your transaction when mining.
So some people will use this optional fee field to make it so that every transaction goes out with a fee and thus no transactions sent will be delayed for the reason that no fee had been paid.
So do you have to pay a fee?   The Bitcoin.org client will generally tell you when you do need to pay a fee and when it does, then yes -- you must pay it or use some other client that doesn't perform this check.   But if it doesn't tell you to pay a fee, then you don't need to pay a fee but your transaction could still end up being delayed as a result.

Most people leave that value as 0.  Most transactions that don't require a fee go through in a timely manner.

There are people who need a transaction to be processed right away (e.g., doing a trade, in-person, where one confirmation is required before handing over the cash.)  For them, paying a fee regardless is prudent.

The sender pays the transaction fee.
The miner gets the fees for all the transactions it puts into a block. Adding a fee makes your transaction more attractive to the miner and hence encourages them to add it to the next block.
The complexity in the wiki is due to extra features such as anti-spam measures to prevent someone sending lots of transactions that move very small amounts around (commonly called 'dust').


text:
Is it possible to view others' transactions in bitcoin client?
This seems like a really basic question, but I'm having trouble searching for answers on it. My understanding is that my bitcoin client (Bitcoin v0.7.1-beta) has basically theoretically downloaded the entire transaction history of every bitcoin transaction that has ever occurred. I can see my own transactions in the Transactions screen. Is there a way to see transaction with wallets that I haven't imported or created on this client? I'm just trying to get a full understanding of bitcoin technology here. Is the reason the client doesn't show transactions from other wallets due to:

User friendliness - it would be overwhelming to have to search through all wallet addresses when most people only care about their own (is there a way to override that?);
Technical limitations - it's impractical to consider every transaction in the huge database when you want to list or look up some particular piece of information;
Design limitations - Not every transaction is actually there with all the information necessary;
Privacy concerns - By making it too easy to view others' transactions people would yell out about privacy more vocally;
Something I missed?

Is it possible to view others' transactions

Yes.

in bitcoin client?

No.

It's not terribly useful to look up the balance of somebody else's address, except maybe so they can prove they have a certain amount of funds.
These lookups would be slow, because it needs to work through millions of transactions. Creating the indexes that would allow you to do fast lookups on any bitcoin address would take a sizable amount of disk space.
All of them are there - it's a central part of the bitcoin protocol. What if somebody moves all of their money out of their account within a transaction you don't know about? Therefore, you have to know about all transactions, unless you want to be surprised when their payment "bounces."
There's already a website called Bitcoin Block Explorer that pretty clearly establishes that transactions are public. Even if there wasn't, you could still build your own.

Concerning #2, it sounds like you're talking about calculating a balance, but I'm not talking about looking up their balance, just looking up a transaction. For example, wouldn't it be useful to be able to use the system as a means of proving a receipt to a third party? A judge could award a case based on proof that funds were transferred from one account to another, neither of which the judge controls. Concerning #3, I'm referring to http://en.wikipedia.org/wiki/Bitcoin#Confirmations which talks about implementations where not all transactions are stored. #4 is a good answer.

It's actually quite easy to look up a transaction given its transaction ID. Use the bitcoind rpc call getrawtransaction 3. Electrum clients only store their own transactions and rely on Electrum server to not lie to them.

Adding to Nick's answer, it's worth clarifying that even though the entire history of transactions are available, there's no information directly stating which collection of addresses belong to a particular wallet. You might get some idea of that by looking at the inputs and outputs of transactions, but there's no "wallet id" (or similar) value in the blockchain.

It has become clear(er) to me since asking the original question that there is a difference between a wallet and a bitcoin address. I was interested in determining what transactions have occurred for a particular address. I'm only now realizing/suspecting that a wallet may contain many addresses.

Yes, that's correct. New addresses are added to a wallet as created by the user. It's easier to achieve anonymity if a new address is created for each incoming transaction, if anonymity is a goal of the user.

I have written a program in Python3 that allows you to search for any address on bitcoin core whether it belongs to your wallet or not.
Here is the github link:
https://github.com/ORP967/Bitcoin_Core_RPC_par_address
Let me know what you think or if you have any improvements you might have.


text:
How can I recover from a corrupted blkindex.dat on Ubuntu 12.10?
I've installed Bitcoin-Qt after a clean WUBI install, and installed Bitcoin-Qt directly. Now it suddenly says "Error loading blkindex.dat".
I assume my blkindex.dat file is corrupted, and I tried reinstalling Bitcoin-Qt with apt but it didn't work. Maybe if I delete the blkindex.dat file it will try to create it again, but I don't know where the installation folder is.
How can I solve this issue?
Extra information (added by other user); the error will likely look like this:
file blkindex.dat has LSN 727/2518588, past end of log at 727/1519938
Commonly caused by moving a database from one database environment
to another without clearing the database LSNs, or by removing all of
the log files from a database environment
__db_meta_setup: /home/user/.bitcoin/blkindex.dat: unexpected file type or format

You should be able to find this in ~/.bitcoin/db.log. This problem occured when interrupting the client suddenly or maybe because two of them opened the database at the same time.

I have this problem all the time. I just erase blk* but it will take 2 days long to download all blockchain again. I don't know why it is happening. I think it is a problem of the recent version.

Just run ./bitcoind -reindex and this will fix your problem.

On Linux, the Bitcoin client data is kept in the .bitcoin directory in your home directory. Go to ~/.bitcoin/ and you'll see the files in there. You may need to toggle Show Hidden Files in your file manager in order to see the directory.
If you remove blkindex.dat, the client will have to redownload the blockchain. I just tested this locally by moving my copy of the file to another file name temporarily - the client resync'd.
Since your copy of the index is corrupted apparently, it sounds like you need to delete it and resync.
A note: be careful to do not erase your wallet.dat. I recommend you back it up before. Your wallet.dat is your private keys.

To avoid having to redownload everything from the p2p network, which may be slow as you have to validate the whole chain, you can download the bootstrap chain file from bitcoincharts.com
It is also available through bittorrent, which may be faster for you. Here's a copy of the message posted above and in the forums that authenticate the file (through GPG).
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Torrent info hash: 0bb0521942f586ed96203c6f4d136324756f8a9a
Torrent magnet link:
magnet:?xt=urn:btih:0bb0521942f586ed96203c6f4d136324756f8a9a&dn=bootstrap.dat

Filename: bootstrap.dat
Byte size: 2491771562
SHA1: e70ca90775dfdb13fd0014425805a0bdf4a31677
SHA256: a3f258e7af030165360596e4cb0b9beb24b4ce97352c22e65349b89ad5fc5d3e

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iQIVAwUBUHeHSdodwg8tvwyoAQJ2DA/8CcINxuD7DzLv96fE+R6GVLvRASLcy0ig
8d2YyDbJ9r9dPVODDPGC7I/ooDVJAcQsqdrLYHST2DTCt6c4zZ/7iXzFEahRopsH
PmxYOgkHie7438nqpmH9uC+d5t0pPHUFS6dBSBgdSVPaLfS86fToXrV/bx30rHBi
60FJz5A99aXrrrUny0cGIjafqVv8XjqNoA1lzjsRjeiu3EgTm8Ibcr8ZI6DLp/80
Siv3potlOArTI6sxjc/vKUa6nZILnW8mKdwc/d8LUdRaBPoo71c6Q4YOSQh/OVht
B1rZ8NEX/2SlS3PbhhMELcY/2wvgPGovkIqOgiw6dDIkhsD8iJAD1DqCkZbsq9S1
kKobGmceuQBcyRUCavkafdHJpZzyCAKLnQLV3FvZ3O4QZQVmYGPYn1H8a5UFRDQq
LGKcQmwm4Cet7162woEiNAaR9p7HvTJ4LV2uEvY56m2GfZbToCk2aiycO+v6Fm8K
ZY8cX+cbEOW3AM5rYVa6Rks029LIrFFzIutlo5MJ7uc7oMqciWrcsPtEh59QY+yJ
SENk6cLyWCAHl4jsvUTBvdNGy3fHKSEyQOjG5cmAMXiJTX/iiB/DJf7koTZAj4ub
wez3/HwuenMYjHgjsVXJAXprcEpTjpEcicg4W0MIDw07dPjol0dnRRNpwfJ1HMRc
dlTqLwlXqgs=
=uwRB
-----END PGP SIGNATURE-----

Also, here's a magnet link that includes trackers:
magnet:?xt=urn:btih:0bb0521942f586ed96203c6f4d136324756f8a9a&dn=bootstrap.dat&tr=udp://tracker.openbittorrent.com:80&tr=udp://tracker.publicbt.com:80&tr=udp://tracker.ccc.de:80&tr=udp://tracker.istole.it:80

Finally, as explained in this answer, you can also simply discard the index and regenerate it using the existing ondisk blk000?.dat files, using -loadblock=blk0001.dat and by deleting blkindex.dat.
Edit: note that with bitcoind 0.8 and up, it's actually easier and faster to just download the block chain from the network directly, so don't bother with the bittorrent/manual download.


text:
How much time it takes to verify a Bitcoin signature in the Satoshi client?
Assuming:

An average modern computer
Using a single thread, as the current Satoshi client does
Using the OpenSSL library, as the Satoshi Bitcoin client does
The signature is not in the signature cache

I speculate that the time may be between 1 and 10 msec.

It depends a lot on the hardware, and on the architecture. OpenSSL use some assembly-optimized routines, which result in a speed factor of +- x2 between 32 bit and 64 bit (the latter is faster). That said, I've seen verifications taking around 0.47 ms on an Intel Xeon E5-1650 @ 3.20GHz, using 64-bit code.
Also, version 0.8 will actually do signature verification in parallel. There is also a patch with an optimized ECDSA verifier for the specific curve we're using, which should give a 20% speedup (discovered by Hal Finney). This patch will probably not make it into v0.8, though.

I instrumented the Satoshi client to see hwo long a transaction verification takes. This includes the signature verification, but is probably more of an upper bound as it also includes several disk seeks.

4500 Transactions. With the following percentiles:

50 percentile 5.0
75 percentile 10.0
85 percentile 15.0
95 percentile 36.0
99 percentile 207.27

While not at all representative it would point towards your estimate being correct.
Note: this was taken on a Lenovo T420 with spinning disks.

Just testing the digital signature verification using the OpenSSL code on a single core of a Core 2 Q9550, I get 725 microseconds per verification, a shade under 1 millisecond. This may be a bit unrealistic because all the ECDSA code is hot in the cache and the branch prediction is primed. (Test was doing verifications in a tight loop.)

The 0.8 code (unreleased currently) has a -benchmark function which measures block connection and signature verifications. You are certainly not just measuring signature validation.

Yep, I needed the benchmark for something else, where the whole processing time of transactions was more relevant.


text:
Do you have to pay taxes on Bitcoin revenues?
Disclaimer: this is not legal advice, and this varies from country to country.
If you accept bitcoins as payment, do you have to pay taxes on that? And would you have to write an invoice? Since they are not an official currency, such a trade would be considered a barter or what?
I.e. what's the legal status of someone accepting bitcoins as payment, and what is him required to do?

Regarding paying tax in the UK there is a form thread here: https://bitcointalk.org/index.php?topic=143425.0

Would be better suited as a comment to this answer: http://bitcoin.stackexchange.com/a/2785/196

I'm voting to close this question as off-topic because it's a jurisdiction-specific legal question.

In Denmark (Europe) I have looked into this with a friend of mine, and we came to this conclusion.
Here, you will have to pay tax and do an invoice regardless of the currency. It is trade taking place within Danish borders, and therefor tax applies.
Although, these are rather old laws, and not very well updated. For example, a trade between two Danes going through a PayPal service, should technically be treated as a foreign trade, since the payment leaves Danish borders.
But modern day lawyers have no need to go after this, and as far as I can tell, no one have ever been "caught in trouble" with the legislation like this.
A interesting ruling was that the Danish tax authority once started creating accounts inside the game Second Life, and demanded tax cuts on the currency, even though it was "fictitious" and digital...
Although, they did not have much success with this.

So you would have to pay actual bitcoin to your government, according to that law?

That was our conclusion.

@NilsMunch How?

We pay a local currency equivalent to the current bitcoin value.

@NilsMunch what exchange rate do you use?

Actually the payment between two danes is taxable irrelevant because the contract counts, not the money flow. So 2 danes with paypal is still 2 danes. Paypal is never part of the taxable legal contract.

In the United States, I believe you can treat Bitcoins held as commodities and Bitcoins traded as like-kind exchanges.
Your tax basis in your Bitcoins is the fair market value of whatever you gave to get them. So if you buy some Bitcoins for $50 and then sell them for $75, the $75 is taxable income. You can deduct your $50 tax basis.
If you buy or sell something for Bitcoins, that's a taxable exchange. Business can defer the taxes (under IRC code 1031).
We're pretty much all just guessing though. If you plan large transactions in Bitcoins, I'd recommend getting a written, legal opinion backing up your planned tax treatment for the transactions. Failing that, at least have a tax professional prepare your taxes.

What do you consider "large"?

Large enough that the amount it affects your taxes is sufficient to trigger the IRS policies on "substantial understatement of income". Essentially, 25% of your gross income.

I recently (as in April 18, 2013) asked the Swedish Tax Agency how they view Bitcoins.
This is the answer I got (the original swedish answer is at the end):
--- ENGLISH TRANSLATION ----
I short, Bitcoin is not considered a currency, but rather a commodity. Taxation on the commodity value is 30%. You you create bitcoins and the sell them, you make a capital gain equal to the value of that commodity on the market (if you buy a comodity, the capital gain is that commoditys market value). The tax basis is zero and the entire gain is taxable.
If you bought bitcoins then the cost equals the amount you paid for them. If you sell for more vaule than you bought, you make a make a capital gain on the difference. Correspondingly, you make make a capital loss if they fell in value.

---- URSPRUNGLIGT SVAR ----
Sammanfattningsvis ses bitcoins inte som en valuta utan som en vara. Beskattning sker i inkomstslaget kapital med en skattesats om 30%. Om du själv skapat bitcoins och säljer dem gör du en kapitalvinst motsvarande ersättningen (om du köper en vara är vinsten varans marknadsvärde). Omkostnadsbeloppet är noll och hela ersättningen är skattepliktig.
Om du köpt bitcoins är omkostnadsbeloppet det du betalat för dem. Får du en större ersättning när du avyttrar dem jämfört med ditt inköpspris gör du en kapitalvinst på mellanskillnaden. Motsvarande gör du en kapitalförlust om de sjunkit i värde.

Then, if you mine them but do not sell them, no tax incurs? This might be implied in this answer but I'm not sure.

That is also my interpretation of the answer I got. Make sense, since from the Tax Agency's point of view you are doing nothing but letting equipment waste electricity. "Stupidity" is not taxable on Sweden, for now...

Wow 30% tax! That is insane. I guess you pay through the nose for that welfare state you got running.

What if you buy/sell in exchanges in other countries? Still should pay taxes in Sweden?

This applies to the UK and is not advice.
My opinion is that Bitcoin is not recognized as a currency, but may be recognized as an asset with a non-zero value. So you should pay the kind of taxes associated with assets.
Example: you buy BTC with GBP, the value of the BTC increases, and you sell it for GBP, making a profit. You pay capital gains tax on the profit.
Example: your employer pays you in BTC. This is a benefit-in-kind and you pay income tax on it.
Example: somebody gives you BTC. You may pay inheritance tax on it.
Example: you sell goods or services for BTC. This is bartering. You pay income tax on the fair market value of the asset received.
Good luck to HMRC collecting though...

Just thought I'd add that this is roughly equivalent to the current tax law in the U.S. - since BTC isn't legally recognized as currency (at least not yet) the same basic rules apply as if you'd traded gold, silver or stock certificates.

In the UK though trading on markers (such as spread betting) is considerd gambling and taxation does not apply.

I spoke to my tax advisor, and he said that here in Italy likely they should be treated like commodities too.

as of 2017 here is IRS answer on Currencies vs taxes:
https://www.irs.gov/pub/irs-drop/n-14-21.pdf


text:
Is there a way to not pay the transaction fees when using the standard Bitcoin client?
I tried sending one satoshi (0.00000001 BTC) to one of my friend and the client always showed a dialog prompting me to pay 0.0005 BTC in fee, with the only options being OK (pay the fee) or cancel (cancel the transaction). The transaction was using one input and possiby two output (with how the clients jungle with the addresses).
I checked the option and the fee was at 0.00000000 BTC, but the client would not let me placed the transaction.

also, be aware that you will not be able to send 0.00000001 BTC...please take a look at the following question regarding "bitcoin dust": http://bitcoin.stackexchange.com/questions/10986/what-is-meant-by-bitcoin-dust

The standard client, as distributed by the Bitcoin developer team, does not permit transactions without a fee for amounts less than 0.01BTC. It adheres to the fee calculation suggestion in the transaction.
That said, not all clients enforce this rule. See Can different clients have different transaction fees?

In certain cases (either too large in bytes, creating very small outputs, or using to small/recent inputs), the reference client considers feeless transactions as spam and does not relay them. To prevent transactions from getting stuck, the client will force a fee under those same conditions (mostly because it doesn't deal well with non-confirmation transactions). In the normal case, free transactions are not a problem.

Yes that was the answer I was looking for.

Yes, however the answer is a bit more advanced than for your everyday consumer:
It is recommended to have some knowledge of JSON if using this method
WORD OF WARNING: Using this method can cause large amounts of inputs being set as miners fees. I suggest you continue with caution and start by using small inputs.
That being said...
A transaction must be compiled and submitted via the bitcoin-qt console using the commands listunspent, createrawtransaction, signrawtransaction and submitrawtransaction.
To access the Bitcoin-qt console:
launch your bitcoin client as usual and wait for it to load the blockchain and start up
click on 'help' in the menu bar (top right)
click on 'debug window'
select the 'console' tab

Use listunspent to get an array of you spendable inputs in your wallet
This is where you set you transaction fee: Use createrawtransaction to generate a transaction in the form createrawtransaction [{\"txid\":\"[txid of the input transaction]\",\"vout\":[vout that relates to the txid of the input transaction]},...] {\"[address to send your bitcoins to]\":[amount of bitcoins to send to this address],...} If you want a no fee transaction you must make sure all inputs equal the output. All inputs that are not spent in a transaction are used as miners fees.
Use signrawtransaction [the output of createrawtransaction] to sign your generated transaction Note: Your wallet must be unlocked to perform this command. If not type walletpassphrase [your passphrase] 21600
Use submitrawtransaction [the output of signrawtransaction] to send your signed transaction to the network to be included into a block

You can see your transaction by going to http://blockchain.info/tx/[txid output from submitrawtrasaction]

Maybe this was added recently, but I don't think so. You can change the fee in your Bitcoin Core client settings. Go to:
Settings -> Options -> Wallet (tab) -> "Pay transaction fee"
set it to 0 and you're good to send fee-less transactions. Keep in mind it may take longer for your transaction to be pulled into the blockchain without a fee.

Recently, feeless transactions might actually never go through : ( - We've gotta wait for this blocksize debate to be decided to go back to good ole free transactions.

Today, we cannot do transactions without any fees. Miners wouldn't choose to include such transactions and the Bitcoin clients also drop these transactions.
We could do as the following article suggested to minimize the fees level: http://coinour.com/index.php/how-to-minimize-bitcoin-transaction-fees/

Thank you for adding an updated answer to an old question, your answer would be more helpful if it included a summary of the relevant information from the linked page, and thus went over the bare minimum answer.


text:
Are there any countries which currently block or plan to block Bitcoin?
Are there any countries which currently block or plan to block Bitcoin? If anyone has enough reputation to edit this, maybe add "censorship" or maybe "freedom" as a tag because i can't.

I changed the tag to "legal" which is a tag that has been used quite a lot already. "Block" really refers to something else so I removed that tag.

It seems that Charles Schumer (D-NY) and Joe Manchin (D-WV) of the U.S. senate sought a law criminalizing it back in 2011. Guess the media moved on and the law stalled.
There are also countries like Venezuela, which criminalize exchange of a 'foreign currency', under the Foreign Exchange Crime Act. Essentially, this is so they can pretend that bolivars are worth more than they really are.
Now, is bitcoin a 'foreign currency'?

“Foreign Currency:  Any currency, whether in coins, bank notes, bank checks and in any form, other than the bolivar, the latter being understood to be the legal tender in the Bolivarian Republic of Venezuela, as well as securities denominated in foreign currency or that can be settled in foreign currency.”

Technically, yes.
Source

Currently there is no known incident of bitcoin blocking.


text:
Wallet versus client machine
Can I store my wallet on one machine while running the client on another?
I'd like to help the p2p aspect of the network by leaving a dedicated machine connected...

Here's how I understand your question: You have a spare computer that you'd like to run bitcoin on to help the network. You have a second computer that is your main personal computer; it's also where you'd like to keep your bitcoins. Two copies of the blockchain would waste bandwidth and disk space.
There is a way to keep the blockchain on one computer but to keep your coins on another - you can run the electrum client, and the normal bitcoin client on the other computer. Optionally, you can run the electrum server on your always-up computer, although this requires some command-line knowledge.
https://github.com/spesmilo/electrum-server/blob/master/HOWTO.md

The wallet functionality and peer-to-peer node are not very tightly dependent, a node does not require a wallet to store the chain, validate and propagate transactions.
A wallet is basically just a keystore (and a list of available unspent outputs).
Your question is not very clear though, do you want to leave your wallet on another machine for security purposes? In this case you might want to switch to a wallet like blockchain.info which might be more practical.


text:
Is Bitcoin a fiat currency?
I often encounter articles where we talk about bitcoin being a fiat currency. What is a fiat money and what is it that bitcoin as to be considered a fiat money.

Fiat money is money that derives its value from government regulation or law. The term fiat currency is used when the fiat money is used as the main currency of the country. The term derives from the Latin fiat ("let it be done", "it shall be").

So bitcoin would be fiat money because it derives his value from his own rules?

@Gopoi, yes. Bitcoins are fiat money.

@Gopoi No. Fiat money is money that receives its value through the decree of an authority. No authority decrees the rules or value of Bitcoin.

N-O.  Just like @David says, fiat is a decree.  Bitcoin is floating based on supply and demand.  It only becomes fiat when you exchange it for USD or Euro or CAD or any of the other fiat money systems.  Until then, it is a possession, like gold.


text:
What precautions should be taken to protect a Ripple wallet?
What if a Ripple wallet gets hacked?
What are the suggested precautions for the average user?

@CharlesHoskinson: Andreesen recently invested in OpenCoin, but neither he nor anyone associated with him played any role in the development of Ripple. It was "conjured" by Jed McCaleb (the original founder of MtGox) and three Bitcoin software developers (including myself).

What precautions should be taken to protect a Ripple wallet?

You can keep your wallet offline most of the time. See this. You'll need to go online to check your balance or spend.
Beyond that, I'd also advise you to only use the client while online with that computer.
For Bitcoin, you can keep your wallet airgapped permanently with Armory, but I don't think there's an equivalent solution for Ripple.


text:
What is "failed to read block" and how can this be fixed?
When I try to open my BitCoin wallet, I get a "failed to read block" message and it will not open. What does this mean and how can this be rectified?

Client and version?

I downloaded 0.8.0 for Windows.

This helped me: http://bitcoin.stackexchange.com/questions/10295/bitcoin-qt-read-block-error


text:
Bitcoin wallet not syncing
My bit coin wallet sync is stuck, if anything the blocks remaining is increasing.
It is not my computer or network because I have another wallet on a different hard drive and that wallet synced in a day, but the problem wallet has been syncing for many many days.
The bit coin I have bought has not yet appeared in my wallet, so what are my options? I cannot transfer the purchased bit coin  before it appears in my wallet.

This question lacks sufficient information to enable any decent answer. As the question is several months old the user probably has already resolved his issue and it is doubtful that the question will be provided. Voted to close.

lannot access my bitcoins because my wallet is still synchronising. What can I do to retrieve them?](http://bitcoin.stackexchange.com/q/6056/5406)

First, a bit information about the underlying OS, bitcoin client config & hardware would be nice. Are you using a virtual environment?
The delay / increased time on the sync problem is hardly to evaluate without this information.
How long is it stuck? How long have you been loading? How much GB have you already loaded?
First thing to check would be the connection, are you using UpnP or forwarded porting? How much bandwidth do you got? Is there a firewall in the way? Ports on switches/virtual environments?
If thats not the problem maybe IO is it. Right after that i would check if hte cpu is running hot.