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
|
Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193]
helo=mx.sourceforge.net)
by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1Z3TR1-0004CU-Eu
for bitcoin-development@lists.sourceforge.net;
Fri, 12 Jun 2015 18:12:07 +0000
Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.81 as permitted sender)
client-ip=62.13.149.81; envelope-from=pete@petertodd.org;
helo=outmail149081.authsmtp.net;
Received: from outmail149081.authsmtp.net ([62.13.149.81])
by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1Z3TQz-0003ii-Sq for bitcoin-development@lists.sourceforge.net;
Fri, 12 Jun 2015 18:12:07 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt18.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5CIBxP3051267
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Jun 2015 19:11:59 +0100 (BST)
Received: from muck ([85.255.235.202]) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id t5CIBr09091936
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO)
for <bitcoin-development@lists.sourceforge.net>;
Fri, 12 Jun 2015 19:11:58 +0100 (BST)
Date: Fri, 12 Jun 2015 14:11:53 -0400
From: Peter Todd <pete@petertodd.org>
To: bitcoin-development@lists.sourceforge.net
Message-ID: <20150612181153.GB19199@muck>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="JgQwtEuHJzHdouWu"
Content-Disposition: inline
X-Server-Quench: 8479a812-112e-11e5-b396-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVJwpGK10IU0Fd
P1hXKl1LNVAaWXld WiVPGEoXDxgzCjYj NEgGOBsDNw4AXgd1
Kg0XXVBSFQB4ABUL Bx8UVxA8fwBYent1 e0RhW25ZXEZlcE56
XU8aUWh1HBUiaGkf WUFRdAUadQBIelFN bld2BXsMY3gGZ3g1
WlZqMm10N24OdmEN GltQfAobGBsHF2Eq egsPB30xGlEIDyQ1
ZxYiLVUfB0cDPw0u MUEmRF0YexEfBxY2
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 85.255.235.202/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.5 (-)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1Z3TQz-0003ii-Sq
Subject: [Bitcoin-development] User vote in blocksize through fees
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Fri, 12 Jun 2015 18:12:07 -0000
--JgQwtEuHJzHdouWu
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Jeff Garzik recently proposed that the upper blocksize limit be removed
entirely, with a "soft" limit being enforced via miner vote, recorded by
hashing power.
This mechanism within the protocol for users to have any influence over
the miner vote. We can add that back by providing a way for transactions
themselves to set a flag determining whether or not they can be included
in a block casting a specific vote.
We can simplify Garzik's vote to say that one of the nVersion bits
either votes for the blocksize to be increased, or decreased, by some
fixed ratio (e.g 2x or 1/2x) the next interval. Then we can use a
nVersion bit in transactions themselves, also voting for an increase or
decrease. Transactions may only be included in blocks with an
indentical vote, thus providing miners with a monetary incentive via
fees to vote according to user wishes.
Of course, to cast a "don't care" vote we can either define an
additional bit, or sign the transaction with both versions. Equally we
can even have different versions with different fees, broadcast via a
mechanism such as replace-by-fee.
See also John Dillon's proposal for proof-of-stake blocksize voting:
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg0=
2323.html
--=20
'peter'[:-1]@petertodd.org
0000000000000000127ab1d576dc851f374424f1269c4700ccaba2c42d97e778
--JgQwtEuHJzHdouWu
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQGrBAEBCACVBQJVeyDmXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw
MDAwMDAwMDAwMDAwMDAxMjdhYjFkNTc2ZGM4NTFmMzc0NDI0ZjEyNjljNDcwMGNj
YWJhMmM0MmQ5N2U3NzgvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0
ZUBwZXRlcnRvZC5vcmcACgkQwIXyHOf0udzZCAf/aO4aTReWOn7nUwFiVbcirC/G
LTYLE4H+5xNgL9eJ6IHCaVHYlKapTQp5h0lChFIuTcX+whTXjz9EN3UNYs6umSOa
hpfEtjz0OHWSRwKK+sXHqT82FvS74jGCs5XNBoCN5DzOfFA6+Urw/GniHed5YrJV
HM9RkFCohgBmJat032eys7cu0mxidA6AFPeHoWR+p6UXNkuuuU5XmP9rrVK5Turj
RZtayZujttK+NzxTp3M1nmF32wFyWze0Mz4lYuTckr/7WKxonjI5s6RJcQ7xYEwh
6Oihs+FJsQcKW2Fwu/XSZnBHhuhwVqn0JT7CRP07U+dJBI1mQTMThzNa6RRflQ==
=TLlE
-----END PGP SIGNATURE-----
--JgQwtEuHJzHdouWu--
|
