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
|
Return-Path: <akaramaoun@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 30CC4267
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 10:13:52 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ig0-f171.google.com (mail-ig0-f171.google.com
[209.85.213.171])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BE0BEB0
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 10:13:51 +0000 (UTC)
Received: by igfj19 with SMTP id j19so37526809igf.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 16 Aug 2015 03:13:51 -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:date:message-id:subject
:from:to:cc:content-type;
bh=mQBn8TFOnj+LuvwVIuhG/kWMIoZJBxo68YqtRgSd2IQ=;
b=wUG2VofgHZdWogtHKbEBD6u4bifFAY3nnwcdjEeGX/2n2eIBXfkuIyT/O8P5TsOeJy
LT766ttcqTzVhew2pXwThl6PGo9pwj7FFrwfdq4Bogf0ZutJie//N7ED5TLCX2anfKON
Np67jHis96S6kxQkWTS6u7YMpS+eQQCNrS98PUOUa0rhuHa6g1vp1DGh36sKW6eytrhr
nJgQ/TV1DHPQ2d4hKYZ0Z099Fg4JkJTLVCOcKgD+3hUjGVuI6Ywsrkud21GaareoJhbZ
4jPwPJPSyK0bpRJu6V49nGLo92fR8eGs5F/jk2Mxw+FO6bfiwDvcBlSv4K74cOqzFT1f
et/g==
MIME-Version: 1.0
X-Received: by 10.50.153.75 with SMTP id ve11mr10675598igb.52.1439720031189;
Sun, 16 Aug 2015 03:13:51 -0700 (PDT)
Sender: akaramaoun@gmail.com
Received: by 10.107.151.195 with HTTP; Sun, 16 Aug 2015 03:13:51 -0700 (PDT)
In-Reply-To: <1527744.9EQbJdl4Dy@1337h4x0r>
References: <1527744.9EQbJdl4Dy@1337h4x0r>
Date: Sun, 16 Aug 2015 10:13:51 +0000
X-Google-Sender-Auth: _GbiQruQ3-FCm9m4VYn1LME7zWE
Message-ID: <CAL8tG==dfe80oxs6Ay_t7BpvoiwmWY2t8uMEt-8a1ivkf8NyWw@mail.gmail.com>
From: Andrew <onelineproof@gmail.com>
To: xor@freenetproject.org
Content-Type: multipart/alternative; boundary=089e0141aa08090282051d6af161
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] Humans constantly arguing about bsize proves that
computers should decide
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development 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: Sun, 16 Aug 2015 10:13:52 -0000
--089e0141aa08090282051d6af161
Content-Type: text/plain; charset=UTF-8
On Sun, Aug 16, 2015 at 9:46 AM, xor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hey folks,
>
> so you've been stressed with arguing about what to do with the block size
> for
> months now :(
>
> Why not realize that the unfruitful permanent need for administrators to
> tweak
> a magical, god-given (= Satoshi-given) constant is a *strong* indicator for
> something which should be delegated to a self-adjusting system instead?
>
> new_max_blocksize = some_averaging_function(previous_block_sizes);
>
Not necessarily some_averaging_function. Could also be something that
depends on how much work has been put in, i.e. make the miners do more
computational work if they want to add bigger blocks into the chain, and
the chain doesn't have to be the original chain, it could be a sidechain or
block extension, so as to not force people to upgrade.
> end_of_flamewar();
> continue_with_REAL_development();
>
> Systems which do not require any human intervention are always more
> beautiful,
> and especially when trying to design a decentralized P2P network :)
>
>
> Greetings,
> xor, a developer working for the Freenet anonymous P2P network
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
--
PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
--089e0141aa08090282051d6af161
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sun, Aug 16, 2015 at 9:46 AM, xor via bitcoin-dev <span dir=3D"ltr">=
<<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_bla=
nk">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockqu=
ote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc s=
olid;padding-left:1ex">Hey folks,<br>
<br>
so you've been stressed with arguing about what to do with the block si=
ze for<br>
months now :(<br>
<br>
Why not realize that the unfruitful permanent need for administrators to tw=
eak<br>
a magical, god-given (=3D Satoshi-given) constant is a *strong* indicator f=
or<br>
something which should be delegated to a self-adjusting system instead?<br>
<br>
=C2=A0 =C2=A0 new_max_blocksize =3D some_averaging_function(previous_block_=
sizes);<br></blockquote><div>Not necessarily some_averaging_function. Could=
also be something that depends on how much work has been put in, i.e. make=
the miners do more computational work if they want to add bigger blocks in=
to the chain, and the chain doesn't have to be the original chain, it c=
ould be a sidechain or block extension, so as to not force people to upgrad=
e. <br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;b=
order-left:1px #ccc solid;padding-left:1ex">
=C2=A0 =C2=A0 end_of_flamewar();<br>
=C2=A0 =C2=A0 continue_with_REAL_development();<br>
<br>
Systems which do not require any human intervention are always more beautif=
ul,<br>
and especially when trying to design a decentralized P2P network :)<br>
<br>
<br>
Greetings,<br>
=C2=A0 =C2=A0 =C2=A0 =C2=A0 xor, a developer working for the Freenet anonym=
ous P2P network<br>
<br>
<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>
<br></blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail=
_signature">PGP: B6AC 822C 451D 6304 6A28 =C2=A049E9 7DB7 011C D53B 5647</d=
iv>
</div></div>
--089e0141aa08090282051d6af161--
|
