I don't think ThiagoCMC was making any accusations, rather an optimization suggestion. He said that Eclipse can, instead of not doing MM for opt-outers as is the current policy, do MM and keep the NMC either for the operator or for the other miners.

Personally I think it is reasonable to expect that if you disable MM then your shares will not be used for MM at all.

Only for generation transactions. Eligius pays out with the generation transaction which is why that's what you saw, but for normal transactions it's 6.

Maybe. My point was that in this regard the qt GUI isn't more space-consuming than the old GUI.

Let's say the last block is #157596, and all miners are trying to find block #157597. Two miners find a block at the same time, one with hash a651a9... and one with hash f6498d... . Each broadcasts it to everyone it knows, until 50% of the network knows of block a651a9... and 50% knows of block f6498d... . If computer A offers to deliver block a651a9... to computer B which already has f6498d..., it will basically say "No thanks, I already have a block for position #157597". (Maybe it will download it and store it, but not recognize it as correct.) The network will be in a disagreement about what the last block is (this is known as a chain fork), and each miner builds block #157598 based on what he recognizes as block #157597. When block #157598 is found, let's say its hash is b66848..., computer B will eventually be informed of it, and since this is a longer chain than what he knows, he will take a651a9... and b66848..., and recognize them as valid blocks instead of f6498d... (this is a chain reorganization).

Every different block header gives the miner 4 billion new hashes to try. Changing the extranonce changes the Merkle root and thus the block header. When a miner finishes his work he gets a new header with a different extranonce.

It's the transaction that gives the miner the 50 BTC (or whatever it is) block reward (or alternatively, the input of that transaction).

Only a coinbase transaction can have a coinbase input, and coinbase input is the only kind of input that does not correspond to an earlier output.

This is definitely possible one way or another, but the details probably depend on the country and even the accountant's interpretation of the activity.

Here is what my accountant told me.

So if you buy a bitcoin at $3 and sell it at $3.05, in fact you have provided a service and charged $0.05 for it, so you pay 15% of $0.05 in taxes.

In case you're unaware, the V next to a transaction means it has 6 confirmations. When it has less there are different icons, and hovering over it displays the exact number of confirmations. It takes less horizontal space than the confirmations listing in the old GUI.

Sure, you can use https://bitcoil.co.il/bitcoil_logo.png or https://bitcoil.co.il/bitcoil_64.png.

Feel free to send any clients from Israel my way. Note, though, that at this point I have no wish to endorse or associate myself with your casino beyond that.

One of the first? I guess that's relative.

Exactly. "All our donation (the donations collected through us, the Bitcoin100) are belong to you (the charity who keeps 100%)".

That can be used as a litmus test for choosing charities. If it crosses our minds to approach an organization with this slogan, it's probably not the kind of charity we are looking for.

Yeah, but a quick search indicates that what's out there is not quite like what I want to do. I want to format it a bit differently, and focus on the most irritating misspellings of really basic words.

"Donation". Say it right.

And I think "to us" is both more fitting and more true to the source.
Edit: The other way around. Should be "All Our Donation are Belong to You!".

You mean "You could have at least spelled ONE word incorrectly."
If it's any consolation, FF's spellchecker doesn't agree that "incentivize" and "counterintuitive" are words. It's wrong, of course.

As long as we're on a grammar tangent... I have for some time wanted to set up a webpage correcting some commonly misspelled words like "definitely", "lose", "its", "they're", "would have", etc. I figured I would give people the option to donate for my efforts using PayPal. But the likely donations would be small and PayPal's fixed fee would eat them all up. So I invented the concept of "randomized donations" which allows donating any given amount on average with much less transaction fees (at the cost of higher variance). But now with Bitcoin this is all moot, and I know a lot more now about setting up webpages, so I should probably go ahead with that...

Sure, sounds good.

Why go half-way? "All your donation are belong to us".

I voted no. I mean, archive.org is great and all, I won't start a riot if it's chosen, but I don't think this is what I signed up for. The goal (I think?) was to improve Bitcoin's perception by having mainstream charities accept it, and to that end incentivize charities for whom it would be otherwise counterintuitive to accept bitcoins. A geeky project like archive.org doesn't much further that goal. And, while it doesn't feel right to punish them for accepting Bitcoin on their own, the fact is that they don't need the extra incentive, and they're doing fine raising bitcoin funds by people who want to donate specifically to them.

I didn't acknowledge in this analysis (and in most of my other analyses) the time it takes the Bitcoin network to recognize the block reward, in part because I don't think it's very fundamental. Either it is simply added to the raw maturity time of each method (which for solo is 0, because for every "share" found while mining solo, if a reward will be given for it, it will immediately move from "unrealized score" to "unconfirmed" status), or it is replaced by a small fee which the pool op takes to compensate for the average invalid rate, variance in invalids and the advance payment (where I consider a pool which simply pays each miner for the blocks he found himself, with or without this absorption of the 120-block wait, to be a type of solo).

