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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <stephencalebmorse@gmail.com>) id 1YzzTK-0003jq-Md
for bitcoin-development@lists.sourceforge.net;
Wed, 03 Jun 2015 03:36:06 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.160.171 as permitted sender)
client-ip=209.85.160.171;
envelope-from=stephencalebmorse@gmail.com;
helo=mail-yk0-f171.google.com;
Received: from mail-yk0-f171.google.com ([209.85.160.171])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1YzzTJ-0007Rd-Rk
for bitcoin-development@lists.sourceforge.net;
Wed, 03 Jun 2015 03:36:06 +0000
Received: by yken206 with SMTP id n206so60091631yke.2
for <bitcoin-development@lists.sourceforge.net>;
Tue, 02 Jun 2015 20:36:00 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.236.0.161 with SMTP id 21mr32026075yhb.141.1433302560428;
Tue, 02 Jun 2015 20:36:00 -0700 (PDT)
Received: by 10.13.245.70 with HTTP; Tue, 2 Jun 2015 20:36:00 -0700 (PDT)
In-Reply-To: <CACrzPe=vNd8T0B4DGH3dTE9S9S1jEU9k6_5Uz_NUP1ZEgC8uYA@mail.gmail.com>
References: <CABHVRKSFV_dXZeLnhBLfRK=wrBFsRH5kFBZqwECh-LyCkwrmtQ@mail.gmail.com>
<CAM7BtUod0hyteqx-yj8XMwATYp73Shi0pvdcTrW0buseLGc_ZQ@mail.gmail.com>
<CABHVRKT7H1p67Bz_T_caaGFnfuswnC+kXKGdkpRhtXUZQv3HtQ@mail.gmail.com>
<CAM7BtUrN9D__ha63Qfs2Fi4HSUFWb8BArHni9yFKRSdLSxCNnA@mail.gmail.com>
<CABHVRKS5Mnp9vSJ6mZwNroY7jbBJx+4d+m4hVpWONisaMvBNUw@mail.gmail.com>
<CACrzPe=vNd8T0B4DGH3dTE9S9S1jEU9k6_5Uz_NUP1ZEgC8uYA@mail.gmail.com>
Date: Tue, 2 Jun 2015 23:36:00 -0400
Message-ID: <CABHVRKQbTa5SA=CpGK2+Fpqxo7V3VCRKVigMrEJ_PvUg5owPiQ@mail.gmail.com>
From: Stephen Morse <stephencalebmorse@gmail.com>
To: Vincent Truong <vincent.truong@procabiak.com>
Content-Type: multipart/alternative; boundary=089e016345c4f859a5051794c1c0
X-Spam-Score: -0.6 (/)
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 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(stephencalebmorse[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
1.0 HTML_MESSAGE BODY: HTML included in message
-0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from
author's domain
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1YzzTJ-0007Rd-Rk
Cc: bitcoin-development <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Max Block Size: Simple Voting Procedure
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: Wed, 03 Jun 2015 03:36:06 -0000
--089e016345c4f859a5051794c1c0
Content-Type: text/plain; charset=UTF-8
Vincent,
> Some changes:
>
> Votes need to be 100%, not 50.01%. That way small miners have a fair
> chance. A 50.01% vote means large miners call the shots.
>
While I like the idea of possibly requiring more than 50%, you wouldn't
want to have a situation where a minority of uncooperative (or just lazy)
miners don't add their votes and hold up progress. Maybe 2/3 instead of
1/2, though.
> Users (people who make transactions) need to vote. A vote by a miner
> shouldn't count without user votes. Fee incentives should attract
> legitimate votes from miners. A cheating miner will be defeated by another
> miner who includes those votes, and take the fees.
>
> This lets wallet providers and exchanges cast votes (few wallets will
> implement prompts and will just auto vote, so if you don't agree, switch
> wallets. Vote with your wallet).
>
The idea of voting with your wallet, while appealing, is technically
infeasible. Miners can fill their blocks with any type of transactions,
including their own specially designed transactions. And any fees from
these transactions can be collected right back into their coinbase
transaction.
- Stephen
--089e016345c4f859a5051794c1c0
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div>Vincent,</div><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-l=
eft-style:solid;padding-left:1ex"><p dir=3D"ltr">Some changes:</p>
<p dir=3D"ltr">Votes need to be 100%, not 50.01%. That way small miners hav=
e a fair chance. A 50.01% vote means large miners call the shots.</p></bloc=
kquote><div>While I like the idea of possibly requiring more than 50%, you =
wouldn't want to have a situation where a minority of uncooperative (or=
just lazy) miners don't add their votes and hold up progress. Maybe 2/=
3 instead of 1/2, though. =C2=A0=C2=A0<br></div><blockquote class=3D"gmail_=
quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-=
color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<p dir=3D"ltr">Users (people who make transactions) need to vote. A vote by=
a miner shouldn't count without user votes. Fee incentives should attr=
act legitimate votes from miners. A cheating miner will be defeated by anot=
her miner who includes those votes, and take the fees.</p>
<p dir=3D"ltr">This lets wallet providers and exchanges cast votes (few wal=
lets will implement prompts and will just auto vote, so if you don't ag=
ree, switch wallets. Vote with your wallet).</p></blockquote><div>The idea =
of voting with your wallet, while appealing, is technically infeasible. Min=
ers can fill their blocks with any type of transactions, including their ow=
n specially designed transactions. And any fees from these transactions can=
be collected right back into their coinbase transaction.=C2=A0</div><div><=
br></div><div>- Stephen</div></div></div></div>
--089e016345c4f859a5051794c1c0--
|
