That's no excuse.

Not sure if you were serious in your request, but here goes...

its.

than.

truly.

Depends... But generally in a situation like you describe you want higher variance. 3 flips is higher variance than 100 flips.

My derivation, as I explained, is based on the assumption that $1 at year 1 is equivalent to $(1+d) at year 0. It looks like you wanted that $1 at year 0 is equivalent to $(1-d) at year 1. So, let R = (1+i)/(1-d), and use the formula P_0*[(R-1)/(1-R^(-n))]*(1-d)^k.

It shouldn't matter too much, because 1/(1-d) = 1 + d + O(d^2).

If you assume that:
1. There are few tickets in total, so buying many tickets has a noticeable effect on your odds, and
2. You stop buying tickets if you find a winning one,
Then there's an advantage to the $2 tickets.

Regardless you also need to consider the variance. With the $10 tickets you have more variance, whether that's good or bad depends on your perspective. If you don't want variance you're better off not buying any tickets at all.

That's true, generating a new pseudorandom number for every hash wouldn't be very efficient. But the clock granularity has little to do with it, it's just used as a seed. Once you have the seed you can generate as many pseudorandom numbers in a sequence as you want.

I'd say we're nowhere near the point where this is worth the additional complexity and confusion, in particular with regards to scoring. People have a hard enough time understanding how shares should be scored as it is.

That's not overhead, that's just a uniform increase in hashing difficulty which has no effect.

I'm thinking mostly about the communication complexity between mining pools and participants. Bigger nonce = less getwork requests.

There is a reason to make it not harder for honest miners than for attackers.

Anything which improves the efficiency in practice, without changing the theoretical maximum an attacker can achieve, is welcome. Attackers will probably run large datacenters and not be effected much by the things I refer to as "overhead".

Doesn't matter much, after the nonce is exhausted the merkle root is changed (via the extranonce). But I agree it would make more sense to have it longer, it could decrease the overhead and doesn't seem to have serious disadvantages.

Oh, I don't know anything myself, I just quote what I read here .

Implementation details. If the nonce was longer (say 128 bits), you could just pick nonces randomly. If the Merkle root was easy to change, you could just use a different random Merkle root and nonce for every hash. But a compromise was reached with a short nonce which is checked sequentially, followed by a random change in the Merkle root. There's "no progress" in the sense that if you hashed for X minutes and didn't find a block, you aren't any closer to finding one than you were in the beginning. (That you don't try the same header twice only means that your progress isn't negative.)

You say you read the documentation, yet you keep asking these very basic questions.
This page details the contents of a block header. One of the fields is the hash of the previous block, this much doesn't change between different miners at the same time. The main thing that changes is the Merkle root, a hash of a data structure of all of the transactions to be included in the block. Assuming everyone knows and willing to include all transactions, most of the data doesn't change between different miners. What does change is the generation transaction. Everyone uses an address of his own in it. Also, there's "extra nonce" in this transaction which can be chosen freely. Hash functions being what they are, every such change alters the Merkle root in ways you can't imagine. Thus, the Merkle root can be for all purposes chosen randomly.

This will all become so much clearer to you if you hang around http://blockexplorer.com/ for a while.

I replied there with an explanation of your mistake.

Correct. I wondered whether I should have clarified that, maybe I could have spared you writing that huge post. Like I mentioned, these are just implementation details and it didn't seem to matter.

Your mistake is vast underestimation of the space of possible hashes. The block header is 640 bits long, of which 288 bits can be chosen more or less freely (Merkle root and nonce), meaning there are 2^288 different headers to try. If someone chooses these completely randomly and calculates a pentillion hashes (10^18), the chance of a collision (trying the same header twice) is less than 10^(-50). So, for all purposes, the hash space is infinite, there is no chance of collision, and random hashing is just as good as sequential.

Now, more technically, the nonce is the easiest part to change, and since it's only 32 bits, it does get checked sequentially (if you tried millions of nonces randomly you would get collisions). But that's implementation details.

Sounds about right. Don't forget everyone also chooses what transactions to include, puts them in a Merkle tree and uses its root as part of the hashed block header.

What's unwise about it?.

I don't know the standard terminology for this, so I'll specify my modeling assumptions explicitly.

Let's say you borrow a principal of P=$10K at the end of year 0 at interest i=5%. You are expected to return it at the end of year n=10. Your first payment is at the end of year 1. You pay an interest of 5%*$10K=$500 and some principal, say $1000, for a total of $1500. However, because of d=3% deflation, it feels like paying $1545 would feel at end of year 0. You now have $9000 principal left, so at end of year 2 you pay 5%*$9K=$450 interest, and say $1000 principal again, for a total of $1450 which feels like $1450*1.03^2=$1538.3. And so on.

What we are looking for is a payment scheme that ensures every payment feels the same. So let's call this feeling-equivalent x, we are looking for the x which makes the principal owed 0 after n years.

