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
|
Return-Path: <opetruzel@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 1E36A941
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 May 2017 23:50:01 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-oi0-f42.google.com (mail-oi0-f42.google.com
[209.85.218.42])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AD291F3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 May 2017 23:50:00 +0000 (UTC)
Received: by mail-oi0-f42.google.com with SMTP id h4so92782741oib.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 29 May 2017 16:50:00 -0700 (PDT)
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=Yj/VilyPXb9nWAbmy3T4iiAgnISXM5Hqq1oJdsc+aB4=;
b=AH+uxqafwsGZO5SCwqmBFeBtzCAVP5y6GaeHwljHTAQlw7oIWI3r0V8UPN8jkfvzkw
A53My7pWZ9LJUN5H8yO+Mffolh5vfZOiy2aebAinfVEvgoiGbMfKG2b+o7mscT595D4E
Z5QPZixA240B57GfSoeFlj/hE9Uz6AJoOk66OLPmQaShw/qkRgbkm7M8tAKqryghWRgz
FZ+uIE4I+lEkqDcBQivbhpnP3fB84CYlAgNozSTfrhxR1ip7TUmei0b1rABhbVc7Nmo4
bgWcYTKvzzNycJUMcTQ3/QCbQtZHOj5Vz/3XPk4kzghvmK60thoQxdkZ9TfxPqcto6av
yYrg==
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=Yj/VilyPXb9nWAbmy3T4iiAgnISXM5Hqq1oJdsc+aB4=;
b=KzkiAzfRNNUF1NBGsS1DFjToGHhRMZyijD8ZQQQmBMFddkzku2u+GDFpzfHNsDpZO3
G25vuX1lwcCsQKVajLK3YqeXShcMRQEkOg3ZIxo8HwjiR9Yoojua7WgSvZ98TGqwX68L
uF/WN4mxc+oWr9M4NEfPZugLvfRH3UwZ9pNCrq+Gt3t4GygueVtCQAm82hTwZFCxD/w+
zup4PzRqLBqp5+GnC/siS/ajTmz+qH+iVnj4q2M+E/N7YfFyofPVPaImXb0i1YyqCQjR
hkrzcDapulGxn4Mt5Ct43J81Jq0YGgF1VaL8yqQ2o55IzSUFf4+j/W4rfP2EDpU96e2C
uqKw==
X-Gm-Message-State: AODbwcAYSLsIC9049FhGruQ9u3qKBaArVrDFtcsOJ7Io2Z6bG+UjWFGl
GuNFUdywtPzmlRGbYFeOgbwOMlp/Kg==
X-Received: by 10.202.207.141 with SMTP id f135mr8620569oig.211.1496101800062;
Mon, 29 May 2017 16:50:00 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.157.34.15 with HTTP; Mon, 29 May 2017 16:49:59 -0700 (PDT)
Received: by 10.157.34.15 with HTTP; Mon, 29 May 2017 16:49:59 -0700 (PDT)
In-Reply-To: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com>
References: <aC4avUiJPnHXxIxPlh4w2XA-SLB6ueTUlVTW7TreFwGV12L7L9CAGoB2E9msVYhV0M6xPTERpatAIeZO3kK-ikCRkwYQcJeEMHS7WWZKDAM=@protonmail.com>
From: Oliver Petruzel <opetruzel@gmail.com>
Date: Mon, 29 May 2017 19:49:59 -0400
Message-ID: <CALhpmH3sUxa=MYtCdNMGO3AMGgmT=Tc2kcJzzpoY84syjgtP_A@mail.gmail.com>
To: CalvinRechner <calvinrechner@protonmail.com>
Content-Type: multipart/alternative; boundary="001a113ad55e5735940550b25887"
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, 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
X-Mailman-Approved-At: Mon, 29 May 2017 23:51:21 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Compatibility-Oriented Omnibus Proposal
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, 29 May 2017 23:50:01 -0000
--001a113ad55e5735940550b25887
Content-Type: text/plain; charset="UTF-8"
>>if the community wishes to adopt (by unanimous consensus) a 2 MB block
size hardfork, this is probably the best way to do it right now... Legacy
Bitcoin transactions are given the witness discount, and a block size limit
of 2 MB is imposed.<<
The above decision may quickly become very controversial. I don't think it's
what most users had/have in mind when they discuss a "2MB+SegWit" solution.
With the current 1MB+SegWit, testing has shown us that normal usage results
in ~2 or 2.1MB blocks.
I think most users will expect a linear increase when Base Size is
increased to 2000000 bytes and Total Weight is increased to 8000000 bytes.
With normal usage, the expected results would then be ~4 or 4.2MB blocks.
Am I missing something here, or does Luke's suggested 2MB cap completely
nullify that expected linear increase? If so, why? What's the logic behind
this decision?
I'd love to be armed with a good answer should my colleagues ask me the
same obvious question, so thank you ahead of time!
Respectfully,
Oliver Petruzel
--001a113ad55e5735940550b25887
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"auto"><div style=3D"font-family:sans-serif;font-size:18.048px" =
dir=3D"auto"><span style=3D"font-size:18.048px">>>if the community wi=
shes to adopt (by unanimous consensus) a 2 MB block size hardfork, this is =
probably the best way to do it right now... Legacy Bitcoin transactions are=
given the witness discount, and a block size limit of 2 MB is imposed.<=
<</span><br></div><div style=3D"font-family:sans-serif;font-size:18.048p=
x" dir=3D"auto"><span style=3D"font-size:18.048px"><br></span></div><div st=
yle=3D"font-family:sans-serif;font-size:18.048px" dir=3D"auto"><span style=
=3D"font-size:18.048px"><br></span></div><div style=3D"font-family:sans-ser=
if;font-size:18.048px" dir=3D"auto">The above decision may quickly become v=
ery controversial. I don't think<span style=3D"font-size:18.048px">=C2=
=A0it's what most users had/have in mind when they discuss a "2MB+=
SegWit" solution.=C2=A0</span></div><div style=3D"font-family:sans-ser=
if;font-size:18.048px" dir=3D"auto"><span style=3D"font-size:18.048px"><br>=
</span></div><div style=3D"font-family:sans-serif;font-size:18.048px" dir=
=3D"auto">With the current 1MB+SegWit, testing has shown us that normal usa=
ge results in ~2 or 2.1MB blocks.</div><div style=3D"font-family:sans-serif=
;font-size:18.048px" dir=3D"auto"><br></div><div style=3D"font-family:sans-=
serif;font-size:18.048px" dir=3D"auto">I think most users will expect a lin=
ear increase when Base Size is increased to 2000000 bytes and Total Weight =
is increased to 8000000 bytes. With normal usage, the expected results woul=
d then be ~4 or 4.2MB blocks.</div><div style=3D"font-family:sans-serif;fon=
t-size:18.048px" dir=3D"auto"><br></div><div style=3D"font-family:sans-seri=
f;font-size:18.048px" dir=3D"auto">Am I missing something here, or does Luk=
e's suggested 2MB cap completely nullify that expected linear increase?=
If so, why? What's the logic behind this decision?</div><div style=3D"=
font-family:sans-serif;font-size:18.048px" dir=3D"auto"><br></div><div styl=
e=3D"font-family:sans-serif;font-size:18.048px" dir=3D"auto">I'd love t=
o be armed with a good answer should my colleagues ask me the same obvious =
question, so thank you ahead of time!</div><div style=3D"font-family:sans-s=
erif;font-size:18.048px" dir=3D"auto"><br></div><div style=3D"font-family:s=
ans-serif;font-size:18.048px" dir=3D"auto">Respectfully,</div><div style=3D=
"font-family:sans-serif;font-size:18.048px" dir=3D"auto">Oliver Petruzel</d=
iv><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"auto"><b=
r></div><div style=3D"font-family:sans-serif;font-size:18.048px" dir=3D"aut=
o"><br></div></div>
--001a113ad55e5735940550b25887--
|
