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
|
Return-Path: <martin@stolze.cc>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id CFBD087A
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 12:58:53 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qk0-f173.google.com (mail-qk0-f173.google.com
[209.85.220.173])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D8AB4144
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 12:58:52 +0000 (UTC)
Received: by mail-qk0-f173.google.com with SMTP id p22so64264437qka.3
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 28 Mar 2017 05:58:52 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=stolze-cc.20150623.gappssmtp.com; s=20150623;
h=mime-version:from:date:message-id:subject:to:cc
:content-transfer-encoding;
bh=wNJ/MfW4cp8cqSc94mZKMYjEEJ+3q3oExDpEQ+jR85w=;
b=XL7fh3q5rfBI0p5LSp1Z8aC6goXT+b9BR0Vy8/sOsn0CVYO/sIugWzr6guF5xFxNEN
BLBvQ6X99yEf2DL5fKO354X8CVSSo7IC/FzPJx+j7o/Q2eDlwzRDFHj0oInOi9sgxAOr
QCqTQw3KYmRkTDGipy5yI+XVHOm0dFZyny3ehiKwELHMvaRsB5llIZ+BbFau/LCHEYZM
BkvxzFv1+ya5n2XW272i+vdfuxa8rH855WCxF7vsPck0ArmwUSnwEoErebxfMl2j2wmA
Scf4fj2LcTzTLmLQYbGc2cN+RTljaCUyVzqzC9PydAfoF7+OeithVhEuR1XqqwdNLQJs
D5oA==
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:cc
:content-transfer-encoding;
bh=wNJ/MfW4cp8cqSc94mZKMYjEEJ+3q3oExDpEQ+jR85w=;
b=lTOg5HcTo4bAxQO6tGOs8kwEKJmihvUBuEB8CJKXEozDGeZnjoSNvzm+vQsEt9RcWj
W9qwgZS8qqtQ8UIlLTGGnuy+vTNc4tnQU7gejPOt9hfR/GkTzA5xBsyRwJ+gAf7hdEkn
f6yEIDMNrZSp3XBX/q1WMc/XC+U34oZ0o0CFMg/HXm+BFDHWv09WqiU1dQZYf5z9p1kb
g8I4e8NwI9sfZ3km8WOkOXFRnBjGCiiYhHi5glcw4tYQphrNHSpv9EYWIxzhIDeMkLcf
xv8ueXtr8Q81rTTjT26oIg9ZaBKkWZYmSCuBbDKzRXho9nHLoWu26Dx27HNMzFywSyZN
mJvA==
X-Gm-Message-State: AFeK/H1rsCbUe7J+nRePz6NGDlEeCGQY0YtPxX3VxDtKqu0CG4aK1WsWlMcuzTCi7u/ESm5DlnNpL5oy1LjQ8A==
X-Received: by 10.55.103.193 with SMTP id b184mr21331147qkc.264.1490705931605;
Tue, 28 Mar 2017 05:58:51 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.63.78 with HTTP; Tue, 28 Mar 2017 05:58:31 -0700 (PDT)
X-Originating-IP: [89.238.178.35]
From: Martin Stolze <martin@stolze.cc>
Date: Tue, 28 Mar 2017 13:58:31 +0100
Message-ID: <CAOyfL0pN8Z8XSvHAXkG2=ic=J6m-8B5K2d=_eL=84Dnox3ovMQ@mail.gmail.com>
To: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, 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: Tue, 28 Mar 2017 14:31:55 +0000
Subject: [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 12:58:53 -0000
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 loca=
tion (yes some people would like only miners in particular countries to min=
e 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 i=
t 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 l=
ike my web service Preferred Miner manages the access to pending transactio=
ns 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 pro=
of-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 speci=
fic miners, whether that's because they agree with a miner/pool's political=
positions, their consensus ideology, physical location (yes some people wo=
uld like only miners in particular countries to mine their transactions) an=
d the list of reasons goes on. The main attitude right now is that people w=
ould like to 'support' miners who signal for the features they care about.
>
> I strongly believe, whether the Bitcoin developer community facilitates i=
t or not, certain miners will become preferred by users. In summary, there =
are realistically two proposed ways of providing this service in the presen=
t-day situation: 1) By creating 'segregated mempools' where an authenticate=
d third-party like my web service Preferred Miner manages the access to pen=
ding 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 a=
n address owned by the preferred miner(s).
>
> There are some terrible pitfalls with both of these methods. The first be=
ing that you have to trust a lot of people, including the 3rd party (me) an=
d 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 fe=
es users will have to pay to offset the risk of a miner losing out for havi=
ng 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 i=
t's got a fee for them. Plus, how many nodes going forward are going to hol=
d what seem to be 0-fee transactions in mempool (because the fee is in the =
outputs)?
>
|
