One situation this does not address is the bit-hopping effect itself. If 100ghash hops on and off 100ghash pools, the early shares will be go by twice as fast, meaning there will be less cheating time than predicted. All pools will spend more time in the > .43 difficulty range; lowering the chance of there being a pool to hop to with share earnings higher than backup.

If you disable backup pooling or set backup threshold really high, you will essentially be hopping at a random threshold. A new round could start at a new pool when your current least-share pool is at 10% or 300%.

I assume you are giving each pool a table of random block find times (randomly generate a high-precision round percentile 0% to 100%, turn that percentile into number of individual hashes required using correct math, turn that into times using hashrate), and then are simulating the switching and share percentages earned. I too am curious in your simulation, how much time is being spent mining beyond the "optimal" range, say if the threshold was 1.8? Could you run a histogram with difficulty switch points for your six-pool example, so we can visually see how long we spend in proportional rounds. I'd be interested how long they actually tend to go.

For more interesting real-world factors to model, analysis could be biased with a 'pool hop-in' time delay (like jumping 5 minutes after block find), and a 'wrong pool hop error rate' that reflects what people are seeing with early block-detection methods, when they get incorrect blockfinding because they aren't getting info from the pool that actually found a block, and jump to a false-positive.

The relevant search gives poor results, displaying newest posts first in a search would be more useful.

I suppose the question to mull over is how did root get ownership of this file in the first place, did you start bitcoin in single-user mode during recovery perhaps?

-rw-------    1 tc       staff    207921152 Aug  8 08:09 blkindex.dat
-rw-------    1 root     staff    425711616 Aug  8 06:53 blk0001.dat

The permissions are on the left. They are
(1): (-) normal file
(234): (rw-) Owner can read and write (but not execute as a program)
(567): (---) Other members of group cannot read or write
(890): (---) Non-group members cannot read or write

It seems that the owner was changed on the file, but not the group. You can do one of two things, either give permission for all group members to be able to read the file, and/or change the file owner back to tc.

To change the owner, you would use the chown command like so:

sudo chown tc blk0001.dat

Not to thread crap, but let me thread crap.

There is not much to "getting set up with a wallet". Download, install, and run the Bitcoin client software on your computer. Let it think for a bit. You now have a wallet. You will see your first payment address for receiving Bitcoins in the client main window. Shut down Bitcoin, and backup your wallet.dat file to a flash drive, in case the hard drive on your computer crashes, etc. You tell people your Bitcoin address, they can send bitcoin payments to you instantly.

PayPal and credit card payments are only accepted by the foolhardy or overly trusting. Whereas Bitcoin payments can never be reversed, disputed, or counterfeited, PayPay and credit card payments can always be reversed or disputed, or can be stolen accounts. You could find a local Bitcoin money changer in your area, someone willing to immediately transfer you Bitcoins for cash-in-hand. There are several web sites for finding local contacts. Most other ways to get Bitcoins require time (sending verifiable funds to an exchange, pool mining them with your ATI graphics card), or require trust or reputation (selling items for bitcoins, you must be trusted to send the item, etc.)

A much better investment in the long term would be to not use your credit card to purchase things you cannot afford.

Shares can be rejected by a pool if you are not submitting with proper worker authentication credentials. Also note that it is best you use a different pool worker login for each miner software instance.

Grab guiminer to start with, and use it's built-in ufasoft miner by picking new->cpu miner. Put your worker info there and mine away. If that works, than it is cgminer, or the way you are using it, that is the problem. Then stop CPU mining unless someone else is paying the electricity bill.

It depends on if you are one of those people saving their silver for the collapse of society as we know it...

pro-bitcoin:
Bitcoins can be instantly sent around the globe. Silver, not so much.
Bitcoins cannot be counterfeited. Is there a touchstone for silver?
Bitcoins can be quickly changed for other currencies. Where do you take silver at 3am?

pro-silver:
You can't press 'delete' on all your silver.
You can make shiny things out of silver.

If we just consider silver an asset you can use to buy computer hardware, and bitcoins an asset you can turn into paper money, the above doesn't address your main questions, which are:

1. Is mining bitcoins a good return on your investment?
You may eventually pay for your computer "shovels" used to mine, or more. You may barely pay for the electricity you use. You at least have a reason to get a cool video game rig.

2. Are bitcoins good to invest in long-term?
Nobody can answer this except the flying spaghetti monster, and since she doesn't exist, she's not giving up her secrets.

Thermodynamic fallacies like some expressed in this thread are hard to overcome. It still is impossible to convince my mother that turning out the lights is not necessary in winter, when the light bulbs are just doing the same job as the resistive electric furnace running at 3000W, eventually converting every bit of electricity they use into heat.

