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
|
Return-Path: <jtimon@jtimon.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 0B9096C
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Apr 2017 04:57:51 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-ua0-f172.google.com (mail-ua0-f172.google.com
[209.85.217.172])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 18FDAA4
for <bitcoin-dev@lists.linuxfoundation.org>;
Sun, 2 Apr 2017 04:57:49 +0000 (UTC)
Received: by mail-ua0-f172.google.com with SMTP id d64so13385881uad.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 01 Apr 2017 21:57:49 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=jtimon-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:in-reply-to:references:from:date:message-id:subject:to
:cc:content-transfer-encoding;
bh=0hLZZHB7npnvHBGTi6kI2mWUA/JU5KeKBORhl4u6ZTs=;
b=nQt76o6lyAqqusefIcdBbEFYjN5A9rgxlKblVpIo6L4WMZscPaA4wTmQuYKgjNqeLk
h8bGkiRipolTmLTBnup411s362OMPCO+6rNh8O5xPGkfPu1DjENUTcA+c8gHdTGJRFSO
Jas8eGnZWJpUHBAAUbPZTO5++DxNvFOZm7X2r8rSLHONYHWW2SOSztxofbkJ4oC9+OZL
yBLrb4Wf2L4cn7+oycnOcTuQvWDmarpmSajmznXB2rke4qO4ffvy4ltfWBY89K4umkML
52bK1l0njCNSLPwAF/JyGebDiPuCjxJmmO30aY8bfszSVLpzAvPk28iv2NLTj6VAj2Xj
nG+A==
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=0hLZZHB7npnvHBGTi6kI2mWUA/JU5KeKBORhl4u6ZTs=;
b=HiLFzBP1Lmsb8WN5XCDkPwlW7x1jnWY6H/92ofpWdAIoj1+Zwkf+BYhZ8KgxNwhi/K
D5cbYfgCn29uRYYHUHRVbpu87tmNg1gAmNOOxyoVhFNUa9ouMOZNeM9F7WUST9QDI4uf
XerPKqq9Trm2l8mZus2NWqzBY1a5hhCpqYo5fQA8+mhCftraefPgFCCevcAv2doCST+3
K8kfd2z8NsOAxFLIQXtorrkA++ygQCbgIAIfXQDHwn7GDxnq4P4diax1NG2xfX1HycxZ
cIRqmlFSGDqXH5Ch4p4R2W+JMkutNFLYlnZcLeQs3k1WknR16uxn9s+CRxFtjbYa/hEj
enCA==
X-Gm-Message-State: AFeK/H0Zis1B7uCWZoGV/jsVfwnHTY2rrDE5p7dQ2vFTo4nMjrgOr5lLFY/6LzEJnHEi3UFFT3bAXJbBeG4yJQ==
X-Received: by 10.159.48.81 with SMTP id i17mr5567062uab.65.1491109069012;
Sat, 01 Apr 2017 21:57:49 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.31.151.136 with HTTP; Sat, 1 Apr 2017 21:57:48 -0700 (PDT)
In-Reply-To: <CAAt2M1835S3YYJ_p0_zvDR9U6EfYAt7SWTAEPNHnNfgstKpgMg@mail.gmail.com>
References: <CAKzdR-oN6tGvGSb04_awCf=Jsf3wgKJN5xUhCr8G2D2W9YgJww@mail.gmail.com>
<1CF1FD5D-8D29-4783-823F-B3F588D5C5CE@mattcorallo.com>
<CAD1TkXse5O6nEw9-EPsNp4c56YJ+OnM=F1uf8w+tyB=_+hFzFQ@mail.gmail.com>
<CAKzdR-rFJNOZ856rA_q8C=zEUj_X561OSOwW+KZr4nRJ51w3HA@mail.gmail.com>
<CABm2gDrAHo2P7t6SjituURqMUqs_=Lbp7X=g_j8nGoNKMKCRKQ@mail.gmail.com>
<CAAt2M19PvHLY0PA6iy+wiPg10vqONDApTLDuxzEcte=KUZLoaQ@mail.gmail.com>
<CABm2gDqw2TayGvaH_nz3jrF8Cz2V=SbB4begD6+K=Ye=Msw4mg@mail.gmail.com>
<CAAt2M1_gDzEuDLSvVsJARvdCAtUyM3Yuu7TT25sbm3L-Zi6+0Q@mail.gmail.com>
<CAAt2M18=Tjw+05QCv6G7Abv=idB6ONgU9xvtrR=fn731452_mg@mail.gmail.com>
<CAAt2M1835S3YYJ_p0_zvDR9U6EfYAt7SWTAEPNHnNfgstKpgMg@mail.gmail.com>
From: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= <jtimon@jtimon.cc>
Date: Sun, 2 Apr 2017 06:57:48 +0200
Message-ID: <CABm2gDqMGBiwZppcyt6yF2sMJVs=nCr0M8u4H_22QDMR3wCFxQ@mail.gmail.com>
To: Natanael <natanael.l@gmail.com>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-0.2 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,RCVD_IN_DNSWL_NONE,URIBL_BLACK autolearn=no version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Segwit2Mb - combined soft/hard fork - Request For
Comments
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: Sun, 02 Apr 2017 04:57:51 -0000
On Sat, Apr 1, 2017 at 5:34 PM, Natanael <natanael.l@gmail.com> wrote:
> Den 1 apr. 2017 16:07 skrev "Jorge Tim=C3=B3n" <jtimon@jtimon.cc>:
> On Sat, Apr 1, 2017 at 3:15 PM, Natanael <natanael.l@gmail.com> wrote:
>> Den 1 apr. 2017 14:33 skrev "Jorge Tim=C3=B3n via bitcoin-dev"
>> <bitcoin-dev@lists.linuxfoundation.org>:
>> Segwit replaces the 1 mb size limit with a weight limit of 4 mb.
>> That would make it a hardfork, not a softfork, if done exactly as you sa=
y.
> No, because of the way the weight is calculated, it is impossible to
> create a block that old nodes would perceive as bigger than 1 mb
> without also violating the weight limit.
> After segwit activation, nodes supporting segwit don't need to
> validate the 1 mb size limit anymore as long as they validate the
> weight limit.
>
> https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Block_size
>
> Huh, that's odd. It really does still count raw blockchain data blocksize=
.
It's not odd, it's just counter-intuitive. How can "< 4 mb weight" be
a more restrictive rule than "< 1 mb size"? Well, it is, that's why
segwit's size increase is a softfork.
It is not that hard once you look at the actual weight formula:
segregated_sigs_sise + (other_size * 4) < 4 "mb"
It is impossible to produce to produce a block that violates the 1 mb
size limit but doesn't violate the 4 mb weight limit too.
There can be block that are < 1 mb size but 20 mb in weight, but those
are invalid according to the new 4 mb weight rule.
At the same time, any block that violates the < 1 mb rule for old
nodes will be invalid not only to old nodes but also to any node
validating the new 4mb rule. This is not by chance but a design choice
for any block size increase within segwit to remain a softfork, which
is what can be deployed faster.
One extreme example would be any 1 mb block today. 1 "mb" of a block
today times 4 is 4 mb, so it complies with the new 4 mb weight rule.
The opposite extreme example would be 4 mb of signatures and 0 mb of
"other data", but this example is not really possible in practice
because signatures need some tx to be part of to be part of the block
itself.
The most extreme examples I have seen on testnet are 3.7 mb blocks,
but those don't represent the average usage today (whenever you read
this).
One common misunderstanding is that users who aren't using payment
channels (that includes lightning but also other smart contracts) or
users that aren't using mutlisig can't enjoy the so called "discount":
there's no reasonable argument for rejecting the "discount" on your
own transactions once/if segwit gets activated.
I would prefer to call the absence of "discount" *penalization*.
Signatures are unreasonable penalized pre-segwit, and there's more
things that remain unreasonably penalized with respect to their
influence on the current utxo after segwit. But signatures are by far
the biggest in data space and validation time, and the most important
unreasonable yet unintended penalization pre-segwit.
> It just uses a ratio between how many units each byte is worth for block
> data vs signature data, plus a cap to define the maximum. So the current =
max
> is 4 MB, with 1 MB of non-witness blockchain data being weighted to 4x =
=3D 4
> MB. That just means you replaced the two limits with one limit and a rati=
o.
Exactly, once one maximum limit is defined, no need for two limits.
But the current max is 1 mb size, not 4 mb weight until/unless segwit
is activated.
Some people complain about 4 mb weight not being as much as 4 mb size,
and that is correct, but both are bigger than 1 mb size.
> A hardfork increasing the size would likely have the ratio modified too.
If the single ratio needs to be modified, it can be modified now
before any rule changes are activated, no need to change the consensus
rules more than needed.
> With exactly the same effect as if it was two limits...
If you don't see any disadvantage on having one single limit if/when
segwit gets activated, I don't see the point of maintaining two
limits, but if you're happy to maintain the branch with the redundant
one you may get my ack: I don't see any disadvantage on checking the
same thing twice besides performance,
> Either way, there's still going to be non-segwit nodes for ages.
That's precisely why it's good segwit has been designed to be backward
compatible as a bip9 softfork.
|
