From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-1.v43.ch3.sourceforge.com ([172.29.43.191] helo=mx.sourceforge.net) by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WhtV9-00065o-Av for bitcoin-development@lists.sourceforge.net; Wed, 07 May 2014 04:30:39 +0000 X-ACL-Warn: Received: from p3plsmtpa08-06.prod.phx3.secureserver.net ([173.201.193.107]) by sog-mx-1.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WhtV7-0006CI-B3 for bitcoin-development@lists.sourceforge.net; Wed, 07 May 2014 04:30:39 +0000 Received: from [192.168.1.101] ([190.19.169.149]) by p3plsmtpa08-06.prod.phx3.secureserver.net with id ysWU1n0083DkUH201sWVa9; Tue, 06 May 2014 21:30:31 -0700 Message-ID: <5369B705.9090406@certimix.com> Date: Wed, 07 May 2014 01:31:01 -0300 From: Sergio Lerner User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6 MIME-Version: 1.0 To: Joseph Bonneau References: <52CDA01B-13BF-4BB8-AC9A-5FBBB324FD15@sant.ox.ac.uk> <20140423150555.GE19430@savin> <53638616.2030009@certimix.com> <536388F9.3040607@certimix.com> In-Reply-To: X-Enigmail-Version: 1.6 Content-Type: multipart/alternative; boundary="------------040209020706000103040702" X-Spam-Score: 1.0 (+) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [173.201.193.107 listed in list.dnswl.org] 1.0 HTML_MESSAGE BODY: HTML included in message X-Headers-End: 1WhtV7-0006CI-B3 Cc: bitcoin-research@lists.cs.princeton.edu, "bitcoin-development@lists.sourceforge.net" Subject: [Bitcoin-development] DECOR+ Better block selection rule X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 07 May 2014 04:30:39 -0000 This is a multi-part message in MIME format. --------------040209020706000103040702 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit 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)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. --------------040209020706000103040702 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: 8bit
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:
      • 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.

Best regards,
 Sergio.
--------------040209020706000103040702--