Not related to anything posted yet - when looking for a space heater as a space heater, there is human comfort factor that is also important. Humans like to be 37C. If we lose heat faster than we generate it, we feel cold. The thermal conductivity of the medium affects how cold we feel; for example 25C water removes heat from our bodies much faster than 25C air, so a 25C swimming pool is cold on a 25C day. Moving air also does the same thing, while my computer may be blowing 30C air on my legs, it feels cold because it is removing more heat from my body that cooler, but more stagnant, air would be.

The best space heaters are those that direct very hot air right at you. I have a Pelonic ceramic heater that puts out a slow flow of air at a constant 125C (only the fan speed changes when adjusting it from high to low, the ceramic element 'wants' to be 125C, and the element resistance drops quickly below that temperature). That is much better than a space heater that blows a lot of 35C air at me from across the room, because although they may both be using 1500W, one is removing heat from my body.

I think you need to re-read the wattage labels on those heaters. Your TV likely puts out more heat than 190 watts.

That is bold to make bold claims, and be incorrect at them. A share submitted after 43.3% of difficulty has elapsed in a proportional pool has a lower expected return than if that share was submitted to a 0 fee PPS or even-paying pool, or if a switch was made to solo mining. By mining from the start until 100% of difficulty shares, you reduce your expected return from 28% to 22%. Considering the lag in statistics and delays switching into and out of a proportional pool, you should be triggering an earlier exit than that to maximize your expected earnings. By mining more pools, you have a higher chance of one of the pools being in the sweet spot, and can also choose the highest reward pool at a particular time, but that doesn't change the ultimate temporal valuation of a submitted share.

Indeed, you also shouldn't be 'slicing', shares should be submitted to the highest instantaneous reward pool only. I would have to scroll back 100 pages to see who came up with this stinker... The fallacy of reducing variation is why people are paying 7% for PPS (and 20% for credit cards), they can't see or comprehend the long-term.

The latest version seems to have a big bug, it basically seems seems to immediately change the block owner every time it gets a new block LP instead of evaluating which came first:

edit: fixed, removed log dump

This LP "who solved the block" procedure exploits an assumption, that a pool that finds a block will be sending notifications to miners earlier than other pools. This may not always be correct.

One has to understand these delays and what long polling is.

When a pool's bitcoin detects a new block (whether they found it themselves or found out about it over the p2p network), the the job of sending notifications goes to pushpool. Pushpool looks at all the open RPC connections that have long polling enabled, and pushes out a notification of the new block to the miners. Long polling keeps a connection open between the miner and the pool, so the miners get a quicker notification of the new block than if they were to just request new work every 15 seconds or so. This reduces obsolete share submissions ("stale" shares), improving pool efficiency.

Pushpool can't instantaneously notify everyone however, due to network bandwidth. Essentially, it goes through a list of all open connections and sends each the LP push consecutively. Small pools can send all their miners the notification quickly, but depending on the pool implementation and the number of open connections, this can take more than five seconds on busy pools. If you are on the start of the list, you get notification fast; at the end of the list, it can take longer. This means that the pool delay can be random per miner, much more significantly than packet transit times. Profiling your pool connection time may give different results from others, and may give different results even if you restart bithopper on a different day and make new RPC connections to the pool.

Great! This feature adds X seconds to the LP receive time of the specified pool for figuring out who solved it. That means if you analyze the console log, and find one pool that is consistently faster in sending you it's LP block announce than others (especially if a pool responds to you before the one that actually found the block - causing the proxy to designate the wrong pool), then you can 'equalize' the time LPs are received by adding a delay to 'too fast' pools.

Block 140749 found by pool.bitp.it:

[19:28:09] received lp from: bitp
[19:28:09] New Block: 5ea4b4d35340f0a60c238a721e3b0bd72453873fe6a7cec6000005f700
000000
[19:28:09] Block Owner bitp
[19:28:09] LP Call pool.bitp.it:8334/longpoll
[19:28:10] received lp from: mmf
[19:28:10] LP Call mining.mainframe.nl:8343/LP
[19:28:10] received lp from: deepbit
[19:28:10] LP Call pit.deepbit.net:8332/listenChannel
[19:28:10] received lp from: mineco
[19:28:10] LP Call mineco.in:3000/LP
[19:28:10] RPC request [getwork] submitted to polmine
[19:28:11] received lp from: bclc
[19:28:11] LP Call bitcoins.lc:8080/LP
[19:28:12] received lp from: eclipsemc
[19:28:12] LP Call pacrim.eclipsemc.com:8337/LP
[19:28:12] received lp from: arsbitcoin
[19:28:12] LP Call arsbitcoin.com:8344/LP
[19:28:14] received lp from: eligius
[19:28:14] LP Call su.mining.eligius.st:8337/LP

