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
172
173
174
175
176
|
Return-Path: <tomas@tomasvdw.nl>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id AD8B4259
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 08:34:12 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
[66.111.4.25])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id C92961E2
for <bitcoin-dev@lists.linuxfoundation.org>;
Wed, 24 May 2017 08:34:11 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.42])
by mailout.nyi.internal (Postfix) with ESMTP id 1AD4A20819;
Wed, 24 May 2017 04:34:11 -0400 (EDT)
Received: from web3 ([10.202.2.213])
by compute2.internal (MEProxy); Wed, 24 May 2017 04:34:11 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:content-transfer-encoding:content-type
:date:from:in-reply-to:message-id:mime-version:references
:subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; bh=r9ECIA
WG0mnowX2mxrfHuAUgfLTuxP6hJdDGN6XCKCY=; b=mNiIE+RtST6s7ETsoRUSY/
7sLC8ltz0nbezSZeXhCAivw1nB4xetU1S0ORNswWW9kW/YFpqLEtIXUJ4hZ+tVXs
t99M0U3c1pmViF74pqKjDtwvMaGGMOsEfTP8ItVg0vQ8jP3eHU3ULWJZVyWM9F2Y
u74cvbi+OwVL/zQZiI76no3NWJTjGZ5yuDeCX9g/wUrWi0DgVC3pn9nc+T9MrgLi
xzIFBPbPYJV8SIj8qPJlyzJWxEeIx9Oj/Sqtz7JJdd+JhxGGY6UiRI84Ec7nYMwo
qcu1nh2CTObTy6WMadz1dR8NoF3sQObu0LTNlhSdTL+gDccxV5H50FIHK9N6R2eA
==
X-ME-Sender: <xms:g0UlWXI9OG0vx81jc1muCZ0wbdnOpzxq54X-R_N1eHk27SRvQ2tbIA>
Received: by mailuser.nyi.internal (Postfix, from userid 99)
id EB5AE9ED21; Wed, 24 May 2017 04:34:10 -0400 (EDT)
Message-Id: <1495614850.2407540.986853224.2FB087C6@webmail.messagingengine.com>
From: Tomas <tomas@tomasvdw.nl>
To: erik@q32.com
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Type: multipart/alternative; boundary="_----------=_149561485024075403"
X-Mailer: MessagingEngine.com Webmail Interface - ajax-a5162694
Date: Wed, 24 May 2017 10:34:10 +0200
References: <1495536637.1801543.985680712.6B788409@webmail.messagingengine.com>
<CAJowKgJs-cVR7w1QvSKr+ZXeQd4giq-aGLOEktqHn3a83tNGBA@mail.gmail.com>
In-Reply-To: <CAJowKgJs-cVR7w1QvSKr+ZXeQd4giq-aGLOEktqHn3a83tNGBA@mail.gmail.com>
X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID,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
X-Mailman-Approved-At: Wed, 24 May 2017 10:01:25 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Proposal to allow users to configure the maximum
block weight based on a support threshold
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: Wed, 24 May 2017 08:34:12 -0000
This is a multi-part message in MIME format.
--_----------=_149561485024075403
Content-Transfer-Encoding: 7bit
Content-Type: text/plain; charset="utf-8"
On Wed, May 24, 2017, at 04:42, Erik Aronesty wrote:
> Instead of block thresholds, use utxo bits to coordinate size changes
> (larger and smaller should be allowed).>
> There is no reason for miners to be involved in a decision to change
> this aspects of the protocol. Plenty of other ways to coordinate.
Miners cannot change the block size or any other rule without support of
the users, because their blocks and coins would be rejected. This
mechanism that Bitcoin brought us, has been working fine and I see no
reason to change it with utxo bits.
I *only* propose an optional way to synchronize changes without the
need of off chain agreements, which seems like a simple improvement over
the current situation.
>
> Otherwise someone can make it seem to a miner like 99pct of nodes are
> ready for a larger weight.... even though that's false.
I agree that the user agent signalling isn't very important, and I think
that most of us aware that you cannot rely on counting them.
>
> On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" <bitcoin-
> dev@lists.linuxfoundation.org> wrote:>> I have a proposal that would allow each user to optionally
>> configure the>> maximum block weight at a support threshold.
>>
>> It recognizes that there is no need for off chain bickering, by
>> providing a mechanism that lets each users freely choose their own
>> parameters while still maintaining full coordination of any changes.>>
>> The BIP can be found here:
>>
>> https://github.com/tomasvdw/bips/blob/master/bip-changing-the-maximum-block%20weight-based-on-a-support-threshold.mediawiki>>
>> It is worth noting that this proposal does neither gives more
>> power to>> miners nor reduces decentralization. Miners still rely on their
>> blocks>> being accepted by economic nodes to sell their minted coins. This
>> proposal doesn't change that.
>>
>> Regards,
>> Tomas van der Wansem
>> bitcrust
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--_----------=_149561485024075403
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="utf-8"
<!DOCTYPE html>
<html>
<head>
<title></title>
</head>
<body><div><br></div>
<div>On Wed, May 24, 2017, at 04:42, Erik Aronesty wrote:<br></div>
<blockquote type="cite"><div><div>Instead of block thresholds, use utxo bits to coordinate size changes (larger and smaller should be allowed).<br></div>
<div><br></div>
<div><div>There is no reason for miners to be involved in a decision to change this aspects of the protocol. Plenty of other ways to coordinate.<br></div>
</div>
</div>
</blockquote><div><br></div>
<div>Miners cannot change the block size or any other rule without support of the users, because their blocks and coins would be rejected. This mechanism that Bitcoin brought us, has been working fine and I see no reason to change it with utxo bits.<br></div>
<div><br></div>
<div>I *only* propose an optional way to synchronize changes without the need of off chain agreements, which seems like a simple improvement over the current situation. <br></div>
<div><br></div>
<div><br></div>
<blockquote type="cite"><div><div><div><br></div>
<div>Otherwise someone can make it seem to a miner like 99pct of nodes are ready for a larger weight.... even though that's false.<br></div>
</div>
</div>
</blockquote><div><br></div>
<div>I agree that the user agent signalling isn't very important, and I think that most of us aware that you cannot rely on counting them. <br></div>
<div><br></div>
<blockquote type="cite"><div><div><br></div>
<div defang_data-gmailquote="yes"><div>On May 23, 2017 8:03 AM, "Tomas via bitcoin-dev" <<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wrote:<br></div>
<blockquote defang_data-gmailquote="yes" style="margin-top:0px;margin-right:0px;margin-bottom:0px;margin-left:0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204, 204, 204);padding-left:1ex;"><div>I have a proposal that would allow each user to optionally configure the<br></div>
<div> maximum block weight at a support threshold.<br></div>
<div> <br></div>
<div> It recognizes that there is no need for off chain bickering, by<br></div>
<div> providing a mechanism that lets each users freely choose their own<br></div>
<div> parameters while still maintaining full coordination of any changes.<br></div>
<div> <br></div>
<div> The BIP can be found here:<br></div>
<div> <br></div>
<div> <a href="https://github.com/tomasvdw/bips/blob/master/bip-changing-the-maximum-block%20weight-based-on-a-support-threshold.mediawiki">https://github.com/tomasvdw/<wbr>bips/blob/master/bip-changing-<wbr>the-maximum-block%20weight-<wbr>based-on-a-support-threshold.<wbr>mediawiki</a><br></div>
<div> <br></div>
<div> It is worth noting that this proposal does neither gives more power to<br></div>
<div> miners nor reduces decentralization. Miners still rely on their blocks<br></div>
<div> being accepted by economic nodes to sell their minted coins. This<br></div>
<div> proposal doesn't change that.<br></div>
<div> <br></div>
<div> Regards,<br></div>
<div> Tomas van der Wansem<br></div>
<div> bitcrust<br></div>
<div> ______________________________<wbr>_________________<br></div>
<div> bitcoin-dev mailing list<br></div>
<div> <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br></div>
<div> <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br></div>
</blockquote></div>
</div>
</blockquote><div><br></div>
</body>
</html>
--_----------=_149561485024075403--
|
