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
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
|
Return-Path: <crypto@crypto.press>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 232964A4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 14:15:34 +0000 (UTC)
X-Greylist: delayed 00:23:33 by SQLgrey-1.7.6
Received: from ter.terralibrecity.com (ter.terralibrecity.com
[216.172.177.108])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 50B72144
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 14:15:33 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=crypto.press; s=default;
h=Content-Type:To:Subject:Message-ID:Date:From:
MIME-Version:Sender:Reply-To:Cc:Content-Transfer-Encoding:Content-ID:
Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc
:Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:
List-Subscribe:List-Post:List-Owner:List-Archive;
bh=e4kSpudbkmSkdwm1SPlCwIYd+mjootFNykHYT3l+V+w=;
b=b3Syf7KkckoHMxQz8rbu0Kmweq
yBP1yJWKt/USLeGcR6XaNzc/n2LekAq1hEZV4DAwvRQd5i54e1rzTzQCN84JbONlhAoyCfJ9FN6KB
CwAVF8/Ct2doPTtgXMdUKAcnOWZ/u16lDE+3XqyV5AYO3dw22Vq7o3RQOQsHoMNOB/vzhT3KnaKr5
up/3zQoVWXQ8L+vp5PceQrPFBQ50bG8rXo1mIsJ9IaePujlGpwWzmaBvqB2K9ppeK2jrryNCeb9q6
opTXvGR106ZGQTYu8mziq5yOvEMY34XP2mfFJ/FV+/iQA7LBn4x3STJF+gL6P8Cqh7TiJYwdTKi6S
f2GIHUxQ==;
Received: from mail-ua0-f180.google.com ([209.85.217.180]:34888)
by ter.terralibrecity.com with esmtpsa
(TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.88)
(envelope-from <crypto@crypto.press>) id 1czO7L-000568-GO
for bitcoin-dev@lists.linuxfoundation.org;
Sat, 15 Apr 2017 08:51:59 -0500
Received: by mail-ua0-f180.google.com with SMTP id f10so36206740uaa.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 15 Apr 2017 06:51:59 -0700 (PDT)
X-Gm-Message-State: AN3rC/77ceXUFxjD47nYJ5o7PhsdTefQw3BWNZ2wB6S38CTtl4E8sQpi
HpoSj9pi6TD/jCOwiHbICcho+ImpCQ==
X-Received: by 10.176.65.196 with SMTP id 62mr6172268uap.175.1492264318677;
Sat, 15 Apr 2017 06:51:58 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.159.37.69 with HTTP; Sat, 15 Apr 2017 06:51:58 -0700 (PDT)
From: "Crypto.Press" <crypto@crypto.press>
Date: Sat, 15 Apr 2017 07:51:58 -0600
X-Gmail-Original-Message-ID: <CAPMASjto+y3SpaBuJPLb2XUrZm8aWu0QWEEVHN6PDherrBeuWg@mail.gmail.com>
Message-ID: <CAPMASjto+y3SpaBuJPLb2XUrZm8aWu0QWEEVHN6PDherrBeuWg@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a114fb3a4a03ed1054d34dc6d
X-AntiAbuse: This header was added to track abuse,
please include it with any abuse report
X-AntiAbuse: Primary Hostname - ter.terralibrecity.com
X-AntiAbuse: Original Domain - lists.linuxfoundation.org
X-AntiAbuse: Originator/Caller UID/GID - [47 12] / [47 12]
X-AntiAbuse: Sender Address Domain - crypto.press
X-Get-Message-Sender-Via: ter.terralibrecity.com: authenticated_id:
crypto@crypto.press
X-Authenticated-Sender: ter.terralibrecity.com: crypto@crypto.press
X-Source:
X-Source-Args:
X-Source-Dir:
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,HTML_MESSAGE,RCVD_IN_SORBS_SPAM autolearn=no
version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
X-Mailman-Approved-At: Sun, 16 Apr 2017 20:09:52 +0000
Subject: [bitcoin-dev] Diminishing Signaling Returns
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: Sat, 15 Apr 2017 14:15:34 -0000
--001a114fb3a4a03ed1054d34dc6d
Content-Type: text/plain; charset=UTF-8
Hi everyone, I have never posted to the list and do not commit the project
proper so I do apologize if this is not even possible in advance.
Examining bitcoin's past and contrasting it with other social contracts and
even physical phenomena it would seem that as bitcoin continues to age
entropy will continue to grow.
The scaling debate would seem to be a fore-bearer of this.
One main contributor to this in bitcoin is as people/businesses become
involved and vested into their perspective it becomes minted in their
identity. The idea that this will somehow decrease as the user base grows
with more perspectives and use-cases seems counter-intuitive so I propose a
potential way to combat entropy in a divided community.
Diminishing Signaling Returns
Since entropy is the increase of disorder in a system (the various scaling
solutions for this idea) and measuring via resource is not trustless, we
need a mechanism to essentially counteract entropy while not relying on
game-able metrics.
What if we applied a rate of diminishing returns on signaling in BIP9?
Something along the lines of:
Every (X) block signaled The actual signal value diminishes from a 1 signal
1 block to a fraction of a signal per block found after a burn in period of
some reasonable time to ensure a majority upgrade(this could even be
effected after the timeout currently apart of BIP9 for ease of
implementation?).
Some thoughts
- The pools that find more blocks would lose the ability to block the
network without taking an economical hit splitting up their hash power as
signaling was never intended to be a voting mechanism (to my knowledge).
- The longer that the signaling took place would eventually run a larger
pool's signaling influence to 0 first. This creates a balancing effect
between hash rate & #of miners actually signaling ready.
- Gamesmanship of this system would be visible to the community at
large. e.g. pools hash rate/blocks found jumps or declines significantly in
a short time frame, or specific time frame (when pools influence begins to
decline).
- creates multiple economic incentives for the mining community to be on
a similar page
- this as a feature of a soft forks greatly diminishes politics becoming
a factor in the future.
unfortunately, this itself would require a soft fork if I am correct?
Acceptance then becomes the question.
While bitcoin has proven to be highly resilient, stagnation has destroyed
many systems/businesses and if the current state of affairs is any measure
it would stand to reason that in the future this will only worsen. Taking
this action could be a solution to that stagnation. So, it would be in
everyone's best long-term interest to support a continually evolving
bitcoin and would allow parties with ideas that differ the time and
resources to fork in a more responsible manner without devoting their
resources to politics. However, everyone would still have the time to voice
their opinions during the burn-in/timeout period and of course before any
code was actually included through technical consensus.
Thoughts?
Regards,
Benjamin George
Crypto.Press http://crypto.press
--001a114fb3a4a03ed1054d34dc6d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div style=3D"color:rgb(34,34,34);font-family:arial,sans-s=
erif;font-size:small;font-style:normal;font-variant-ligatures:normal;font-v=
ariant-caps:normal;font-weight:normal;letter-spacing:normal;text-align:star=
t;text-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;b=
ackground-color:rgb(255,255,255);text-decoration-style:initial;text-decorat=
ion-color:initial"><div>Hi everyone, I have never posted to the list and do=
not commit the project<span class=3D"gmail-m_7843344178119555129gmail-Appl=
e-converted-space">=C2=A0</span>proper<span class=3D"gmail-m_78433441781195=
55129gmail-Apple-converted-space">=C2=A0</span>so I do apologize if this is=
not even possible in advance.<span class=3D"gmail-m_7843344178119555129gma=
il-Apple-converted-space">=C2=A0</span><br><br>Examining
bitcoin's past and contrasting it with other social contracts and even=
=20
physical phenomena it would seem that as bitcoin continues to age=20
entropy will continue to grow.<span class=3D"gmail-m_7843344178119555129gma=
il-Apple-converted-space">=C2=A0</span><br><br>The scaling debate would see=
m to be a fore-bearer of this.<span class=3D"gmail-m_7843344178119555129gma=
il-Apple-converted-space">=C2=A0</span><br><br>One
main contributor to this in bitcoin is as people/businesses become=20
involved and vested into their perspective it becomes minted in their=20
identity. The idea that this will somehow decrease as the user base=20
grows with more perspectives and use-cases seems counter-intuitive so I=20
propose a potential way to combat entropy in a divided community.<span clas=
s=3D"gmail-m_7843344178119555129gmail-Apple-converted-space">=C2=A0</span><=
br><br>Diminishing Signaling Returns<br><br>Since
entropy is the increase of disorder in a system (the various scaling=20
solutions for this idea) and measuring via resource is not trustless, we=20
need a mechanism to essentially counteract entropy while not relying on=20
game-able metrics.<span class=3D"gmail-m_7843344178119555129gmail-Apple-con=
verted-space">=C2=A0</span><br><br>What if we applied a rate of diminishing=
returns on signaling in BIP9? Something along the lines of:<span class=3D"=
gmail-m_7843344178119555129gmail-Apple-converted-space">=C2=A0</span><br><b=
r>Every (X) block signaled The actual signal value diminishes from a 1 sign=
al 1 block to a fraction of a signal per block found after a burn in period=
of some reasonable time to ensure a majority upgrade(this could even be ef=
fected after the timeout currently apart of BIP9 for ease of implementation=
?).<span class=3D"gmail-m_7843344178119555129gmail-Apple-converted-space"><=
/span><br><br>Some thoughts<br><ul><li>The
pools that find more blocks would lose the ability to block the=20
network without taking an economical hit splitting up their hash power=20
as signaling was never intended to be a voting mechanism (to my=20
knowledge).<span class=3D"gmail-m_7843344178119555129gmail-Apple-converted-=
space"> <br></span></li><li>The longer that the signaling took place would =
eventually run a larger pool's signaling influence to 0 first. This cre=
ates a balancing effect between hash rate & #of miners actually signali=
ng ready.<span class=3D"gmail-m_7843344178119555129gmail-Apple-converted-sp=
ace">=C2=A0</span></li><li>Gamesmanship
of this system would be visible to the community at large. e.g. pools=20
hash rate/blocks found jumps or declines significantly in a short time=20
frame, or specific time frame (when pools influence begins to decline).<spa=
n class=3D"gmail-m_7843344178119555129gmail-Apple-converted-space">=C2=A0</=
span></li><li>creates multiple economic incentives for the mining community=
to be on a similar page</li><li>this as a feature of a soft forks greatly =
diminishes politics becoming a factor in the future.<span class=3D"gmail-m_=
7843344178119555129gmail-Apple-converted-space"> <br></span></li></ul><br>u=
nfortunately, this itself would require a soft fork if I am correct?<span c=
lass=3D"gmail-m_7843344178119555129gmail-Apple-converted-space">=C2=A0</spa=
n><br></div><div><span class=3D"gmail-m_7843344178119555129gmail-Apple-conv=
erted-space"></span><br><br>Acceptance then becomes the question.<br>While
bitcoin has proven to be highly resilient, stagnation has destroyed=20
many systems/businesses and if the current state of affairs is any=20
measure it would stand to reason that in the future this will only=20
worsen. Taking this action could be a solution to that stagnation.=C2=A0 So=
,=20
it would be in everyone's best long-term interest to support a=20
continually evolving bitcoin and would allow parties with ideas that=20
differ the time and resources to fork in a more responsible manner=20
without devoting their resources to politics. However, everyone would still=
have the time to voice their opinions during the burn-in/timeout period an=
d of course before any code was actually included through technical consens=
us.<br><br>Thoughts?<span class=3D"gmail-m_7843344178119555129gmail-Apple-c=
onverted-space">=C2=A0</span><br><br></div><div>Regards,</div>Benjamin Geor=
ge<br></div><span style=3D"color:rgb(34,34,34);font-family:arial,sans-serif=
;font-size:small;font-style:normal;font-variant-ligatures:normal;font-varia=
nt-caps:normal;font-weight:normal;letter-spacing:normal;text-align:start;te=
xt-indent:0px;text-transform:none;white-space:normal;word-spacing:0px;backg=
round-color:rgb(255,255,255);text-decoration-style:initial;text-decoration-=
color:initial;display:inline;float:none">Crypto.Press <a href=3D"http://cry=
pto.press" target=3D"_blank">http://crypto.press</a></span></div>
--001a114fb3a4a03ed1054d34dc6d--
|
