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
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
|
Return-Path: <earonesty@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C52332C
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jul 2016 17:27:24 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-yw0-f181.google.com (mail-yw0-f181.google.com
[209.85.161.181])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 08C5A287
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jul 2016 17:27:23 +0000 (UTC)
Received: by mail-yw0-f181.google.com with SMTP id z8so23379690ywa.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 26 Jul 2016 10:27:23 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
h=mime-version:sender:in-reply-to:references:from:date:message-id
:subject:to:cc;
bh=O+NL8HWcPeDrqXcwPg4aSnUMyIzC/HbtObOsxVwwLRg=;
b=FLnOYAOqbeyoraehyeTvWnUAHflfDt9LRcojeyYc10tAwjTisLHLnCN2ajeQvxdr2c
pfq+3yTAmtb3VCVqYbrlKklAQO6z2z8wAJffecgVKHPxO8Yi2stQDRVTX8jglNhg6Le0
r8qnnvDcPizR+XokjF62xXML/7ZbLE9clyhgYQ1oGlUhMxo6qYEDm2frs/syrqiPVTsj
PYxCarRuo1xMoT3/FBVtkgxvj+7WuM6pCdXuS5xTs/A7IzABO+caNOJE9G4YlDRalZnY
d/bm81xPvq4TUGjiToJIOaIY6Q+vLZRBgGF4htFssgfLotRW6mlwoCFqtc+wJLlKjLig
ZmtQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20130820;
h=x-gm-message-state:mime-version:sender:in-reply-to:references:from
:date:message-id:subject:to:cc;
bh=O+NL8HWcPeDrqXcwPg4aSnUMyIzC/HbtObOsxVwwLRg=;
b=fNaqpdDvSjs643wcHa8K/jeQrEiHfnlxu0AqW0WELk3+xRhYQwxEyfjSnZze3nMA0y
U9agu2V3HmV58dooxtSpXszjzfr+6MqAUpcT6waMfC+FiMacF1AuK6LLM4DlAHeK3MwX
rXVzmAoWXlMg8es7GzM8dd/7lq7bkpbwbgoeuOepsNUw/TPfQamjl0CgzgbRfGge2G9s
xl4XW4Zcig5yXoDo4j83xuEWipwkTcxcWN+hNacNKjQROjhcCPZNZJw+TPfZoNP8jRX1
/no+FeuZrDGqbyi8xvX0x2QR7WEymKCsDQsZw6lk1/USswUTDETsrXCsR3Ec9vaOHhRa
/eLg==
X-Gm-Message-State: AEkoousGFthT2Eri8HsMIOhp6ZmugfXgPYZWbn7apSQfZ0SwAom2CcphiXB/y2tesDpGKYS2+ZEY7KN0iQrVgg==
X-Received: by 10.13.221.149 with SMTP id g143mr22300188ywe.52.1469554043222;
Tue, 26 Jul 2016 10:27:23 -0700 (PDT)
MIME-Version: 1.0
Sender: earonesty@gmail.com
Received: by 10.37.88.214 with HTTP; Tue, 26 Jul 2016 10:27:22 -0700 (PDT)
In-Reply-To: <1659997.Te2m0CHHuS@garp>
References: <CACiOHGxpTEOzUBovuJstNEVQOpD+Yv0JivuyeOFsba_jhdyydw@mail.gmail.com>
<1659997.Te2m0CHHuS@garp>
From: Erik Aronesty <erik@q32.com>
Date: Tue, 26 Jul 2016 13:27:22 -0400
X-Google-Sender-Auth: diRwKQdgYsIs5J2_Oqph0Ge4fWE
Message-ID: <CAJowKgLw+0LZJkQ-F2xi_t11dpJoWvTDQnyMjFPB+XfD98RvYw@mail.gmail.com>
To: Tom <tomz@freedommail.ch>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c060f20b987d505388d3658
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE 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 17:27:24 -0000
--94eb2c060f20b987d505388d3658
Content-Type: text/plain; charset=UTF-8
- Flags will be mined selfishly, and not published until the advantage
gained from withholding is less than the mining reward. This effect may
kill the decentralization features, since big miners will be the only ones
that can selfish-mine flags. Indeed, collusion would be encouraged... just
ship the flag to the miners you do business with, and no one else. At the
expense of loss of flag revenue, your in-group would gain a massive
advantage in main-chain mining.
On Tue, Jul 26, 2016 at 9:51 AM, Tom via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> > #Basic idea:
> >
> > Ideally, all miners would begin hashing the next block at exactly the
> same
> > time. Miners with a head start are more profitable, and the techniques
> that
> > help miners receive and validate blocks quickly create centralization
> > pressure.
> >
> > What if there was something that acted like the starting flag at a race,
> > which could suddenly wave and cause all of the miners to simultaneously
> > begin hashing the next block?
> >
> > #Implementation:
> >
> > Let a sync flag be a message consisting of:
> >
> > 1. Hash of the previous block.
> > 2. Bitcoin address
> > 3. Nonce
> >
> > This tiny message could propagate through the network at maximum speed.
> If
> > miners had to include the hash of this flag in the next block, then all
> > miners wait for this flag, and when it suddenly spread through the
> network,
> > all miners could simultaneously begin hashing the next block.
>
> What you describe in this part of your message can be done with no forks
> whatsoever and I think that this is enough. Don't really see the reason for
> any change in funding.
>
> The idea of sending out a block header is essentially what I called
> "optimistic mining" and has been described in more detail in my blog here;
> http://zander.github.io/posts/Innovation%20-%20OnlineScaling/
>
> The video explains with graphics too...
>
> You may find this interesting :)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--94eb2c060f20b987d505388d3658
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D""><div class=3D""><ul><li>Flags will be mine=
d selfishly, and not published until the advantage gained from withholding =
is less than the mining reward.=C2=A0 This effect may kill the decentraliza=
tion features, since big miners will be the only ones that can selfish-mine=
flags.=C2=A0 Indeed, collusion would be encouraged... just ship the flag t=
o the miners you do business with, and no one else.=C2=A0=C2=A0 At the expe=
nse of loss of flag revenue, your in-group would gain a massive advantage i=
n main-chain mining.<br></li></ul>
</div>
</div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quote">On Tu=
e, Jul 26, 2016 at 9:51 AM, Tom via bitcoin-dev <span dir=3D"ltr"><<a hr=
ef=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">bitco=
in-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex">> #Basic idea:<br>
><br>
> Ideally, all miners would begin hashing the next block at exactly the =
same<br>
> time. Miners with a head start are more profitable, and the techniques=
that<br>
> help miners receive and validate blocks quickly create centralization<=
br>
> pressure.<br>
><br>
> What if there was something that acted like the starting flag at a rac=
e,<br>
> which could suddenly wave and cause all of the miners to simultaneousl=
y<br>
> begin hashing the next block?<br>
><br>
> #Implementation:<br>
><br>
> Let a sync flag be a message consisting of:<br>
><br>
> 1. Hash of the previous block.<br>
> 2. Bitcoin address<br>
> 3. Nonce<br>
><br>
> This tiny message could propagate through the network at maximum speed=
. If<br>
> miners had to include the hash of this flag in the next block, then al=
l<br>
> miners wait for this flag, and when it suddenly spread through the net=
work,<br>
> all miners could simultaneously begin hashing the next block.<br>
<br>
What you describe in this part of your message can be done with no forks<br=
>
whatsoever and I think that this is enough. Don't really see the reason=
for<br>
any change in funding.<br>
<br>
The idea of sending out a block header is essentially what I called<br>
"optimistic mining" and has been described in more detail in my b=
log here;<br>
<a href=3D"http://zander.github.io/posts/Innovation%20-%20OnlineScaling/" r=
el=3D"noreferrer" target=3D"_blank">http://zander.github.io/posts/Innovatio=
n%20-%20OnlineScaling/</a><br>
<br>
The video explains with graphics too...<br>
<br>
You may find this interesting :)<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div><br></div>
--94eb2c060f20b987d505388d3658--
|
