summaryrefslogtreecommitdiff
path: root/b9/b2c2e3cbb3d68f6a2ac43478ef64499c1fe1c1
blob: f657f4a014cc3db8578279dc84db869af9f65630 (plain)
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
177
178
179
180
181
182
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
	helo=mx.sourceforge.net)
	by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
	(envelope-from <elombrozo@gmail.com>) id 1Z3VBn-0001Wf-R0
	for bitcoin-development@lists.sourceforge.net;
	Fri, 12 Jun 2015 20:04:31 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.217.175 as permitted sender)
	client-ip=209.85.217.175; envelope-from=elombrozo@gmail.com;
	helo=mail-lb0-f175.google.com; 
Received: from mail-lb0-f175.google.com ([209.85.217.175])
	by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
	(Exim 4.76) id 1Z3VBm-0002MG-AX
	for bitcoin-development@lists.sourceforge.net;
	Fri, 12 Jun 2015 20:04:31 +0000
Received: by lbbtu8 with SMTP id tu8so25152477lbb.2
	for <bitcoin-development@lists.sourceforge.net>;
	Fri, 12 Jun 2015 13:04:24 -0700 (PDT)
MIME-Version: 1.0
X-Received: by 10.152.5.65 with SMTP id q1mr16712689laq.110.1434139463966;
	Fri, 12 Jun 2015 13:04:23 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Fri, 12 Jun 2015 13:04:23 -0700 (PDT)
Received: by 10.112.53.5 with HTTP; Fri, 12 Jun 2015 13:04:23 -0700 (PDT)
In-Reply-To: <CABr1YTfowMqgDZoWhDXiM0Bd3dwhVo6++FOvLntGc2HkApEbGw@mail.gmail.com>
References: <20150612181153.GB19199@muck>
	<CAOG=w-up7-wp2NnK52jeCLvcSWvbC-iT-YRDoA=10QhU=K14-g@mail.gmail.com>
	<1466351.XXvDcu7nzO@crushinator>
	<CABeL=0g5Lq0zpwW2sHTbO+TTj84aJaDH=1wzeQdFVyhHf-QiSg@mail.gmail.com>
	<CABr1YTfowMqgDZoWhDXiM0Bd3dwhVo6++FOvLntGc2HkApEbGw@mail.gmail.com>
Date: Fri, 12 Jun 2015 13:04:23 -0700
Message-ID: <CABr1YTd0wcOC8+KSPCPHrx5Ob4nY3azed46gS+nR_NzmxDiTzw@mail.gmail.com>
From: Eric Lombrozo <elombrozo@gmail.com>
To: Jannes Faber <j.faber@elevate.nl>
Content-Type: multipart/alternative; boundary=089e013d17544ee52f0518579d53
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
	(elombrozo[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: 1Z3VBm-0002MG-AX
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [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 20:04:31 -0000

--089e013d17544ee52f0518579d53
Content-Type: text/plain; charset=UTF-8

Miners currently only collect an almost negligible portion of their revenue
from fees. While I certainly welcome any proposals that move us in the
direction of defining a smooth metaconsensus process, I think with the
curent economics, miners (and especially those with significant hashing
power) have more of an incentive to block txs/spam their votes than to
adapt to tx sender preferences...unless people increase their tx fees
significantly. But without wallets that can make decent suggestions in this
regard, this feature will be almost inaccessible to most regular users. And
the economics still aren't entirely clear.

- Eric Lombrozo
On Jun 12, 2015 12:30 PM, "Jannes Faber" <j.faber@elevate.nl> wrote:

I'm imagining in Peter's proposal it's not the transaction votes that are
counted but only the votes in the blocks? So miners get to vote but they
risk losing money by having to exclude counter voting transactions. But
garbage transactions are no problem at all.

Note that users that want to cast a vote "pay" for that by increased
confirmation time (on average, hopefully slightly depending on the trend).

On Fri, Jun 12, 2015, 20:27 Matt Whitlock <bip@mattwhitlock.name> wrote:

> On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:
> > Peter it's not clear to me that your described protocol is free of miner
> > influence over the vote, by artificially generating transactions which
> they
> > claim in their own blocks
>
> Miners could fill their blocks with garbage transactions that agree with
> their vote, but this wouldn't bring them any real income, as they'd be
> paying their own money as fees to themselves. To get real income, miners
> would have to vote in accordance with real users.
>
>
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

------------------------------------------------------------------------------

_______________________________________________
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--089e013d17544ee52f0518579d53
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Miners currently only collect an almost negligible portion o=
f their revenue from fees. While I certainly welcome any proposals that mov=
e us in the direction of defining a smooth metaconsensus process, I think w=
ith the curent economics, miners (and especially those with significant has=
hing power) have more of an incentive to block txs/spam their votes than to=
 adapt to tx sender preferences...unless people increase their tx fees sign=
ificantly. But without wallets that can make decent suggestions in this reg=
ard, this feature will be almost inaccessible to most regular users. And th=
e economics still aren&#39;t entirely clear.</p>
<p dir=3D"ltr">- Eric Lombrozo</p>
<div class=3D"gmail_quote">On Jun 12, 2015 12:30 PM, &quot;Jannes Faber&quo=
t; &lt;<a href=3D"mailto:j.faber@elevate.nl">j.faber@elevate.nl</a>&gt; wro=
te:<br type=3D"attribution"><blockquote class=3D"quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">I&#39;m=
 imagining in Peter&#39;s proposal it&#39;s not the transaction votes that =
are counted but only the votes in the blocks? So miners get to vote but the=
y risk losing money by having to exclude counter voting transactions. But g=
arbage transactions are no problem at all.</p>
<p dir=3D"ltr">Note that users that want to cast a vote &quot;pay&quot; for=
 that by increased confirmation time (on average, hopefully slightly depend=
ing on the trend).</p><div class=3D"elided-text">

<br><div class=3D"gmail_quote"><div dir=3D"ltr">On Fri, Jun 12, 2015, 20:27=
=C2=A0Matt Whitlock &lt;<a href=3D"mailto:bip@mattwhitlock.name" target=3D"=
_blank">bip@mattwhitlock.name</a>&gt; wrote:<br></div><blockquote class=3D"=
gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-=
left:1ex">On Friday, 12 June 2015, at 11:20 am, Mark Friedenbach wrote:<br>
&gt; Peter it&#39;s not clear to me that your described protocol is free of=
 miner<br>
&gt; influence over the vote, by artificially generating transactions which=
 they<br>
&gt; claim in their own blocks<br>
<br>
Miners could fill their blocks with garbage transactions that agree with th=
eir vote, but this wouldn&#39;t bring them any real income, as they&#39;d b=
e paying their own money as fees to themselves. To get real income, miners =
would have to vote in accordance with real users.<br>
<br>
---------------------------------------------------------------------------=
---<br>
_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net" target=3D"_bla=
nk">Bitcoin-development@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
</blockquote></div>
</div><br>-----------------------------------------------------------------=
-------------<br>
<br>_______________________________________________<br>
Bitcoin-development mailing list<br>
<a href=3D"mailto:Bitcoin-development@lists.sourceforge.net">Bitcoin-develo=
pment@lists.sourceforge.net</a><br>
<a href=3D"https://lists.sourceforge.net/lists/listinfo/bitcoin-development=
" rel=3D"noreferrer" target=3D"_blank">https://lists.sourceforge.net/lists/=
listinfo/bitcoin-development</a><br>
<br></blockquote></div>

--089e013d17544ee52f0518579d53--