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
|
Return-Path: <ajwest@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 2C2A1B62
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 16:29:43 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f170.google.com (mail-qk0-f170.google.com
[209.85.220.170])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 4CB8B1AA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 16:29:42 +0000 (UTC)
Received: by mail-qk0-f170.google.com with SMTP id r142so14351846qke.2
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 27 Mar 2017 09:29:42 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
h=mime-version:from:date:message-id:subject:to;
bh=6N591F5gt2kufjah01UJP3/OiZ+OTYYRw8z3q25u1Zw=;
b=cieQJAr9GrCl0t0VfLTXIb2pBP5jiYsridt8tfk8S/cA0V90l4T0uJRWKOFr7hNv0m
YwGXMs4KcYaQ86d7lIsCnf09RmrQ+2VzJe0Lg++raG4udbjG+QpcUmRlt2V6zlG4MoF5
VzNwNZyApE9vrc90QGvnf750zmrvMlMqTeHyGx/1OrQXY4pNSrG+4/5f9pOhuc/bqPVj
Bj5MQeCyHtDKrS/us8/fTRdWI0AdLK0mGg9asZNUL2A+ErhCoYFVLUKDAYoxYhdSWjAE
U+7SLBe7aP6maYg5eWy9YJZO0D2S1hzjuC3I6BgC4rWzyQIOTnqbJDJFjHPHq/1Dro+k
WgKQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20161025;
h=x-gm-message-state:mime-version:from:date:message-id:subject:to;
bh=6N591F5gt2kufjah01UJP3/OiZ+OTYYRw8z3q25u1Zw=;
b=M98EaWonapceR/nDxE8wm8JZC4HhaRnY9CdaeFvuOxRq18/5Pc9TiKjpLoRbH/Ds1e
Onheh42pSFCEHhlZQ8OLaKzw0Ut5mOfRoFJyhPmzmomJkgmSmgO00ux1AyTTjq8XDhjP
LghNkFGSt+e71sUGRZzc+z++FN2N1fCnMLxzeoTbaw5p86f+1F9FB8bgVpsCWTvEqqfX
Ldj0m+Ucq62l3Ppi0yAoKyNJ5Kj2+DpcTB+UD7VtQ0+eQSVMP9W4BzLg8+uBvnezuzsL
EmH+7CUNdSceJkopuhJgp88mHACl/23hAuJxpdWiRd0vERTPEjBXgDbt86oEZMFzrYpL
CoFA==
X-Gm-Message-State: AFeK/H0RAONFZ7gK3GVKOCI7gjx/o8fMwWaFY778jk4tzuzjdcrH7WiUrg7PRBpWhlZhsxlUzXikInvbtjl+JQ==
X-Received: by 10.55.15.38 with SMTP id z38mr21559060qkg.114.1490632180805;
Mon, 27 Mar 2017 09:29:40 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.38.66 with HTTP; Mon, 27 Mar 2017 09:29:20 -0700 (PDT)
From: AJ West <ajwest@gmail.com>
Date: Mon, 27 Mar 2017 12:29:20 -0400
Message-ID: <CABXVU6ZRBBcPVjEcCRjhSNsgPmWrHWnmcWLOYVDjRdQYN2QTiQ@mail.gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a113b0b50a0b7fd054bb8d9ba
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: Mon, 27 Mar 2017 16:32:14 +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: Mon, 27 Mar 2017 16:29:43 -0000
--001a113b0b50a0b7fd054bb8d9ba
Content-Type: text/plain; charset=UTF-8
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)?
I am not necessarily looking for answers or solutions to these issues, but
simply to show a case and to express that this idea of having specific
miners/pools process their transactions, is important to some people.
--001a113b0b50a0b7fd054bb8d9ba
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><span style=3D"font-size:12.8px">Hi I'm AJ West, I mad=
e a service=C2=A0</span><a href=3D"http://preferredminer.com/" target=3D"_b=
lank" style=3D"font-size:12.8px">http://preferredminer.<wbr>com</a><span st=
yle=3D"font-size:12.8px">=C2=A0which is a proof-of-concept project designed=
to spur discussion on exactly this issue of "miners as service provid=
ers."</span><div style=3D"font-size:12.8px"><br></div><div style=3D"fo=
nt-size:12.8px">The current status is that Bitcoin end users are looking to=
support specific miners, whether that's because they agree with a mine=
r/pool's political positions, their consensus ideology, physical locati=
on (yes some people would like only miners in particular countries to mine =
their transactions) and the list of reasons goes on. The main attitude righ=
t now is that people would like to 'support' miners who signal for =
the features they care about.</div><div style=3D"font-size:12.8px"><br></di=
v><div style=3D"font-size:12.8px">I strongly believe, whether the Bitcoin d=
eveloper community facilitates it or not, certain miners will become prefer=
red by users. In summary, there are realistically two proposed ways of prov=
iding this service in the present-day situation: 1) By creating 'segreg=
ated mempools' where an authenticated third-party like my web service P=
referred Miner manages the access to pending transactions destined for a sp=
ecific 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 mi=
ner(s).</div><div style=3D"font-size:12.8px"><br></div><div style=3D"font-s=
ize:12.8px">There are some terrible pitfalls with both of these methods. Th=
e first being that you have to trust a lot of people, including the 3rd par=
ty (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 tr=
ansaction. And finally, the other method requires that they be larger trans=
actions, and a directory of mining pools' receiving addresses for outpu=
ts must be maintained. Then you have to hope the miner will be setup to sco=
op 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)?</div><div style=3D"font-size:=
12.8px"><br></div><div style=3D"font-size:12.8px">I am not necessarily look=
ing for answers or solutions to these issues, but simply to show a case and=
to express that this idea of having specific miners/pools process their tr=
ansactions, is important to some people.</div></div>
--001a113b0b50a0b7fd054bb8d9ba--
|