For an equivalent of x at the end of year k, the actual payment is x*(1+d)^(-k). So for the principal at the end of year k you have P_k = P_{k-1}(1+i) - x*(1+d)^(-k). Denoting R = (1+i)(1+d), this has general solution P_k = A(1+i)^k + [x(1+d)^(-k)]/(R-1). Because P_n=0 we have A = (-xR^(-n))/(R-1) and hence P_k = x * [(1+d)^(-k)-(1+i)^kR^(-n)]/(R-1). Letting k=0 gives us x = P_0*(R-1)/(1-R^(-n)), and so the actual payment at end of year k is P_0*[(R-1)/(1-R^(-n))]*(1+d)^(-k).

I don't currently have access to my CAS so you'll have to verify these calculations. But the fact that for d=0 you have R=1+i and this reduces to the original formula is encouraging.

Now for your questions:

1) 5% + 3% = 8% is probably the wrong intuition. If you have 50% interest per year, then the interest in two years will be 125% = (1+50%)(1+50%)-1, not 100%=50%+50%. The same probably happens when you combine the interest with deflation. They are combined multiplicatively, not additively, and you'll notice that R=(1+i)(1+d) plays a key role in my above calculation.

2) Check.

3) My formula gives an equal feeling-equivalent for every payment, and the derivation should be easy to modify for any desired increase or decrease in the equivalents.


About the philosophical issues, how much a payment feels is proportional to the person's salary, not its purchasing power. I expect that in a stable Bitcoin economy, salaries will remain more or less fixed in numerical value while their purchasing power will increase. So d would be 0 for Bitcoin.

If the last block is #136352, everyone is trying to find block #136353. But everyone tries to find a different block #136353.

The network doesn't "assign" jobs, everyone composes his candidate himself as long as it follows the rules. The most important variable is the receiving address of the generation transaction, everyone uses one of his own for this.

There's no "start over". There's no progress towards finding a block. It's random. A pool has, say, 0.01% chance of finding a block every second whether it's working on a new block or on the same block for hours.

Power efficiency has nothing to do with it. The system is designed to be stable as long as no single entity controls >50% of the hashing capacity. Whatever amount of hashing needs to be done (and hence power consumption) to ensure this is the amount that will be required. Everything else is implementation details.

It's not a race. In a race, whether you win or lose depends on what the others do. But here, for a given difficulty, the chance of finding blocks is completely independent of how many blocks others find.

More or less.

Right. But every block references the last block. Once a block is found and broadcast, people will start referencing it in their new blocks.

Rainbow tables would be useless because you're hashing different data each time.

Every block references the previous block, and the longest chain is considered the valid one. If a new block is broadcast which references a very old block it will not be part of the longest chain and have no influence.

I think your confusion is that you think that first the next block is decided, then people work on it. It's the other way around, every miner decides for himself what "block candidate" to work on. He decides what transactions, among the floating transactions he knows, will be included in it. Since everyone should know all transactions, the sender doesn't rely on any single miner for his transaction to be included. The miner constructs the header to work on based on the Merkle root of transactions, the hash of the previous block and so on, and starts hashing with different nonces until he find a hash satisfying the difficulty requirement. Only when he finds it he broadcasts it as the next valid block. If someone else beat him to finding a valid hash, the next block would be different (but would still include more or less the same transactions).

Since it's random, there's no "progress" towards finding a block which the miners need to synchronize about.

Have a look at http://blockexplorer.com/block/00000000000003910e6bce91f8fcbfabac2273123174a2a3fb128c0f7f2619f3 , all the data about the last block at the time of this writing.

I was thinking along the lines of a PI controller. I don't see how it can cause the problems you describe.

Re 1: First we need to ask why difficulty adjustment is based on a naive calculation instead of a more sophisticated control system. And the answer is probably that Satoshi either didn't have the foresight to include one, or he feared that it would be less understood and harder to implement.

Given that we're using a naive approach, evaluating generation rate in an interval too short will create too much variance, and difficulty will fluctuate every update.

The attack you've mentioned has been discussed before, and the current consensus is that it will be dealt with manually if it ever happens. So, while in theory it could be possible to create a consensus to change the adjustment algorithm, it doesn't seem to matter enough.

Re 2: The reason block reward diminishes at all is that Satoshi subscribes to the economic theory which says that the total amount of monetary units should have a fixed limit (I think this is called the Austrian school).

Why is the drop so staggered? Probably also has something to do with simplicity of understanding and implementation. I don't think the drop will be too disruptive. The amount generated is small compared to the total in circulation, and the drop will be considered in advance.

Making transaction fees high enough to support the required mining is an important challenge for Bitcoin going forward, which I think can be alleviated by augmenting proof-of-work with other synchronization methods.

I'd support a new blockchain where block reward is constant.

You're talking about PPLNS. I was talking about SMPPS. PPLNS is a great method as I've mentioned here and elsewhere.

Read carefully. I said "current hashrate > average hash rate over the window". The number of shares per window depends on the average hashrate over the window, not the current hashrate. Meanwhile, the chance your share will be included in a payout does depend on the current hashrate.