11.6 (original, not 11.6b release) seems to work the best for most. If you have a multi-core CPU, you can force all your miners to run only on the same single CPU core by forcing CPU affinity. Here's a batch file that starts my miners as an example (if you are on Windows):


The affinity setting is actually a bitmask in hex, 01=CPU0, 02=CPU1, 03=CPU0+CPU1 etc.
I am also running Phoenix from source, not the binary, so correct the exe above if you are the other 99%.

It sounds like the solution you ask for, using your Bitcoin addresses on another computer, isn't really the problem you are having. It sounds like you don't have the complete blockchain downloaded yet. If you moved to another computer, you would have to start downloading from the beginning.

Here is a thread of interest to you: http://bitcointalk.org/index.php?topic=51456

If you do want to move all your bitcoins and account info to a new computer, the file to copy is %APPDATA%\Bitcoin\wallet.dat. Put it in the same place on the other computer (using the appropriate user name), and run Bitcoin.

Why does noob double-post the same question, and then never log in again...?

For the same reason they admit the same question they are asking must have been asked a million times, but they can't be bothered to search for even one of those previous answers.

Just a note, if your computer is spontaneously crashing or rebooting, then you likely have a hardware problem. I wouldn't store my money on such a system until it is fixed.

If the computer is fine until you run the CPU hard for a while (such as processing downloaded Bitcoin blocks), it could be a hardware fault as simple as a bad CPU fan. Download and run a burn-in stress test like OCCT on your computer overnight. The power supply test in this program will work your system hard, and likely crash it if there is a problem.

I have found a concern relating to Bitcoin (all versions) on Windows on an active directory domain member.

The Bitcoin data directory is under %APPDATA%, an alias for CSIDL_APPDATA. On WinVista and Win7 this typically resolves to "C:\Users\{logon}\AppData\Roaming", on Win2000/XP to "C:\Documents and Settings\{logon}\Application Data".

The problem this presents is that this folder is used for roaming user profiles. When logging on to a domain that uses roaming profiles, the entire directory is synchronized with the server. This would mean sending up to 1GB of blockchain between the server and logon computer before the user can use their station. Admins may also opt to have the entire profile be a user network share without local storage.

In addition, this means that the private wallet data is stored on both the logon computer and the server. If the user logs on to another network machine, the user profile is then completely copied to the second machine. This also means anyone with "power user" rights can read the profile data on the second machine. This becomes less of a concern with an encrypted wallet, but you are still spreading your Bitcoin data anywhere you log in, with a copy for the admins to read too.

Windows Vista/7 have lessened the data transfer concern with the addition of %LOCALAPPDATA%, "C:\Users\{logon}\AppData\Local" typical. This is non-roaming profile data, used for caches, temp files, the entire install and user data of Google Chrome, etc. This seems like a more appropriate location for the Bitcoin data directory. For Win2000/XP/Me, the analogous location is C:\Documents and Settings\{logon}\Local Settings\Application Data, but XP doesn't have the environment variable. Here are some XP methods to determine the directory.

In this line of examination, one might wonder if it isn't appropriate to take all program data except the wallet out of userland. If Mom, Dad, and little Billy all use bitcoin with their own computer logins, there doesn't need to be three complete blockchain downloads. The program data could be moved to CSIDL_COMMON_APPDATA (C:\ProgramData), and the user data could be only the wallet, and perhaps a 'last_block' counter file that indicates for a rescan for any wallet transactions after the user's last seen transaction block; forces a complete rescan if the counter isn't present...

I don't know how a demonstration can be verified. When Steve Jobs unveiled the original Macintosh computer (64k), the demo unit that was up on stage was actually a one-of-a-kind 128k prototype, and the demo used all it's memory. The "$500" demo unit could have $1000 worth of FPGAs on it, or the miner source could have print "hashrate:", hash_rate*2, etc.

The u-wash-it car wash I go to issues tokens out of their change machine. Actually, their machine is loaded with a mix of quarters and tokens, so you don't know what you'll get. I can redeem those later for car wash service, or trade my extras at the car wash to the next guy that comes in. Time for a crackdown!

Giant douche:


Who is it? How about Tycho (deepbit pool admin). Lets analyze:

-Makes 3% (for proportional) or 10% (for PPS) on half of all the bitcoins mined,
-keeps all of half the transaction fees seen on the network,
-deepbit thread started June - ~150 days ago,
-hasn't logged into forums for two weeks (disinterest?)

Lets call it a conservative 2% of all bitcoins earned: 144 BTC a day x 100 days. 14,400 BTC. Nope, that's not enough to account for midnight dumping (35,000 in an hour).

Who else has the coins to sell? Art, Vlad, Tux? Mystery bubble sucker? Likely not "Satoshi", early coins have never been touched, so aren't on an exchange (unless the exchange has the whole wallets. It's feasible, since everything seems to start at Satoshi.) Is the seller awake in Japan?