Although this is not the best example (I actually had one block scroll by where mineco was the first to announce the block, beating the actual finding pool), we can see that pools take different amounts of time to respond. Bitp.it was almost beat in announcing their own block by mainframe. I can improve the results by tweaking like this (if I was only looking at the above results and not evaluating pool delays over many blocks):

[mmf]
lp_penalty: 4

[deepbit]
lp_penalty: 4

[mineco]
lp_penalty: 4

[bclc]
lp_penalty: 3

[eclipsemc]
lp_penalty: 2

[arsbitcoin]
lp_penalty: 2

[eligius]
lp_penalty: 0

[bitp]
lp_penalty: 3? (would need to evaluate blocks they didn't solve)

I will test this out and see if it can completely fix false pool block designation. Of course what would be wishful thinking would be if bithopper could learn for itself the average delays it sees from each pool.

I'm trying the pool block detection features in this software. The LP detection algorithm needs the ability to fine-tune timing. Some pools announce blocks by LPs faster than others; the problem manifests that a fast/close pool can get LP push to the miner before the pool that actually solved the block. A block-finding pool can be slower than others from the pool's infrastructure, number of pool miners in that pool needing the LP push, and geographic location (and perhaps even by pool ops messing with LP timing themselves).

The correction factor could be a pool.cfg option to 'slow down' fast-announcing pools that cause false positives, a user.cfg option like "Delay_LP: 2" seconds if block-finding pools are consistently being beaten in LP push speed by this fast/small pool by a second.

Also, if anyone with a btcmine account would be willing to add worker for me to get info with and PM me, it would be appreciated!

1. Mine the hell out of this to increase difficulty 1024,4096,16384,65536,262144,1048576...,
2. Leave,
3. ....,
4. Profit in LuLz.

Big Edit:

I looked again at the AMD APP SDK v2.5, trying to get it to not suck. I did one more thing, not only did I install the 2.5 SDK (on Catalyst 11.6), but I also re-compiled pyopencl 0.92 against the newer SDK. On phatk 2.2, changing just from 2.4 SDK to 2.5 SDK with a matching pyOpenCL gets a hair more mhash:
SDK 2.4: 309.97
SDK 2.5: 310.10

Just to let people know, regarding the APP SDK, the version installed as well as the version used to compile pyopencl both seem to matter (not that this helps you if you are using just the prepackaged Windows phoenix.exe.)

Using a pyOpenCL newer than 0.92 gives a deprecation warning:

[0 Khash/sec] [0 Accepted] [0 Rejected] [RPC]kernels\phatk\__init__.py:414: Depr
ecationWarning: 'enqueue_read_buffer' has been deprecated in version 2011.1. Ple
ase use enqueue_copy() instead.
  self.commandQueue, self.output_buf, self.output)
[11/08/2011 21:10:22] Server gave new work; passing to WorkQueue
[291.32 Mhash/sec] [0 Accepted] [0 Rejected] [RPC (+LP)]kernels\phatk\__init__.p
y:427: DeprecationWarning: 'enqueue_write_buffer' has been deprecated in version
 2011.1. Please use enqueue_copy() instead.
  self.commandQueue, self.output_buf, self.output)

Using pyOpenCL 2011.1.2 with the kernel in its current form gets me less mhash though:
SDK 2.4: 307.98
SDK 2.5: 307.84

(5830@955/350; Catalyst 11.6; Win7; py 2.6.6)

I had an old $13 ask, but it didn't quite get there.

With a big one-time buy order like this (or a big single sell-off order), you don't get to log in and sell at the new price, since after it is filled, it's not like everyone else has instantly increased their buy price too. Trade prices will correct quickly, you had to have had an ask (sell) order in the system to help fulfill the instantaneous big buy order.

The site is being slowed down by taster bots that keep putting the same orders in every five seconds.

The Bitcoin difficulty targets a rate of six new transaction blocks per hour, so if your transfer includes an appropriate fee, it will be announced immediately to other clients, included in the next transaction block that is solved, and you will see the confirmation count increase to six (where the Bitcoin client status changes to confirmed) within about an hour. Sending to exchanges usually is between one and two hours, depending on how many confirmations they expect before making your funds available.

PPLNS doesn't punish you if you can't mine 24/7. The only difference vs a proportional pool is that the hashrate you submit now might get you nothing or it might get you 5x the reward. Compare that to mining part-time in a proportional pool: you might submitting work during a short round where you get a fast payout, or your part-time work might be diluted to near-nothing by a long round with full-time miners. It all evens out.

Thanks freemoney for freemoney!