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
|
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 529695A7
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Mar 2017 20:12:59 +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 28E782FA
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Mar 2017 20:12:57 +0000 (UTC)
Received: by mail-qk0-f173.google.com with SMTP id p64so119942250qke.1
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 20 Mar 2017 13:12:57 -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
:content-transfer-encoding;
bh=VvRU7CFn+ekyjVv5ea2yOEq2wvDOJk1l417oCxuED4I=;
b=ynW+cfPyHSR4oXL6ZcAVl1wzXTVXHPpqv2R9lZbC2vZR41V575eA5QpZpdEHWTNKED
TNTm2LPNyLCu4IN/5hVi+6QFEEqFXusAP5Z5xGD/8q+1IU93/TbVjSlHs4UdeVMDr3Tq
NXflZv0igRNwiG34CqIBJfz5a1fQC0fV5nmD0XP3HaOiqIh8NXG6M+uMmRbdZxWixKc3
HtCnA/GoHOrDzMsk3u3iPLPPwdO/uEAue3niO7N8/olN2/JDuysMldIFz7MPP7jrluRf
/6yn1rnjVpgZZA3Jw1SHErZYQ5LCCmF+hRBFQ+fxAKq1ELTo2kRLzNGbwE2gTwyjONvj
8kUg==
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
:content-transfer-encoding;
bh=VvRU7CFn+ekyjVv5ea2yOEq2wvDOJk1l417oCxuED4I=;
b=umXJQ7n2KrrqpEeocki10e9r7di0bRo34S4EuP58NudWZijda/zgOuty3X3MG8bxoC
HBs7+eM4ZVpKVlqt9j+GuPLXz16bYlS8r3K/+QqFADsUB4HShC0EWxizBuSApoROQ/L+
IoCMU0ULYNtT0rHw0QcOojwCOrt/8rn1hBNnlAgVC3zaazs6iTejWvj2j1nWUiyJRMSH
HmmqdBeUX9M7s7XN++iM+wkmFxagdDmAPZazdgSX+bc7UBhNjRKLeYtn/Z0tlmfaFtQA
w57K1QvMQLlPhJiQHWfpHSff3CUU7mMOruUnybng4Kh2V5syjPbVBnOjBjDE7Vb0E3Te
q24g==
X-Gm-Message-State: AFeK/H0obbbtApLCVr10zg4cK7FBRO1bUSeblSFsDdygCYqFh2l+c8x2Dxna5M3LpGpYP2Fqy3W6ut42uA5Sbg==
X-Received: by 10.55.54.5 with SMTP id d5mr29401342qka.9.1490040776730; Mon,
20 Mar 2017 13:12:56 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.63.78 with HTTP; Mon, 20 Mar 2017 13:12:36 -0700 (PDT)
X-Originating-IP: [185.65.132.110]
From: Martin Stolze <martin@stolze.cc>
Date: Mon, 20 Mar 2017 20:12:36 +0000
Message-ID: <CAOyfL0oQrHzDmHBnWo0pTdbVU7acnsLmikTh9NU_u6HnhT4VCw@mail.gmail.com>
To: 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: Mon, 20 Mar 2017 20:37:39 +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: Mon, 20 Mar 2017 20:12:59 -0000
Hi Team,
I would like to find out what the current consensus on transaction tiering =
is.
Background: The current protocol enables two parties to transact
freely, however, transaction processors (block generators) have the
authority to discriminate participants arbitrarily. This is well known
and it is widely accepted that transaction processors may take
advantage of this with little recourse. It is the current consensus
that the economic incentives in form of transaction fees are
sufficient because the transaction processing authorities are assumed
to be guided by the growth of Bitcoin and the pursuit of profit.
We can establish that a transaction processing authority does not need
to actually process transactions and reigns sovereign over the block
space they govern. [1] For further discussion I will refer to a
transaction processor more aptly as "Block Space Authority" (BSA).
Currently, a user can only signal to all BSA=E2=80=99s (via the mempool) it=
s
desire to include her transaction into the ledger. A user can not
signal to specific BSA=E2=80=99s, and thus, can not easily carry out busine=
ss
in jurisdictions that conform to the users understanding of best
practice.
As a participant in the economy in general and of Bitcoin in
particular, I desire an ability to decide where I transact. The
current state of Bitcoin does not allow me to choose my place of
business. As a consequence, I try to learn what would be the best way
to conduct my business in good faith. [2]
I have certain minimum requirements towards the constitution of the
block space like transparency, forward guidance and risk management.
More poignantly, it could also include due diligence to ensure that
child labor is not involved in the maintenance of a specific block
space, or that the specific block space does not utilize nuclear
energy or sources at least 80% of the expended energy from solar
power. Obviously, preferences can vary widely.
I don=E2=80=99t think there is any way to discard the desire of users to
choose their place of business, especially under the consideration
that BSA=E2=80=99s have the discretion to choose users transactions already=
.
I have identified the following options along the lines of Lawrence
Lessig's concept of Cyberspace: [3]
1. Law: Bilateral Agreement
Users engage directly with BSA=E2=80=99s to process their transaction.
Transactions are routed around the mempool. A likely outcome of this
solution is the emergence of brokers that sell off block space in a
sort of secondary market. Wallets may negotiate on behalf of their
users. This model has obvious downsides as it involves new middlemen,
increases transaction cost beyond the current market price
(speculation) and potentially reduces performance.
2. Architecture: Remove transaction fees
If only the block reward functions to incentivise transaction
processing, no differentiation is useful. However, spam/empty blocks
could not be prevented and Bitcoin would have to be entirely
redesigned, potentially losing its censorship resistance.
3. Market: Direct Communication
Through the core client, BSA=E2=80=99s can offer individual mempools that
users can choose to advertise their transactions to. Different BSA=E2=80=99=
s
could receive different transaction fees for the same transaction in
their respective mempool to reflect the preference of the user.
In Conclusion: In the long term, it is likely that a clearer
differentiation of BSA=E2=80=99s will become important. Today, BSA=E2=80=99=
s
communicate rarely and it appears that their raison d'etre is not
necessarily motivated by good faith towards Bitcoin as a whole. [4] As
we move forward it is not just important to attract opportunistic
players that win an individual game but good players that are invited
to play again in order to win a set of all possible games.
BSA=E2=80=99s establish their authority on cheap access to capital in the f=
orm
of electricity and hardware and the consent and trust of users who
expect BSA's to respect and maintain the ledgers integrity.
In 3 to 8 years, when Bitcoin leaves it=E2=80=99s bootstrapping phase, the
incentives will squarely fall on the later. [5] Subsequently it seems
prudent to allow BSA=E2=80=99s to compete for business on other factors tha=
n
price.
Hence my question: What is the current stance of core developers
regarding the facilitation of direct communication between users and
BSA=E2=80=99s, possibly through a transaction tiering model?
Sincerely,
Martin Stolze
[1] BSA rules sovereign: (https://twitter.com/JihanWu/status/70447683956613=
5298)
[2] No direct attribution but solid foundation for business logic
since 1899: =C2=A7242 ff BGB
(https://www.gesetze-im-internet.de/englisch_bgb/englisch_bgb.html#p0726)
[3] Lessig, Code. "And Other Laws of Cyberspace, Version 2.0." (2006).
[4] The pursuit of profit can come at the expense of Bitcoin:
(https://twitter.com/ToneVays/status/835233366203072513)
[5] Satoshi Nakamoto: "Once a predetermined number of coins have
entered circulation, the incentive can transition entirely to
transaction fees [...]"
|
