Actually, I think it probably is... just not safe to spend the outputs yet (or enable others to do so).

This recently created a problem for Eligius. I think it needs to follow the same rules as other formerly-unknown transactions in the block.

It is actually the time that the transaction was received. Some older versions used that time until it was confirmed, and then changed the timestamp to the block time. This caused listtransactions to change order. I agree this logic needs reworking to be sane in all scenarios. Perhaps something along these lines...

Requirements:

• The timestamp shown for a transaction should never change.
• New transactions should always have a timestamp no earlier than the transactions accounted for before it.
• THEREFORE, new transactions should never have future timestamps.
• listtransactions should preserve the order of transactions added.

Logic:

• If receiving a transaction outside a block, assign its timestamp to the current time.
• If receiving a block with a future timestamp, assign all its (not already known) transactions' timestamps to the current time.
• If receiving a block with a past timestamp, before the most recent known transaction (that we care about), assign all its (not already known) transactions' timestamps to the same timestamp as that most-recent-known transaction.
• If receiving a block with a past timestamp, but after the most recent known transaction, assign all its (not already known) transactions' timestamps to the block time.

Additionally, it might make sense to add 'first_seen' and 'block_time' to the information.

Anything I'm missing here?

Mining is always a form of gambling. And with SMPPS, you don't have to be mining when it goes positive. Even if you've stopped mining, you'll still be paid for extra credit you've earned.

No, gambler's fallacy is just assuming that the next block will move the buffer/credit toward 0. Over a long timeperiod, the law of large numbers does apply. The difference, while it might grow, will also have diminishing relevance, at least with ESMPPS. Real-world experiences show that the difference does not in practice grow unbounded, however.

The law of large numbers means that over time, any miner/pool's rewards will always drift toward average in the long run.

Put bluntly, this paper is wrong and biased:

• MPPS does pay out fairly over the long-term to fair miners, at least in practice.
• While it is true that hoppers can hurt fair miners with MPPS, they have no incentive to do so. (remember that any pool can be hurt by the block withholding attack, so this is not a significant flaw)
• Terminology: SMPPS does not accrue "debt", but issues fiat "extra credits" when it cannot pay Bitcoins.
• SMPPS, in theory, will always drift toward 0-buffer 0-credit, it does not have any inherent negative drift.
• In practice, SMPPS has proven to have a positive buffer much more than zero (on Eligius, we have only very briefly hit 0-buffer a few times)
• While in theory, people might "hop" off SMPPS when it has no buffer, this is in practice not a problem. There was no mass exodus from Ars when its buffer hit zero and began issuing extra credit, and by now everyone has observed that so long as the pool remains online, it will eventually recover. Furthermore, this kind of "hopping" does not benefit the hopper nor harm the non-hopper.

Note that I only read the "Attempts for risk-free pay-per-share" section, and am not attempting to cover the other methods here.

The original SMPPS pool, Eligius, is still up and going.

Sorry, but Bitcoin is not anonymous nor "free" of regulation. Maybe you need to grow up and get out of your rebellious phase-- and start obeying your legitimate authorities (obedience is a virtue!).

The only way this would even be a viable experiment would be if someone was willing to back it with another currency. For example, guarantee they would always buy 1 GC for 1 USD. Otherwise, it's just another scamcoin.

And even if someone does want to try the backed-cryptocurrency concept, please don't inherit the design flaws of Bitcoin.

I think it would be nice to get OPTIONAL support in Bitcoin-Qt for embedding an external source tree of cgminer into the client. With Eligius, it doesn't even need configuration: just check the "Generate Bitcoins" box and watch them come in

Why?

It was his own. He basically resold 100 BTC worth of merchandise at cost, and donated half of it to the forum. It's no different than if he had simply donated his 100 BTC directly in the first place, except he chose to let the community get something out of it (being able to buy retail products for Bitcoins).

Since Toys for Tots does not accept Bitcoin donations, what determines the conversion rate that will be used?

An answer to this should be provided so that people know:

• You won't instant-sell the amount, moving the market and harming the Bitcoin economy.
• You won't sell them all to yourself or a close friend at some dirt-cheap rate.

I'm not saying you would do either of these necessarily, but that you should set a good precedent for auctions to avoid problems like this arising in the future as well.

Easy answers to this would include:

• MtGox "last" at the end of the auction
• Flat $3 per BTC

It might also be a good idea to try to sell them at $3.50 (for example) at first, to give people a chance to be charitable in yet another way.

Managed to merge just the orphan-flood bugfix without the client banning feature. Hopefully this compromise is good enough for everyone.

0.5.x already has the client-banning feature, so it will ban orphan flooders.

I just added a "maxtxfee" option to get the old behaviour (enabled by default up to 0.01 BTC fee). Hopefully this is a good compromise?

Hmm, does it also ignore the block? I wonder if it's maybe possible to merge this WITHOUT the banning part?

Shortly after 0.4.0 was released, Gavin added code to ban clients which misbehave (sending invalid blocks, transactions, etc). This is part of 0.5.0, but I didn't merge into 0.4.1 because it was questionable whether this was really a fix or a new feature, and it looked like there was some potential for new bugs introduced by it.

Recently, a certain "alternate" block chain has been experiencing floods of impossible orphan blocks which are filling its clients' databases. In order to preemptively try to stop such an attack on Bitcoin, Gavin just added an extension to his client banning code which also bans clients that send these impossible orphan blocks. This will become part of 0.5.1 and 0.6. Since this orphan block flooding has an actual potential to do damage, this new change seems more likely to be a bugfix than the original client banning was.

So my question to people who will be using the stable bitcoind 0.4.x on an ongoing basis is: should this be backported for 0.4.2, or not?

Note: Impossible orphan blocks are, for example, those with impossibly low difficulty or built on blocks older than the last "checkpoint" block.

Someone just tried to register namecoin payouts to 1JVTmfR36K9hPA7UR3jqRj6HRhyudYLUvK. This is a bitcoin address, and not a namecoin address. It will not work. You can reregister with a valid namecoin address, but until then, no namecoins will accrue. I have fixed the registration page to reject Bitcoin addresses in the Namecoin field.