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
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
|
Return-Path: <andrew.baine@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 12520941
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 14:57:22 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-it0-f51.google.com (mail-it0-f51.google.com
[209.85.214.51])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id F29ED24E
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 14:57:20 +0000 (UTC)
Received: by mail-it0-f51.google.com with SMTP id 76so13409742itj.0
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 07:57:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:references:in-reply-to:from:date:message-id:subject:to;
bh=QxJKF4KsHtvzUteEiiDmmbLBpEQBOuAxQKY64mRYDTw=;
b=sLjnYNVRyS9wuDsFhZIIPP/G82CsOIj8hreBXHa99Qvx+qtxLYw2/5mhuevZVCKdzq
/PqjYLeOX5yvmI6YhkTrr00CuvDzGCFqWwOb5g1yS6PgQ2sGL0Vndcl1r3//An9dsJR6
mQGk6fYupr2eoSxfOnLvW4QTeSKgs6baWmpzkUnZ8Xm+qBnhVzupqkcx59GJ3FZ8j9w5
VuLvXmFWrHpKBeWMP2MrvaTmPnijXVYik/VJ85UvTfssaUMBE+AV7+uoGW01F7CHSM5E
1QZATFs8hIxHBwi6swxdiBROtRV01B60POulxP0/UVsarmDSAqa5DSbAFshNAVXYeTSa
RHjw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:references:in-reply-to:from:date
:message-id:subject:to;
bh=QxJKF4KsHtvzUteEiiDmmbLBpEQBOuAxQKY64mRYDTw=;
b=NmFb5zAFzxnbjUSqWhpzcPvDU2XSGFlZq0joQfEbW/TDqv7PELxFKfy3+Twh9hLzhO
B5MXWAulr3EVU4mbAWRqObFDMHnTErzGywbbEGHmlbP8+lSe6EfNQQ9thhCAQy9AwIl+
o2bkLrHObKF4f2PEj8NQ3DlTO6Rck+f12z9D34iDwTp1934i2fKz4xjeR1EC/K7w2wU3
f2HfixfFBN+0lVmM8B2Blc657Iy8Z1mUtmdsoG8lAZ+KR6gKFzZbhnllNMFv/qQFFrxO
UUasQKMs5InfnQzi2kxNXwn8wd93yTG3ZW6uuvMS7jOASmxPM0Z9sP0J4BRLVD8dGVAv
zCSw==
X-Gm-Message-State: AFeK/H1yj8CA4tdYmC+K+1BlaltFeLSum7y/R11xErjetI/PzucwKMsbSfvCuOp37qZY7v5ZqDoKGZrD/qQSDQ==
X-Received: by 10.36.130.133 with SMTP id t127mr15010670itd.36.1490713040278;
Tue, 28 Mar 2017 07:57:20 -0700 (PDT)
MIME-Version: 1.0
References: <CAOyfL0pN8Z8XSvHAXkG2=ic=J6m-8B5K2d=_eL=84Dnox3ovMQ@mail.gmail.com>
In-Reply-To: <CAOyfL0pN8Z8XSvHAXkG2=ic=J6m-8B5K2d=_eL=84Dnox3ovMQ@mail.gmail.com>
From: Andrew Baine <andrew.baine@gmail.com>
Date: Tue, 28 Mar 2017 14:57:09 +0000
Message-ID: <CAJxsMusFEDmT4YLhMJT0a6S=Mm0rfNGp6U5QRKApK6KJXU0cLg@mail.gmail.com>
To: Martin Stolze <martin@stolze.cc>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=94eb2c0891483a9332054bcbad07
X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
RCVD_IN_DNSWL_NONE,
RCVD_IN_SORBS_SPAM autolearn=no 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, 29 Mar 2017 13:48:57 +0000
Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
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: Tue, 28 Mar 2017 14:57:22 -0000
--94eb2c0891483a9332054bcbad07
Content-Type: text/plain; charset=UTF-8
The bitcoin ecosystem is better off the more transactions are propogated
peer-to-peer than directly to miners. We want miners listening to the
network, not soliciting transactions directly from users. You whispering
your transactions to your miner-of-choice while I whisper to mine
contravenes a critical value-add of the peer-to-peer network in my opinion.
On Tue, Mar 28, 2017 at 10:35 AM Martin Stolze via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Hi AJ,
> That's outstanding. I am glad to see that there is actually somebody
> who has made some progress.
>
> > "miners as service providers."
> Great idea! Block space as a resource is under-analyzed.
>
> > miner/pool's political positions, their consensus ideology, physical
> location (yes some people would like only miners in particular countries to
> mine their transactions)
>
> I am not joking when I say that in 3 to 8 years, I want to be able to
> verify my transaction through green blocks that are generated locally
> by my neighbor through the excess capacity of his solar panels or by
> an NGO pool that promotes solar deployment around the equator.
>
> > The main attitude right now is that people would like to 'support'
> miners who signal for the features they care about.
>
> Yes, just selecting all SegWit signaling hash power instead of picking
> individual Authorities would be helpful on preferredminer.com
>
> > I strongly believe, whether the Bitcoin developer community facilitates
> it or not, certain miners will become preferred by users.
>
> Absolutely, considering the recent language used in opinions by the
> ECB and drafts by the EU I see them assembling the artillery. I
> wouldn't be surprised if they start target practice next year. That
> will mean that commercial interest must have a way to transact on
> somewhat regulated space.
>
> > 1) By creating 'segregated mempools' where an authenticated third-party
> like my web service Preferred Miner manages the access to pending
> transactions destined for a specific set of miners
>
> I would call it regulated block space or regulated consensus space. I
> hope that we can do that on a deeper level, as part of the p2p
> protocol layer.
>
> > 2) by creating transactions where the mining fee is in one way or
> another, an output to an address owned by the preferred miner(s).
>
> That's a distinct function, e.g. at least some communities charge a tax.
> [1]
> I fear it is more likely that a business, say Coinbase, will approach
> a "miner" and just say "we pay 100 USD for a KB to your bank account,
> here are our transactions with no fee". It will literally be an
> off-chain fee. That's what I mean by "secondary market". This would be
> one of the least appealing scenarios.
>
> > There are some terrible pitfalls with both of these methods. [...]
>
> Spot on, that's why this should receive some attention before it
> becomes urgent. I think there is much more to it that we are missing
> at the moment, e.g. Tom: "Using xthin/compact blocks miners only send
> a tiny version of a block which then causes the receiving node to
> re-create it using the memory pool."
>
>
> [1] http://thebitcoin.foundation/declaration.txt
>
>
>
> > From: AJ West <ajwest@gmail.com>
> > To: bitcoin-dev@lists.linuxfoundation.org
> > Cc:
> > Bcc:
> > Date: Mon, 27 Mar 2017 12:29:20 -0400
> > Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
> > Hi I'm AJ West, I made a service http://preferredminer.com which is a
> proof-of-concept project designed to spur discussion on exactly this issue
> of "miners as service providers."
> >
> > The current status is that Bitcoin end users are looking to support
> specific miners, whether that's because they agree with a miner/pool's
> political positions, their consensus ideology, physical location (yes some
> people would like only miners in particular countries to mine their
> transactions) and the list of reasons goes on. The main attitude right now
> is that people would like to 'support' miners who signal for the features
> they care about.
> >
> > I strongly believe, whether the Bitcoin developer community facilitates
> it or not, certain miners will become preferred by users. In summary, there
> are realistically two proposed ways of providing this service in the
> present-day situation: 1) By creating 'segregated mempools' where an
> authenticated third-party like my web service Preferred Miner manages the
> access to pending transactions destined for a specific set of miners, and
> 2) by creating transactions where the mining fee is in one way or another,
> an output to an address owned by the preferred miner(s).
> >
> > There are some terrible pitfalls with both of these methods. The first
> being that you have to trust a lot of people, including the 3rd party (me)
> and the pools to work in your users' interest ("don't give my transactions
> to other miners or broadcast to mempool please"). Then there are the extra
> fees users will have to pay to offset the risk of a miner losing out for
> having to send the network a not-yet-broadcasted transaction. And finally,
> the other method requires that they be larger transactions, and a directory
> of mining pools' receiving addresses for outputs must be maintained. Then
> you have to hope the miner will be setup to scoop in your transaction
> knowing it's got a fee for them. Plus, how many nodes going forward are
> going to hold what seem to be 0-fee transactions in mempool (because the
> fee is in the outputs)?
> >
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
--94eb2c0891483a9332054bcbad07
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr">The bitcoin ecosystem is better off the more transactions =
are propogated peer-to-peer than directly to miners. We want miners listeni=
ng to the network, not soliciting transactions directly from users. You whi=
spering your transactions to your miner-of-choice while I whisper to mine c=
ontravenes a critical value-add of the peer-to-peer network in my opinion.<=
/div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Tue, Mar 28, 2017 a=
t 10:35 AM Martin Stolze via bitcoin-dev <<a href=3D"mailto:bitcoin-dev@=
lists.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>> wr=
ote:<br></div><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;=
border-left:1px #ccc solid;padding-left:1ex">Hi AJ,<br class=3D"gmail_msg">
That's outstanding. I am glad to see that there is actually somebody<br=
class=3D"gmail_msg">
who has made some progress.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> "miners as service providers."<br class=3D"gmail_msg">
Great idea! Block space as a resource is under-analyzed.<br class=3D"gmail_=
msg">
<br class=3D"gmail_msg">
> miner/pool's political positions, their consensus ideology, physic=
al location (yes some people would like only miners in particular countries=
to mine their transactions)<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I am not joking when I say that in 3 to 8 years, I want to be able to<br cl=
ass=3D"gmail_msg">
verify my transaction through green blocks that are generated locally<br cl=
ass=3D"gmail_msg">
by my neighbor through the excess capacity of his solar panels or by<br cla=
ss=3D"gmail_msg">
an NGO pool that promotes solar deployment around the equator.<br class=3D"=
gmail_msg">
<br class=3D"gmail_msg">
> The main attitude right now is that people would like to 'support&=
#39; miners who signal for the features they care about.<br class=3D"gmail_=
msg">
<br class=3D"gmail_msg">
Yes, just selecting all SegWit signaling hash power instead of picking<br c=
lass=3D"gmail_msg">
individual Authorities would be helpful on <a href=3D"http://preferredminer=
.com" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">preferredmin=
er.com</a><br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> I strongly believe, whether the Bitcoin developer community facilitate=
s it or not, certain miners will become preferred by users.<br class=3D"gma=
il_msg">
<br class=3D"gmail_msg">
Absolutely, considering the recent language used in opinions by the<br clas=
s=3D"gmail_msg">
ECB and drafts by the EU I see them assembling the artillery. I<br class=3D=
"gmail_msg">
wouldn't be surprised if they start target practice next year. That<br =
class=3D"gmail_msg">
will mean that commercial interest must have a way to transact on<br class=
=3D"gmail_msg">
somewhat regulated space.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> 1) By creating 'segregated mempools' where an authenticated th=
ird-party like my web service Preferred Miner manages the access to pending=
transactions destined for a specific set of miners<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
I would call it regulated block space or regulated consensus space. I<br cl=
ass=3D"gmail_msg">
hope that we can do that on a deeper level, as part of the p2p<br class=3D"=
gmail_msg">
protocol layer.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> 2) by creating transactions where the mining fee is in one way or anot=
her, an output to an address owned by the preferred miner(s).<br class=3D"g=
mail_msg">
<br class=3D"gmail_msg">
That's a distinct function, e.g. at least some communities charge a tax=
. [1]<br class=3D"gmail_msg">
I fear it is more likely that a business, say Coinbase, will approach<br cl=
ass=3D"gmail_msg">
a "miner" and just say "we pay 100 USD for a KB to your bank=
account,<br class=3D"gmail_msg">
here are our transactions with no fee". It will literally be an<br cla=
ss=3D"gmail_msg">
off-chain fee. That's what I mean by "secondary market". This=
would be<br class=3D"gmail_msg">
one of the least appealing scenarios.<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> There are some terrible pitfalls with both of these methods. [...]<br =
class=3D"gmail_msg">
<br class=3D"gmail_msg">
Spot on, that's why this should receive some attention before it<br cla=
ss=3D"gmail_msg">
becomes urgent. I think there is much more to it that we are missing<br cla=
ss=3D"gmail_msg">
at the moment, e.g. Tom: "Using xthin/compact blocks miners only send<=
br class=3D"gmail_msg">
a tiny version of a block which then causes the receiving node to<br class=
=3D"gmail_msg">
re-create it using the memory pool."<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
[1] <a href=3D"http://thebitcoin.foundation/declaration.txt" rel=3D"norefer=
rer" class=3D"gmail_msg" target=3D"_blank">http://thebitcoin.foundation/dec=
laration.txt</a><br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
<br class=3D"gmail_msg">
> From: AJ West <<a href=3D"mailto:ajwest@gmail.com" class=3D"gmail_m=
sg" target=3D"_blank">ajwest@gmail.com</a>><br class=3D"gmail_msg">
> To: <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"=
gmail_msg" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br c=
lass=3D"gmail_msg">
> Cc:<br class=3D"gmail_msg">
> Bcc:<br class=3D"gmail_msg">
> Date: Mon, 27 Mar 2017 12:29:20 -0400<br class=3D"gmail_msg">
> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering<br class=3D"gm=
ail_msg">
> Hi I'm AJ West, I made a service <a href=3D"http://preferredminer.=
com" rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">http://prefer=
redminer.com</a> which is a proof-of-concept project designed to spur discu=
ssion on exactly this issue of "miners as service providers."<br =
class=3D"gmail_msg">
><br class=3D"gmail_msg">
> The current status is that Bitcoin end users are looking to support sp=
ecific miners, whether that's because they agree with a miner/pool'=
s political positions, their consensus ideology, physical location (yes som=
e people would like only miners in particular countries to mine their trans=
actions) and the list of reasons goes on. The main attitude right now is th=
at people would like to 'support' miners who signal for the feature=
s they care about.<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
> I strongly believe, whether the Bitcoin developer community facilitate=
s it or not, certain miners will become preferred by users. In summary, the=
re are realistically two proposed ways of providing this service in the pre=
sent-day situation: 1) By creating 'segregated mempools' where an a=
uthenticated third-party like my web service Preferred Miner manages the ac=
cess to pending transactions destined for a specific set of miners, and 2) =
by creating transactions where the mining fee is in one way or another, an =
output to an address owned by the preferred miner(s).<br class=3D"gmail_msg=
">
><br class=3D"gmail_msg">
> There are some terrible pitfalls with both of these methods. The first=
being that you have to trust a lot of people, including the 3rd party (me)=
and the pools to work in your users' interest ("don't give my=
transactions to other miners or broadcast to mempool please"). Then t=
here are the extra fees users will have to pay to offset the risk of a mine=
r losing out for having to send the network a not-yet-broadcasted transacti=
on. And finally, the other method requires that they be larger transactions=
, and a directory of mining pools' receiving addresses for outputs must=
be maintained. Then you have to hope the miner will be setup to scoop in y=
our transaction knowing it's got a fee for them. Plus, how many nodes g=
oing forward are going to hold what seem to be 0-fee transactions in mempoo=
l (because the fee is in the outputs)?<br class=3D"gmail_msg">
><br class=3D"gmail_msg">
_______________________________________________<br class=3D"gmail_msg">
bitcoin-dev mailing list<br class=3D"gmail_msg">
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" class=3D"gmail_msg=
" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org</a><br class=3D"g=
mail_msg">
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" class=3D"gmail_msg" target=3D"_blank">https://lists.linu=
xfoundation.org/mailman/listinfo/bitcoin-dev</a><br class=3D"gmail_msg">
</blockquote></div>
--94eb2c0891483a9332054bcbad07--
|
