Add November 13th Hardfork technical specification

[schancel]

Subscripts did not translate well. Suggestions?

[ftrader]

@schancel : Maybe using something like B_last would be more readable?

I'll start reviewing, but please add a version number + date at the top, in the style of the other spec docs. This thing will need updating.

[ftrader]

Merging this since it's good enough for further public review on its own. We consider it a work in progress as things like test vectors will still be added.

Everyone is invited to raise Issues or submit Pull Requests on it where they think changes are needed.

[zawy12]

I really like the simple algorithm you've chosen. You could have done away with the median of 3 and the limits on the T range and it would have worked pretty much the same. Forward timestamps that would have lowered the difficulty by 1-144/(144+12)= 8% would have had the effect completely erased in the next block as long as you do not erase negative solvetimes. Since the-6 MTP and +12 limits are in there, total_time > 2*144 or < 0.5*144 would be real measurements that do not need to be limited. The -6 MTP can get be "owned" by a >50% attack, making it possible to drive the D up as high as the attacker wants. But as other miners abandon it due to it being unprofitable, the attacker could reduce his hashrate that was required to perform the attack. But smart miners would be able see to the low hashrate behind the curtain of fake timestamps, and jump on, again causing him a large loss in wasted hashrate. There is no fix for this. Obviously it is unlikely, unless a state decides it does not like a certain coin. This can't be done on the +12 side to drive difficulty continually down (via > 50% hashrate being able to "own" the median of 3 and MTP) because the +12 limit is a real-time limit, not relative to the block chain. So the bitcoin limits are smart. But if the nodes have an approximate agreement on time, then they do not need mining because the nodes could run as a synchronous network that does not need consensus enforced by POW. Specifically, there would be an "on" and "off" cycle synchronized with clock time for when nodes will accept and not accept tx's for the current block (same as a CPU). The off time is due to network latency, the same reason CPU's have a "no more signals" period, waiting for distance parts of the chip to catch up and due to the relative slowness of transistors to change state.

Anyway, the simplest possible difficulty design is just as good as the best, i.e. next_D = sum(past N D's) / sum(past N solvetimes). I've been preaching this for a year and it's good to see BCH is going to use the simplest method.

My only complaint is the large N. I prefer N=50 as you know. Degnr8's weighting method is a little better but was a little late in being considered.