I'm not a PHP coder.

If you don't want to do it, don't do it.  I was just giving feedback based the incorrect algorithm you posted on the forum.

Your statements are contradictory here.  If the bias is very small (which it is), then blocks won't be skipped very often and users won't have anything to be upset about.  It's not going to happen very often, if ever.  But as things stand now you can't (honestly) say that your game is "fair."   You can say that the bias is "small" and users might be okay with that, or they might not.

But anyway, another algorithm would be to increment the nonce and generate a new hash.   Again, you do this deterministically only when the first hash falls in the bad range.

You misunderstand.  The discarding is entirely deterministic based on the formula.  There is no way for the administrator to exploit that.  i.e. still provably fair.

The standard method is to discard the inputs that lead to a biased draw. If this happens, you could wait for the next block to pay off the raffle.  It is very unlikely to happen in practice so as a practical matter, you can certainly ignore it, but people tend to get a little heated about "unfair" gambling sites.

I think the top answer here is correct, but I didn't examine it that carefully: http://stackoverflow.com/questions/11758809/what-is-the-optimal-algorithm-for-generating-an-unbiased-random-integer-within-a

You realize the code in the first post produces slightly biased draws for ticket counts that aren't a power of two, right?

Oh, the big blk....dat files at the top level of Bitcoin are now unused? 

Still, expecting users to exclude three separate folders from Time Machine is a bit much.  Most won't even know about it and will just have their backups blow up, or will possibly exclude the top level when this happens, no longer backing up their wallet.

How about putting the BCD in ~/Caches instead of Library?  I think Time Machine excludes that by default, and this seems like logically the right approach to me anyway.  (Unfortunately I think Spotlight still indexes Caches).

There is also an issue with Time Machine.  The (huge) blockchain database (BCD) files are constantly being updated, which means they are copied and recopied to the backup disk every hour. 

Excluding the Bitcoin foilder from Time Machine means the wallet won't be backed up either, which is bad.

There should be some kind of storage layout where the old blocks are in static files that don't change.  Or at least the wallet should be moved out of the same folder as the BCD so the BCD can be excluded from backup without excluding the wallet.

This affects every system with an incremental backup mechanism, not just Mac, but it is a bigger issue on Mac because Time Machine is built into the OS and is widely used. 

Is there a way to mark files as being of a non-indexable type?


Yes, as stated in the original post.  That works fine.

I've noticed that with 0.8.0-beta on Snow Leopard, when updating the block chain, mds (the spotlight indexer) wakes up frequently and burns a lot of CPU (presumably indexing and reindexing the block chain database).  Adding Library/Application Support/Bitcoin to Spotlight privacy fixes the problem.  I don't know if there is some way for the client to indicate to spotlight that the files in there shouldn't be indexed.

I don't know about newer versions of Mac OS do the same thing, but I wouldn't be surprised if they do, since spotlight isn't changed much.

Yes, and at times this difference can be important in terms of supply fundamentals.  One common misconception about bitcoin is that supply is "fixed."  Eventually it is (22 mil) but the 6/hour rate is not fixed at all.  During periods of rapid network growth the production of bitcoins is borrowed from the future since the lagging difficulty calculation causes the block production rate to increase well above 6/hour.

The obvious (though not necessarily correct) inference from bitcoinBull's latest chart is that this is a good time to buy since the ratio being near 1 has been the bottom end of the trading range historically. 

You could use bitcoin transfers.  Address A sends 1.00X bitcoins to a pool address.  The pool sets the donation rate for address A to X% and sends 1.00X bitcoins back.

I say again, the advantage of the biggest pool is the lowest payout variance.  Pools like Eligius have some great features like zero fees, etc. but they suffer because sometimes they get zero blocks in an entire day.  That never happens with deepbit.  Deepbit gets a few blocks an HOUR most of the time.

Pooled mining is a natural monopoly for this reason.  There needs to be some kind of technical fix, like the one previous linked in this thread. 

And even if deepbit is kept below 50%, it's still the case that the big pools as a group have the same natural advantage and will tend to control a big share of the network.  Two or three pools that control 50%+ (quite a bit over in fact) is not good because it is too easy for two to three pool operators to collude.  In fact there is no way in general to know that two "separate" pools aren't actually run by the same person.

The whole pool model is part of the problem.  There is a natural economy of scale in that the biggest pool has the lowest payout variance. 

Until there is some kind of fix for that, this problem will come up again and again.  Today it is deepbit, in the future it might be some other pool (or it might still be deepbit), and even a small number of large pools isn't great, because a few pool operators could collude to reach 50%+.

The 12 day cycle is probably due to the difficulty adjustments.  They're supposed to be 14 days, but when the network is growing they happen faster.

I haven't had time to do any real work with the data yet, unfortunately.

Eligius uses generate transactions to distribute pool coins.  I got a few, to an address I have assigned to "eligius" in my wallet, but they are showing up in the "" account.  Is this the expected/intended behavior?

    {
        "account" : "",                    <----
        "category" : "generate",
        "amount" : 1.27329935,
        "confirmations" : 205,
        "txid" : "58cc0cf1877e8153b6b53b32e6c63bc486ae19a6f275e3dfe200f5d15d49d9af",
        "time" : 1306806056
    }

{ confirm with block explorer that this transaction went to 1B9hLQDUdpL29A2EMbCfx6fY2qpGKww9t }

$ ./bitcoin-0.3.21/bin/64/bitcoind getaccount 1B9hLQDUdpL29A2EMbCfx6fY2qpGKww9t
eligius
$ ./bitcoin-0.3.21/bin/64/bitcoind listaccounts
    "eligius" : 0.00000000,

price adjusted

price bump

You can't assume that everyone who is selling is mining-for-immediate-sale. People may have bought or mined previosuly and don't need them any more. 

Hmm.  I don't get how you have a "locked in" trade for 48 hours.  That's a pretty long time.  Did you explicitly agree that you were going to take 2+ days to settle the deal?

price bump