[Bitcoin-development] DECOR+ Better block selection rule

[Sergio Lerner <sergiolerner@certimix.com>]

[-- Attachment #1: Type: text/plain, Size: 3216 bytes --]

This e-mail is an extract of my post:
http://bitslog.wordpress.com/2014/05/07/decor-2/

Some posts ago 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 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:
          o pay q coins to the address specified in the coinbase output
            of block Y
          o pay w coins to an owned address
          o burns z coins
          o 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.

Best regards,
 Sergio.

[-- Attachment #2: Type: text/html, Size: 4296 bytes --]