Bitslog

In my previous post I presented the DECOR protocol. One of the assumptions I did was that the amount of coins each miner earned in competing blocks was approximately the same. This could be true for cryptocurrencies with never ending block subsidies (inflationary designs) because the block subsidy may be an order of magnitude higher than the fees collected in the block. In Bitcoin we don’t really know what will happen with fees when the reward is halved. Less we know if in that case the number of transactions per block (and fees collected) will be fairly constant or there will be high variability. If Alice and Bob compete for a certain block height with blocks A and B respectively, and Alice’s block reward (subsidy+fees) is half of Bob’s reward, then even if Hash(A) < Hash(B) (and the DECOR incentives are set to prefer A) it may be the case that both Alice and Bob would prefer to mine on top of B since they both earn much more even paying the higher penalty d of burnt coins. In limit cases, Alice’s optimal choice may not be the same as Bob’s optimal choice (I will search for an example case and insert it here). I propose a slight modification of the protocol such that even with different block rewards the optimal choice of parent is always the same for all miners. Instead of choosing the block with less hash digest, miners will choose the block with higher reward (subsidy+fees). Splitting the higher reward block would always be more profitable than splitting lowest reward block. In the rare case both blocks have exactly the same reward, then the block with lowest hash is chosen. Even if rewards are approximately equal, the change adds a new monetary incentive to cooperate. Compared with the DECOR protocol, the only modification is in step 6.

DECOR+ Mining strategy

1. If there is no block Y having a sibling X in the main chain whose reward has not matured then mine in the standard way and exit this procedure
2. Add a reference to Y in the new block that is being prepared.
3. Let x  := BlockReward(X)
4. Let q := x*a
5. Let z :=x*b
6. If (BlockReward(X)<BlockReward(Y)) OR (BlockReward(X)=BlockReward(Y)) AND (Hash(X)>Hash(Y)) then
   q :=q-(x*c)
   z :=z+(x*d)
7. Let w :=x*e
8. Add a transaction that has as input the coinbase output of X and has four outputs:
   • pay q coins to the address specified in the coinbase output of block Y
   • pay w coins to an owned address
   • burns z coins
   • pay the remaining coins to the same address as the input address.

BlockReward() returns the block subsidy plus the transaction fees in the block.

Conditions on constants

If you want to choose different values of a,b,c,d,e that still force miners selections converge into a single parent then these conditions must be satisfied:

• e > 0
• 1-a-e-b > a-c
• 1+e-a-e-b > a-c
• a > 1-a-c-e-b-d
• a+e > 1-a-c-e-b-d

And all constants are between 0 and 1. It’s interesting that now it’s much easier to prove that for two competing miners the DECOR+ protocol cannot be abused, since there is no dependence on the block content.

Competition by more than two blocks

It should be very rare that more than two blocks compete for the same place in the block-chain, so one could just disregard this case. If the case it should be considered, the protocol can handle it, at the expense of a little more block-chain house-keeping work. Miners should accept any new missing sibling during all the immaturity period of a block coinbase, even if other siblings have been previously found and published. To simplify sharing the reward, it would be better if the transaction that distributes the reward of a block between its siblings is not included in intermediate blocks, but in the last block before maturity. This transaction would distribute the reward among all siblings previously published and pay each miner having published a share. I have no proof that a single set of a..e constants make DECOR+ work for any number of competing miners, but the values a..e could also be dynamically adjusted depending on that number.

Security of DECOR+ when mining on top of unverified block headers 

One of the drawbacks of this strategy when used along with the strategy of mining on top of unverified block headers is that  the reward (subsidy+fees) should be specified on a field in the block header to allow nodes to immediately decide what block to mine on top of.  This should not be a problem since 8 bytes is enough. But a rogue miner could specify an arbitrary high value in this new field creating an invalid block and then forcing the remaining miners to mine on top of this invalid block. Nevertheless, the attack is costly and has almost no impact on the network. The miners in the network will react by backtracking to the previous parent block when as soon as the rogue block is detected as incorrect during verification or the timer associated with unverified mining expires.