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
|
Return-Path: <teekhan42@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1E9C3259
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Jan 2017 21:06:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f169.google.com (mail-ua0-f169.google.com
[209.85.217.169])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18C08141
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 2 Jan 2017 21:06:00 +0000 (UTC)
Received: by mail-ua0-f169.google.com with SMTP id 34so268995338uac.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 02 Jan 2017 13:05:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc; bh=ilZpVVnUOuxGXX2dj+CaiBKgZ3ZAQfmm8dwIkQaXDLg=;
b=OhJI2hR33RGUUjgmn43LSCZsjMaPo0si7pWvhllOEhpjAnyBYYBL1lTJ5JlOBA0UH1
GGsjptoyHIT//J4ktaKmGhqzE58S0Kmkrne9AeWKFY1fwuHS+T7XhIYOxs3dmvLI/G9q
oJvdSS5a6tcXe7lKdI3sg0xYP8F0aDp/bDiwpSa6pSgi/g+3SXsyTWhza/ZyQ7YU1qFc
Pz5F7tNxQfQHAM27/42nSL64DNfBE8jfqIycuHdJqRr/18wINHjrCsPeajjswoSGxqHp
IJQAppJA96ZW39UOSn4Io8u2d8+t/cNJiqJB0suRQ+HMhz4ucSpnP1Rv7VGr9wYqQu7S
lbXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:in-reply-to:references:from:date
:message-id:subject:to:cc;
bh=ilZpVVnUOuxGXX2dj+CaiBKgZ3ZAQfmm8dwIkQaXDLg=;
b=gjtCqoyixdNBqeIv9hxGZ1R45G/6JGC1fGdS+KinEZIJkDl1PzwHWSRMMFa6dHVAYq
elLzAIcaTQ84UeDy+AV4Li1l4SNNmf5rXSUcAiCAQN6j3PAGSU4GgWvLZwVR4v0vOsBy
FJ7Z5GMQB6lwkRNyOWG+ZpqH4OcGWiTkJcjCgfeNlNBPCRmQ0/Q7JGy59CCA2ZV/J7c6
2ohOfB7Tx3uZirKV7QX5TRFxiR5MEShtLsjMXMBD1sjDQJqoklqlg6YbFZG1dnWLocNb
FN0UqrAI5KMQgQE11hkulmhclEUWuKNYI7ebL0EwBeMbvKkI5QlKDQU690rj1f5pfS9p
o+jA==
X-Gm-Message-State: AIkVDXLIyScC51Vhkffw7cgWr+dIqftJFOjWiPW0mYqrZyGuYj5fSUaAOiNmiE+iHo04gzbT0/YpAPZwgj96iQ==
X-Received: by 10.176.0.169 with SMTP id 38mr46934453uaj.34.1483391159256;
Mon, 02 Jan 2017 13:05:59 -0800 (PST)
MIME-Version: 1.0
Received: by 10.103.49.144 with HTTP; Mon, 2 Jan 2017 13:05:58 -0800 (PST)
In-Reply-To: <1944321.hguq3JoYe1@cherry>
References: <CAGCNRJoN7u3yvzitH2KSmVty-p0tX9jxWLHPb8uO5CPZmxmoRg@mail.gmail.com>
<2273244.fZU5ULDz4l@cherry>
<CAGCNRJp71NCxQ3jk4hu-kXF94RiqfeD=AVnxR37TrJ7bDG310w@mail.gmail.com>
<1944321.hguq3JoYe1@cherry>
From: "t. khan" <teekhan42@gmail.com>
Date: Mon, 2 Jan 2017 16:05:58 -0500
Message-ID: <CAGCNRJpBMEha+cqXbgL6z9Fk5aoDOJF8tHu+XhYmMtgmdY2osw@mail.gmail.com>
To: Tom Zander <tomz@freedommail.ch>
Content-Type: multipart/alternative; boundary=001a11c169da1c4bc7054522ebe2
X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,
HTML_MESSAGE, RCVD_IN_DNSWL_NONE,
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
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP - 'Block75' - New algorithm
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: Mon, 02 Jan 2017 21:06:01 -0000
--001a11c169da1c4bc7054522ebe2
Content-Type: text/plain; charset=UTF-8
On Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <tomz@freedommail.ch> wrote:
> If the input of your math is completely free and human created, how does it
> follow that it was math that created it ?
> Why do you want it math created anyway?
The beauty of math is that everyone on the planet agrees how it works.
Everything in Bitcoin is math, with the exception of the blocksize limit
(1MB) which was a stop-gap solution at the time.
> A maximum is needed, yes. But does it have to be part of the protocol?
> A simple policy which is set by node operators (reject block if greater
> than
> X bytes) will solve this just fine, no?
No. That would be an epic disaster. There's no such thing as a "simple
policy" when humans are involved. Obviously no one would agree on what X
bytes would be and you'd have some nodes rejecting blocks that others
already accepted.
- t.k.
--001a11c169da1c4bc7054522ebe2
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 Mon, Jan 2, 2017 at 3:35 PM, Tom Zander <span dir=3D"ltr"><<a hre=
f=3D"mailto:tomz@freedommail.ch" target=3D"_blank">tomz@freedommail.ch</a>&=
gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 =
0 .8ex;border-left:1px #ccc solid;padding-left:1ex">If the input of your ma=
th is completely free and human created, how does it<br>
follow that it was math that created it ?<br>
Why do you want it math created anyway?</blockquote><div><br></div><div>The=
beauty of math is that everyone on the planet agrees how it works. Everyth=
ing in Bitcoin is math, with the exception of the blocksize limit (1MB) whi=
ch was a stop-gap solution at the time.</div><div>=C2=A0</div><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex">A maximum is needed, yes. But does it have to be part of =
the protocol?<br>
A simple policy which is set by node operators (reject block if greater tha=
n<br>
X bytes) will solve this just fine, no?</blockquote><div><br></div><div>No.=
That would be an epic disaster. There's no such thing as a "simpl=
e policy" when humans are involved. Obviously no one would agree on wh=
at X bytes would be and you'd have some nodes rejecting blocks that oth=
ers already accepted.</div><div>=C2=A0</div></div>- t.k.</div></div>
--001a11c169da1c4bc7054522ebe2--
|