I've added a note to clarify this.

The reward method triangle is a visual way to represent the different tradeoffs when selecting a reward system for a mining pool.

The 3 primary factors which determine the attractiveness of a pool (at least as far as the reward method is concerned), are:
 - Expected payout
 - Variance of payout
 - Maturity time

The expected payout is affected by several external factors which are unrelated to the reward method; however, it is influenced by the risk posed on the pool operator by the reward method, as high risk will cause him to charge a higher fee to compensate. Therefore, the above factors can be translated to the following attributes which the reward system seeks to minimize:
 - Variance
 - Maturity time
 - Operator risk

It is impossible to eliminate all 3 simultaneously; however, by choosing a reward method and its parameters, it is possible to achieve any desired tradeoff between the 3. (In this analysis we disregard some sources of additional variance and maturity time, such as variable block rewards and the 120-block maturation time).

The possible choices can be visualized with the reward method triangle:



Every point in the triangle represents a possible tradeoff between the 3 attributes.

The red vertex represents high variance, while the opposing red edge represents no variance; the more distant a point is from the red edge, the more variance there is in a method corresponding to the point.

Similarly, the green vertex represents high maturity time, with the green edge representing no maturity time; and the blue vertex represents high operator risk, with the blue edge representing no operator risk.

The shaded area corresponds to all possibilities that can be obtained with different parameters for the double geometric method. The methods represented by the edges and vertices are also special cases of DGM. This isn't a special property of DGM per se - other methods can also encompass the entire triangle if they are sufficiently parameterized.  You can reduce any attribute as much as you like by moving close to the corresponding edge, but at the cost of increasing the other two; and you can even eliminate any two attributes by approaching the vertex of the third, at the cost of pushing that third attribute to the highest possible value (the blue vertex is a special case which I discuss in detail below).

The red vertex corresponds to solo mining, which has no maturity time or risk, but has the highest possible variance. It is also a special case of DGM with c=0, r=0, of the geometric method with c=0, and of PPLNS with N=1 share.

The blue edge represents PPLNS in all its variants (unit-, exponential-, shift-, pay-once-, but not the naive versions which are not hopping-proof), which has no operator risk. By choosing a value for N (or the equivalent parameter for the specific variant), we select a point along the edge; a low value is closer to the red vertex with high variance and low maturity time, while a high value is closer to the green vertex with low variance and high maturity time. Exponential-PPLNS is a special case of DGM with c=0, o=1 and varying values of r.

As N goes to infinity in PPLNS, we approach the green vertex, which has no variance or risk, but infinite maturity time. This is DGM with o=1, r=1.

The red edge represents DGM with c=1, r=1 and varying values of o. This has no variance, and the tradeoff between maturity time and risk is controlled by o - the lower o is, the greater the risk and the lesser the maturity time. However, even if we set o to 0 and follow the method verbatim, there will still be maturity time. The payouts in this case will be exactly as in PPS, but the method description specifies that they can only be given when the next block is found. This is why the blue vertex, corresponding to PPS (with the highest risk, but no variance or maturity time) stands on its own - we need to explicitly specify that we will give rewards according to PPS rather than following the generic method. This is also why there is a white area which is probably impossible to achieve with any reward method (unless there is a two-way payment channel between the operator and miners).

The black edge which is adjacent to the green edge represents the geometric method. Its maturity time is not 0, which is why it does not coincide with the green edge; but it has the lowest maturity time for any given generic tradeoff between risk and variance. The higher the parameter c is, the lower the variance and the higher the risk. As c approaches 1, we approach the intersection between the black and red edges, which is equivalent to PPS for all purposes except maturity time.

He allows selling bitcoins, not buying bitcoins, so chargebacks don't apply.

Even for buying, the real problem isn't the chargebacks, it's PayPal freezing the account.

Also http://bitcoinservice.co.uk/ .

Yes, both points are correct. Though, personally I would be wary of keeping my life savings in a wallet which I have never ever checked actually works.

I'll take a shot at making this even clearer:

Score = How much you will get for every future block. The exact amount you'll get out of this depends on the number of blocks that will be found and is thus random.

Unconfirmed = Rewards for blocks which were already found but didn't mature yet.

Confirmed = Rewards for blocks which already matured.

Normal withdrawals are from the confirmed balance only.
Cashout is confirmed + unconfirmed + score - fee, where the fee is applied only to the unconfirmed and score.

You don't need it to get to >=0, as long as the balance stays mildly negative you'll get your payouts (in the limit). You're betting that the pool doesn't collapse (due to reaching a highly negative balance) before you finish getting your payouts.