Good luck with that one! Even if you were deepbit, the nonce is randomly created by all mining software and is not 'forceable'. You would have to write a custom pushpool and custom mining software that would move the 'noncing' into the coinbase or such, and have Thash/s, to even have a whimper of a chance.

256 tickets and the last two digits of the hash then.

Bitcoin has a random number generator that is not falsifiable and is widely available for all to verify. What you do is, say: ticket numbers are 0-499, winning ticket matches the last three digits of the nonce of block 155620 - (2016 blocks from now, should be ~14 days/Nov 30). Subtract -500 from nonce if last three digits over 499. Or (nonce)Mod(number_of_tickets) for an arbitrary number of tickets.

{
  "hash":"000000000000052292e0b44756ec93c37d9fa4e974c82b10f205cedfc241986b",
  "ver":1,
  "prev_block":"0000000000000434485ebbffcde54b1870c9598f2d5e50b3859770282a15d690",
  "mrkl_root":"2b537a8fec565e7ff4e1a535becb17f5edee621c01f15bfa3361b0041a43ddf1",
  "time":1321483525,
  "bits":437129626,
  "nonce":958058163,

Then people need to actually know what "ticket number" they got, a receipt should be digitally signed by raffle holder and include the number(s) and address that a winning payment would be sent to if won, so any claims of nonpayment can be verified as legitimate. The public key of the raffle holder should be held in an immutable location.

Then there is the "I sent payment but never got a ticket", or "raffle holder disappeared". Someone looking to exit the community with some profit could pocket everything and disappear if the the balance is not held in escrow (see mybitcoin.com).

I have been getting the JSON pool stats from bitcoins.lc every minute for the last four months, with a little stats scraper program I made. It appends the data to a CSV file. If you want to investigate a pool's stats for four months of mining, here you go (17,283,823 bytes CSV, 151,502 lines, 7-zipped to 1.17 MB): http://we.lovebitco.in/lc.StatsLog.138077-152915.7z

Data looks like this:
Date,Time: my local time UTC-7 and -8
round_started: unix epoch time in JSON

Note: a new round announcement is delayed in an odd way, stats keeps counting up shares as though they were contributed to the previous round for 1-3600 seconds. For analysis, you might need to use the block found time and recalculate the delayed stats.

It's an unlinked-to page on a certain .lc domain pool's website.

Looking at the hashrate graph from earlier today, it looks like the pool was down for ~1 hr. Only Wuked would be able to answer this, and he hasn't checked this forum for two months (although he can occasionally be spotted in #mineco on freenode IRC).

How about a team of the the best hitmen and attack the shit out of the Bitcoin community...seems to work for lots of governments.

Or to roll that back, a team of the the best government lobbyists and attack the shit out of the Bitcoin community

This auction is over, I want to hear that Matoking got paid his 3.9 BTC. The only other bid from Cory doesn't qualify, his snipe bid was a second too late, and there was no second-place bidder. We could also call shenanigans, by rules (bid increment, end time) being added/changed mid-auction by OP.

PPLNS systems, as long as they cross rounds (which all do, there is no concept of pool rounds when distributing payments) are all fair payout methods that do not positively or negatively affect the part-time miner. Since the work you submit now determines your percentage of reward on future blocks until the work expires, you don't know when blocks will be found, and past block finding doesn't affect future payments, all contributed shares have equal expected value.

I think it may be possible to game 'decaying' value pools or get a different average reward than you deserve when part-time mining, which is non-ideal. Lets say you have three different accounts on one pool, and switch between accounts every hour. It would seem that under an exponentially decaying reward or other custom poorly-informed formula (don't know if any pools do this) your expected reward may be different than constantly mining one account. Just thinking that 'pulsing' your hashrate (intermittent mining), may get you more or less expected reward than constant mining, depending on the decay rate, when we want every submitted share to have the same expected return.

Upon reflection, it seems like the second paragraph's concern is also unfounded. As long as each share's value is independently evaluated, it shouldn't make a difference. If a pool has some other policy, like "if you leave for three hours your reward is cut in half", this would "connect" the value of shares you submit now to future shares you submit.

Just a bump, the pool is still running great, I am about 1% of the pools hashrate, and I get my ~.50 BTC every time a block is found, averaging about one a day. Big props to megauser boom, who found four blocks in a row with ~15GHash/s. My signature link is not because I am affiliated with the pool admin, just because it works!

I suggest that you look at a pool's guide to mining. Your mining computer runs software specifically for mining Bitcoins. You contribute work to the pool, and as the pool finds blocks, your account balance at the pool goes up. You can withdraw the bitcoins you've earned from the pool when you want, or you can set it up for automatic withdraws. You withdraw the coins to your own personal Bitcoin address, which can be Bitcoin running on any computer you want; you don't need multiple wallets or anything like that.

It depends more on what you are selling. Since Steam accounts were hacked, and buyers have already reported getting burned off stolen accounts, those are as poisonous as calling cards or offering PayPal for Bitcoin. If you are selling some material goods that cannot be hacked by Russian mobsters, then the chances are much higher of you being trusted.