MIME-Version: 1.0
In-Reply-To: <CAODYVYfciFGoVMKtOWs9PNkEJEt768KFZNO6s-qFhzQFchUTXw@mail.gmail.com>
References: <CAODYVYfciFGoVMKtOWs9PNkEJEt768KFZNO6s-qFhzQFchUTXw@mail.gmail.com>
From: Tier Nolan <tier.nolan@gmail.com>
Date: Tue, 26 Jul 2016 22:45:14 +0100
Message-ID: <CAE-z3OUkRbKVEB17dRzgtm_Ojdy9Bf6tqwz=nopJEOO2-7+3qw@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a11473cf6ecfb60053890d0ad
Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
Precedence: list

--001a11473cf6ecfb60053890d0ad
Content-Type: text/plain; charset=UTF-8

On Tue, Jul 26, 2016 at 9:58 PM, Martijn Meijering via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Is there a reason miners would be more likely to engage in selfish
> mining of sync flags than they are now with ordinary blocks?
>


This proposal has the same effect as adding mandatory empty blocks.

POW targeted at 2 minutes means that the POW for the flag is 25% of the
block POW.  That gives a flag every 2 minutes and a block every 8 minutes.

It has the feature that the conversion rate from hashing power to reward is
the same for the flags and the blocks.  A flag get 25% of the reward for
25% of the effort.

A soft fork to add this rule would have a disadvantage relative to a
competing chain.  It would divert 20% of its hashing power to the flag
blocks, which would be ignored by legacy nodes.  The soft fork would need
55% of the hashing power to win the race.

This isn't that big a deal if a 75% activation threshold is used.  It might
be worth bumping it up to 80% in that case.

This rule would mean that headers first clients would have to download more
information to verify the longest chain.  If they only download the
headers, they are missing 20% of the POW.

--001a11473cf6ecfb60053890d0ad
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Jul 26, 2016 at 9:58 PM, Martijn Meijering via bitcoin-dev <span dir=3D=
"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
Is there a reason miners would be more likely to engage in selfish<br>
mining of sync flags than they are now with ordinary blocks?<br>
</blockquote><div><br><br></div><div>This proposal has the same effect as a=
dding mandatory empty blocks.<br><br></div><div>POW targeted at 2 minutes m=
eans that the POW for the flag is 25% of the block POW.=C2=A0 That gives a =
flag every 2 minutes and a block every 8 minutes.<br><br>It has the feature=
 that the conversion rate from hashing power to reward is the same for the =
flags and the blocks.=C2=A0 A flag get 25% of the reward for 25% of the eff=
ort.<br></div><div><br></div><div>A soft fork to add this rule would have a=
 disadvantage relative to a competing chain.=C2=A0 It would divert 20% of i=
ts hashing power to the flag blocks, which would be ignored by legacy nodes=
.=C2=A0 The soft fork would need 55% of the hashing power to win the race.<=
br><br></div><div>This isn&#39;t that big a deal if a 75% activation thresh=
old is used.=C2=A0 It might be worth bumping it up to 80% in that case.<br>=
<br></div><div>This rule would mean that headers first clients would have t=
o download more information to verify the longest chain.=C2=A0 If they only=
 download the headers, they are missing 20% of the POW.<br></div></div></di=
v></div>

--001a11473cf6ecfb60053890d0ad--