Ahh, I thought you were trying to connect to your local node.  If you are joining a pool, you need the worker name and password for that pool, along with the host and port.  The thread for the pool you are using should have the host (aka server) and port information.

In some pools, you sign up with a username and password, then you use the same to connect your miner.  In others, you create one or more workers, with their own username and password.  In others, you specify the payment address in the username, and use a generic password, like x.

Oh, and I've never used guiminer, but there are two ways to specify the four things you need to connect.  One is setting each one by itself, the other is by packing them all into a URL like this:  http://username:password@host:port/

I don't know which form guiminer takes, but as you can see it is easy to convert from one form to the other.

A miner gets a header and starts working on it by running through all of the possible nonce values.  This can take a few seconds to several minutes, depending on the hashing speed of the miner.  If it finds no valid hashes that way, it reports back to the node.  Or, the node can tell the miner to stop, assuming both ends support long polling, by sending out a new header before the miner is done with the first one.

If the miner asks for a new block because it exhausted all of the possible nonces, the node will update the Merkle root hash (by allowing in new transactions, or by updating the nonce in the generation transaction) and/or the timestamp and send it out again.

If the miner was interrupted by a long poll, it usually means that the node heard that someone else got a valid block, so the new work will have a different "last block hash", and the transaction list will be totally different, giving a new Merkle root hash, and the timestamp will (likely) be different.

So, no, the miner doesn't really need to know what it did before, because it will never get that unique combination of bits again.

Here is the procedure to make sure that your wallet never gets out of sync with the block chain:

1) Shut down node on computer A
2) Copy wallet data from computer A to computer B
3) Start node on computer B

In general, you never want both nodes running at the same time, and you never want a block cache on a node that is newer than the wallet files.

If you can do that, your file sync should never screw up your balance.

Cloud backup should be fine.  Just make sure it is encrypted.

Oh, and you should probably join a pool.  If you are just getting started, the odds of you getting a block by yourself are pretty bad.  I think that getting struck by lightning and having it incinerate a winning lottery ticket in your hand while leaving you untouched is more likely at this point.

Thank you so much for this wonderful analysis.

I was just thinking that we really need someone that knows neither bitcoins nor economics to start yet another thread about how wrong we all are for letting them get started too late to get a bunch of free coins by mining.

You need to edit (or more likely create) a bitcoin.conf file to set a username and password that your node will allow to connect.  It goes in %APPDATA%\bitcoin\ (on XP, this is C:\Documents and Settings\YOUR USERNAME HERE\Application Data\bitcoin\ ).


That should get you started.  If you aren't behind a NAT box on private IPs, change rpcallow to the one IP that you are connecting from, or the subnet.

No, please don't think of the wallet as a physical wallet.

No one owns any bitcoins.  What they own are private keys that control bitcoins that exist in the block chain.  That is the important part of your wallet.

If you toss your wallet files around carelessly, your node will get confused.  The good news is that this usually only means that it'll show the balance wrong, and there are ways to fix that if it happens.  The bad news is that your node can try to double spend if the confusion is in the wrong direction.

If you are curious, the displayed balance is the sum of the bitcoins in the block chain that have been assigned to keys that are in your wallet, and haven't been redeemed (assigned to another key).  The node doesn't rescan the whole chain every time it starts, it keeps a running balance, and the id of the last block it read.  If you grab the wallet files from a node that last saw block # 1000, and put those files on a node that has seen up to block # 2000, any transactions in nodes 1001 to 2000 that correspond to keys in your wallet won't be counted, and it will show you either too many coins, or too few.

Yes, totally normal.

The standard node client isn't impressed unless you've got a valid hash that meets the current difficulty target.  For most people, this will be never.

The pools, however, accept hashes that only meet a much easier target, so that they can allocate shares to the miners.

Shit, I missed something.  We started by wanting to lock the price of every product in the entire world into a fixed price for all eternity.  Then there was a digression into anonymity and double spending.  Now we've invented the website shopping cart with online payment processing.  Were the intervening steps in other threads or something?

Well, with regards to the shopping cart and payment processing, this is like the twentieth thread I've read in the last week where someone felt obligated to tell the world that they discovered that a third party was necessary to assume the risk if neither party to a transaction is willing to keep it.  On that point, you are totally correct.  There is no rollback for bitcoin payments (yet).  When you hit send, you are making an irreversible donation.

ZOMG!  Economics isn't perfect!  Everyone run for the hills!

It is completely true that supply and demand in real life don't look like the idealized abstract charts in economics books.  Also, real atoms don't look like the little solar systems in physics books, and molecules don't look like the stick figures in chemistry books.

However, any supply that is not unlimited must be allocated in some way.  There are many possible ways to allocate a scarce good.  Here are just a few examples:  You can use a lottery.  You can use rationing.  You can use a queue.  You can use merit.

All of those tend to turn into allocation by corruption, by the way.  And they virtually guarantee that resources are not allocated to those who can best make use of them.

Which brings us to allocation by price.  Sure, the curves in real live aren't neat and clean, and no one really knows the exact level of supply, nor of demand.  And pricing isn't exact.  But everyone tries, and for the most part, we do a pretty good job of it.

Ask your parents about the gasoline lines in the 70s if you are wondering how well non-price allocation systems work.  The Law of Supply and Demand isn't perfect in the real world, but it is wildly better than every other method anyone has ever tried.

fpgaminer has it right except for one tiny detail.

The block of transactions is built first, because the merkle hash of all the transactions is included in the header that the miners work on.  Also, the node will add newly arrived transactions to the block periodically.  Oh, and the node could give totally different blocks out to different miners if it wanted to.

There is a key detail that may not be obvious, but is crucial to understanding the mining process is that there isn't just one true next block that every node is searching for.  Every node is searching for their own unique next block that meets the validity criteria.  Their unique block includes the address that gets the mining reward.

Erm...

Did the price of everything else fall too?  Or was it just bread?

If it was just bread, that is the market telling you to stop baking.  If it was everything else too, you are just fine.

Ahh.  My tax dollars at work.

I wouldn't consider it "safe" enough to tell a stranger on the internet to do it, but I've done much worse things with electricity and both me and my house are still here.

If you do it, you should run a decent sized copper wire between the two supplies.  Personally, I'd use 14 or 16 gauge wire with properly crimped ring lugs on one of the power supply mounting screws on each case.

A ground loop is very unlikely, but why take chances?

Is it really so hard to open a spreadsheet and plug in the numbers that no one can do it themselves?  How many of these threads do we need?

The client caches the block chain.  You'd only need to download the new ones.

You mean like the dollar is stable because it is anchored to the...  Or the way the Euro is stable because it is anchored to the...  Or the way the Yen is stable because it is anchored to the...

Well, shit.  I guess nothing is anchored to anything.  Hint:  currency stability comes from depth, not unicorns.

Deflation is never a problem.  Even when it is quite severe.

I'm pretty sure Keynes never drank alcohol.  If he had, he would have known better than to blame the hangover for the previous night's binge.

Well, sorta.  Fooling the chain is neither as easy nor as useful as popular imagination makes it seem.


Yes (but that "person" might be a pool, and pools can set their own policy for fees).

I'm almost certain that you have something you want to say here.  For the life of me, I am completely unable to determine what that might be.  And I read the whole thing twice.  Most people won't be able to say even half of that.

Can I have my 5 minutes back?

Oh, and you are wrong about pretty much everything, notably the stamps part near the end, and the debt part throughout, and the box.  And most of all, you are wrong about value.  Oh, and the technical details behind how and why bitcoin works (to the extent that it works at all).