1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
|
Return-Path: <tier.nolan@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2B16194D
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jul 2016 21:45:17 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f182.google.com (mail-qk0-f182.google.com
[209.85.220.182])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 129DF153
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jul 2016 21:45:16 +0000 (UTC)
Received: by mail-qk0-f182.google.com with SMTP id x1so18582877qkb.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jul 2016 14:45:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to;
bh=iEjEomNgfEbYhiWLteyaOf1Et/M1mtk691I+UwvbjGw=;
b=ub3tuDBxcwj8A9fnaa8dgZu0PD8zBOQCBKny4qXVWywFSWvgZKb1GUNhcUQZahQect
ptjRJdDj1fk7r+/0MMZOX3sGNCk3lHmnZ8vdJmTekolLiwUNSkhz2I/sNduMPTCpMpme
xl3wERQs9MF2ecG9G+S5EO7wVqtsjlDQPd4X55EZHe+9KEgJYCebvK3I8LxB6rtOds9z
iwei1Pdgl2/HMbPVcxuR8QecNdLW44BxYj6+9dCsadRZkAlrhW7nk6tfbmMRu8113eeR
dV2GNKLKHucURBNRh6gQrjFHlMEsZxjfmjbeq6p60ZuBL88xlYu6zybUx/w7Bnp82Pr6
gGRA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to;
bh=iEjEomNgfEbYhiWLteyaOf1Et/M1mtk691I+UwvbjGw=;
b=UqnoXUlqebThhNP2xvqeQ46UF4CweVsgS5KO7UBHS2oj8PLq9nwAMvnxIiLfA6X1Ck
rjKAJHPafb9ZWnO+ZCmktsP63h4HYe84r0peG2eyt5oD+3qRIuPnmtcMKuugSf5x5rq/
2GERRnOwVD3buFCaUX7S5/gj6nDERDyObwIOGye2nJjYI0ohhmPFcmIA9RF8GZl4ixmb
K27P8dHQycszk8emBui/c3HYFA7g06F8IK9SZ9rz6iY+FhjzjXpACYkUpGeJZQ5J8fcF
H3I45+ZRZpzXwhwgH+VBWQCc0rh53se5MgFruDAFjVKxTy6N2ee1hnVsuRYd3fu5/mfl
nFgA==
X-Gm-Message-State: AEkoouszGh6qT5R3nlsWHSeJErD9jfMhX85D4vWI8nzUlnehug6R+oTuZVv5kD8SyO3JdKenFY5gyMi/5iHGpQ==
X-Received: by 10.55.21.160 with SMTP id 32mr32806924qkv.210.1469569515189;
Tue, 26 Jul 2016 14:45:15 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.200.46.193 with HTTP; Tue, 26 Jul 2016 14:45:14 -0700 (PDT)
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
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Subject: Re: [bitcoin-dev] Reasons to add sync flags to Bitcoin
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2016 21:45:17 -0000
--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"><<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=
=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a>></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'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--
|
