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
|
Return-Path: <jaredr26@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 82C97B62
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Jun 2017 19:40:39 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f178.google.com (mail-ua0-f178.google.com
[209.85.217.178])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id A2F7E257
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 2 Jun 2017 19:40:37 +0000 (UTC)
Received: by mail-ua0-f178.google.com with SMTP id x47so50465939uab.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 02 Jun 2017 12:40:37 -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:content-transfer-encoding;
bh=qdWtv5pF7WET/L2s8libF7R60lx09c7SOu9Ut9cRrBI=;
b=TJAH/McayH/8ctlKwcqseWKFl+HNx/alMwZ/9pbLc+ngci+UVNxqgq/Vzth36zshnx
zI+OKJ9CYWqEjGYJBWD12x/AYPUt2XZXO4dXs9zRGh/wk5WZyi4K/SLJaTlTqdnFpEJ+
7qJHKKQFU7g8HnBB1HZJRa6dBElonjcmfAXavNg16YeE/t7T9CL6rYM0rvswKF97efRJ
W6Z1aZWAWo4xOlLF7Mb/g/F3LE9mDG9pfIqwUhmM4iJXhnUVh0W2YAFeceTR/hkEhti+
79MtNVML4W8FBFQ3mZgKV/SPtAo1kCmn3CnUuSQoG6MVDaV/4aq41M/QYXGr+Z3Zo61G
0lAg==
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:content-transfer-encoding;
bh=qdWtv5pF7WET/L2s8libF7R60lx09c7SOu9Ut9cRrBI=;
b=BoIJMQMpNMlZbusv9m4flXmTalEhfw0VTkG0T6Xnoh/9Xna73HFSC9HkLcAobUlXZH
DnkoX0+iPhiCYbVUyOEmxEgxWOTfdGnJXJ6ZeERjzvWeSR7vOhZXD4sVGhOW5lqfEL2G
UO3vpw9RfZbKouxQ1sakDOWOeyH3M6XIdzurSlj4T6ZPKze7RGRZuLz+P6B3AP6WN8OM
O7zTtBcme/fgH/2I/kIbOCebCd2HqGBblGJT4wRoZrf5yhzv27sYZRObA4nC0HRYU12q
Slzmp6GZODJaKcj7n0kguY4tuRjjte/CBc/ae+Y7t//2QIU8+PGGM1B1kGY6KnQ0diTp
dKbA==
X-Gm-Message-State: AODbwcDI+EIbsAK1XSIW8odgcbs0D1YVY32YyjoMgwhOfpxeGr2YzKSl
D8tkgdLkFuu7Z0Ra6vO9M8v3qQ1PtA==
X-Received: by 10.176.25.99 with SMTP id u35mr4739122uag.16.1496432436782;
Fri, 02 Jun 2017 12:40:36 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.157.215 with HTTP; Fri, 2 Jun 2017 12:40:36 -0700 (PDT)
In-Reply-To: <CAAUaCyjbObcb1mJVmeEDmgzNddQCY3QhrHV3fgNbin-ZyqgfeA@mail.gmail.com>
References: <201705232023.40588.luke@dashjr.org>
<CAJowKgJK9zBkVAM1NyOsjU04gvwV3zGnk+1ebfpt6rnbiKy6Og@mail.gmail.com>
<CABm2gDpet31gEcBY6NTxEG+xA4rvg8_c79L+J=mJySGbf7Ydbg@mail.gmail.com>
<CAOG=w-uei5-c-Mpp_R6RrN29NTrSV+gpNd79FC3cB6QPG65sEw@mail.gmail.com>
<CAH+Axy5yYQywpy0s9pBZt_fNoLPpWfra-cU9HrUwH71GDOchsQ@mail.gmail.com>
<004E1123-8346-48B6-9BCB-94BAE00EC34B@me.com>
<CAAUaCyjbObcb1mJVmeEDmgzNddQCY3QhrHV3fgNbin-ZyqgfeA@mail.gmail.com>
From: Jared Lee Richardson <jaredr26@gmail.com>
Date: Fri, 2 Jun 2017 12:40:36 -0700
Message-ID: <CAD1TkXtut2LZdp5Qo9ep2FfMGFFYqdxtobLJgoC7UutyNujKKg@mail.gmail.com>
To: Jacob Eliosoff <jacob.eliosoff@gmail.com>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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,
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: Fri, 02 Jun 2017 21:26:58 +0000
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Hypothetical 2 MB hardfork to follow BIP148
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: Fri, 02 Jun 2017 19:40:39 -0000
> Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has q=
uadratic hashing risks, and maybe James' 10KB is too ambitious; but even if=
so, a simple 1MB tx size limit would clearly do the trick. The broader po=
int is that quadratic hashing is not a compelling reason to keep blockmaxsi=
ze post-HF: does someone have a better one?
I think this is exactly the right direction to head. There are
arguments to be made for various maximum sizes... Maybe the limit
could be set to 1mb initially, and at a distant future block
height(years?) automatically drop to 500kb or 100kb? That would give
anyone with existing systems or pre-signed transactions several years
to adjust to the change. Notification could (?possibly?) be done with
a non-default parameter that must be changed to continue to use 100kb
- <1mb transactions, so no one running modern software could claim
they were not informed when that future date hits.
I don't see any real advantages to continuing to support transactions
larger than 100kb excepting the need to update legacy use cases /
already signed transactions.
On Tue, May 30, 2017 at 8:07 PM, Jacob Eliosoff via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> Maybe there's some hole in Jorge's logic and scrapping blockmaxsize has
> quadratic hashing risks, and maybe James' 10KB is too ambitious; but even=
if
> so, a simple 1MB tx size limit would clearly do the trick. The broader
> point is that quadratic hashing is not a compelling reason to keep
> blockmaxsize post-HF: does someone have a better one?
>
>
>
> On May 30, 2017 9:46 PM, "Jean-Paul Kogelman via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> That would invalidate any pre-signed transactions that are currently out
>> there. You can't just change the rules out from under people.
>>
>>
>> On May 30, 2017, at 4:50 PM, James MacWhyte via bitcoin-dev
>> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>
>>>
>>> The 1MB classic block size prevents quadratic hashing
>>> problems from being any worse than they are today.
>>>
>>
>> Add a transaction-size limit of, say, 10kb and the quadratic hashing
>> problem is a non-issue. Donezo.
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
|
