From: Sergio Lerner <sergiolerner@certimix•com>
To: Joseph Bonneau <jbonneau@princeton•edu>
Cc: bitcoin-research@lists•cs.princeton.edu,
"bitcoin-development@lists•sourceforge.net"
<bitcoin-development@lists•sourceforge.net>
Subject: [Bitcoin-development] DECOR+ Better block selection rule
Date: Wed, 07 May 2014 01:31:01 -0300 [thread overview]
Message-ID: <5369B705.9090406@certimix.com> (raw)
In-Reply-To: <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.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 --]
prev parent reply other threads:[~2014-05-07 4:30 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.122233.1398039406.2207.bitcoin-development@lists.sourceforge.net>
2014-04-21 1:30 ` [Bitcoin-development] Economics of information propagation Jonathan Levin
2014-04-21 3:58 ` Mark Friedenbach
2014-04-21 4:06 ` Peter Todd
2014-04-21 4:44 ` Daniel Lidstrom
2014-04-21 5:46 ` Daniel Lidstrom
2014-04-21 11:34 ` Tier Nolan
2014-04-21 13:04 ` Jorge Timón
2014-04-21 15:40 ` Ashley Holman
2014-04-21 15:58 ` Alan Reiner
2014-04-21 16:00 ` Mark Friedenbach
2014-04-21 16:22 ` Paul Lyon
2014-04-21 16:38 ` Mark Friedenbach
2014-04-21 16:39 ` Mike Hearn
2014-04-21 16:45 ` Jonathan Levin
2014-04-23 2:54 ` Tom Harding
2014-04-23 15:05 ` Peter Todd
[not found] ` <CAOe4Ui=OaVLvh0vUnNv-1j41YB4B2x896DQ5b6xt4oUJ5oLPFg@mail.gmail.com>
2014-05-02 11:48 ` [Bitcoin-development] Block collision resolution using the DECOR protocol and Bonneau's Kickbacks problem Sergio Lerner
2014-05-02 12:00 ` Sergio Lerner
[not found] ` <CAOe4UimBEe4t1Z41du3r8pQUOmzd_1V_aESizuiH2U6uvN9nFA@mail.gmail.com>
2014-05-05 19:45 ` Sergio Lerner
2014-05-05 20:27 ` Ittay
2014-05-07 4:31 ` Sergio Lerner [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=5369B705.9090406@certimix.com \
--to=sergiolerner@certimix$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=bitcoin-research@lists$(echo .)cs.princeton.edu \
--cc=jbonneau@princeton$(echo .)edu \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox