summaryrefslogtreecommitdiff
path: root/47/ec257409a372e89c76fddab56ce0afaa20cbd6
blob: abff84176f1c85e3cc34fc8d848c1a30c492934b (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
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
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 658364A6
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Mar 2017 17:16:13 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-qt0-f177.google.com (mail-qt0-f177.google.com
	[209.85.216.177])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6060BA1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Mar 2017 17:16:12 +0000 (UTC)
Received: by mail-qt0-f177.google.com with SMTP id i34so12314449qtc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 25 Mar 2017 10:16:12 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=stolze-cc.20150623.gappssmtp.com; s=20150623;
	h=mime-version:in-reply-to:references:from:date:message-id:subject:to
	:cc; bh=SW/LDYhODVKFBaD6vl6kD0oEJ9O2nN5Lzo8N84o2QvY=;
	b=VeEU9MaE/zJi9m7iEzA/ZF614r9AvxZEGgKsW07bMvt1jReObojt5JL0PvSHCITymF
	wVIlXFND+yg1X5O2XHrAEFGvik+dpES/K2IUwbnTWjctxPjbQ2YBMQgJZ2b9wCZgYqA0
	hGAwnVrOhx6euZ6nw/31WLZJd5y2nVDIBmmHShnL98ZErjwbLBeN9YKswYOdelcVbFSU
	J8+HtlcWuFStfxRbPOFpAHL1bygfn3/N9fqMFWJMgj4L0agAonElW4DJsOB7BUgAygZs
	7/kNAH2Gv1MKGbYZ2BHmWcOs4F0PlmbEPl0CfRiJ38TXr4Xa/iW3EG34zMSWIzhZI6Pw
	mfdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:in-reply-to:references:from:date
	:message-id:subject:to:cc;
	bh=SW/LDYhODVKFBaD6vl6kD0oEJ9O2nN5Lzo8N84o2QvY=;
	b=uPkP+RsbIEcna4xpQ79DHqoWOtARPCENYTvCvZ5TqZBMhbkKvm/qCjetDU7kI75x/z
	oRW1RLOz4/MaMF1JN8e/4yNpqg6QS6eaSHF1IoE5mH9ySz+WL5NPqDpzs6vmKlT9AFzP
	2gJXOSqrQFbaXyVkRgPdL5J02/vzRVWLC89qNKaf5MDLSo81vu/JRg11RR/iwLVDDjUe
	tjXsHegO9xTLoI78YNA5sFdxcPFVtQnqd69lKxviud3Z7a5JAFi1mG89/nzqXofVFT2q
	8hzUIP1dHMsom3xvMfaOA9ageE5at1lQQD9eEwpxWvAf6cFpPtaS0AzTTRhn5C2u21vr
	0iMg==
X-Gm-Message-State: AFeK/H3BX5EqQ0BREA7PuireJwYA+MI8J667r2w33XySQnc/S0Ui2B+H8ZdP6gVXXzGTvOMLpngnv+jexGsYew==
X-Received: by 10.237.40.66 with SMTP id r60mr14500782qtd.42.1490462171173;
	Sat, 25 Mar 2017 10:16:11 -0700 (PDT)
MIME-Version: 1.0
Received: by 10.237.63.78 with HTTP; Sat, 25 Mar 2017 10:15:50 -0700 (PDT)
X-Originating-IP: [185.65.135.88]
In-Reply-To: <Rs51ijp6P21vJsv7OxVB-k8vuJC_aUd8KnpxHC3phNw_lPieY2lS-k95gytpHTNzzBfuX030RRFKzrrwS3pfjTuFea_eUfErb3qDp5LDHp4=@protonmail.com>
References: <CAOyfL0r8dLR=7Co5+YzbPQUeTs6Lw+OQjZTy=iyoDmr6VV_Qpw@mail.gmail.com>
	<Rs51ijp6P21vJsv7OxVB-k8vuJC_aUd8KnpxHC3phNw_lPieY2lS-k95gytpHTNzzBfuX030RRFKzrrwS3pfjTuFea_eUfErb3qDp5LDHp4=@protonmail.com>
From: Martin Stolze <martin@stolze.cc>
Date: Sat, 25 Mar 2017 17:15:50 +0000
Message-ID: <CAOyfL0qW=8091BAo9R2mskbyFSS3hOnXd+Wjsu4LQy7EtqzJjg@mail.gmail.com>
To: praxeology_guy <praxeology_guy@protonmail.com>
Content-Type: text/plain; charset=UTF-8
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: Sat, 25 Mar 2017 17:44:34 +0000
Cc: bitcoin-dev@lists.linuxfoundation.org
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: Sat, 25 Mar 2017 17:16:13 -0000

Thanks, those are valid concerns.

> Potentially miners could create their own private communication channel/listening port for submitting transactions that they would not relay to other miners/the public node relay network.
That is the idea. Transaction Processors could source transactions
from the public mempool as well their proprietary mempool(s).

> Miners would be incentivized to not relay higher fee transactions, because they would want to keep them to themselves for higher profits.
Not so, a user may want to incentivise a specific Transaction
Processor or many. A user can detect this behavior and withdraw his
future business if he notices that his transaction is not included in
a block despite there being transactions with lower fees included.
Remember, the transaction can be advertised to different mempools and
a Transaction Processor could lose this business to a competitor who
processes the next block if he holds it back.

Best Regards
Martin

PS: It seems not too late to get rid of misleading terms like "miner".
Block rewards (infrastructure subsidies) will be neglectable for
future generations and the analogy is exceedingly poor.

On Sat, Mar 25, 2017 at 4:42 AM, praxeology_guy
<praxeology_guy@protonmail.com> wrote:
> Potentially miners could create their own private communication
> channel/listening port for submitting transactions that they would not relay
> to other miners/the public node relay network.  Users could then chose who
> they want to relay to.  Miners would be incentivized to not relay higher fee
> transactions, because they would want to keep them to themselves for higher
> profits.
>
> Cheers,
> Praxeology Guy
>
>
> -------- Original Message --------
> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
> Local Time: March 22, 2017 12:48 PM
> UTC Time: March 22, 2017 5:48 PM
> From: bitcoin-dev@lists.linuxfoundation.org
> To: bitcoin-dev@lists.linuxfoundation.org
>
> Hi Tim,
> After writing this I figured that it was probably not evident at first
> sight as the concept may be quite novel. The physical location of the
> "miner" is indeed irrelevant, I am referring to the digital location.
> Bitcoins blockchain is a digital location or better digital "space".
> As far as I am concerned the authority lies with whoever governs this
> particular block space. A "miner" can, or can not, include my
> transaction.
>
> To make this more understandable:
>
> Abu Bakr al-Baghdadi can extend his caliphate into Bitcoins block
> space and rule sovereign(!) over a given block. If he processes my
> transaction my fee goes directly into the coffers of his organization.
> The same goes for the Queen of England or the Emperor of China. My
> interest is not necessarily aligned with each specific authority, yet
> as you point out, I can only not use Bitcoin.
> Alternatively, however, I can very well sign my transaction and send
> it to an authority of my choosing to be included into the ledger, say
> BitFurry. - This is what I describe in option 1.
>
> In order to protect my interest I do need to choose, maybe not today,
> but eventually.
>
> I also think that people do care who processes transactions and a lot
> of bickering could be spared if we could choose.
>
> If we assume a perfectly competitive market with 3 authorities that
> govern the block space equally, the marginal cost of 1/3 of the block
> space is the same for each, however, the marginal revenue absent of
> block rewards is dependent on fees.
> If people are willing to pay only a zero fee to a specific authority
> while a fee greater than zero to the others it's clear that one would
> be less competitive.
>
> Let us assume the fees are 10% of the revenue and the cost is 95 we
> have currently the following situation:
>
> A: Cost=95; Revenue=100; Profit=5
> B: Cost=95; Revenue=100; Profit=5
> C: Cost=95; Revenue=100; Profit=5
>
> With transaction tiering, the outcome could be different!
>
> A: Cost=95; Revenue=90; Loss=5 // BSA that does not respect user interest.
> B: Cost=95; Revenue=105; Profit=10
> C: Cost=95; Revenue=105; Profit=10
>
> This could motivate transaction processors to behave in accordance
> with user interest, or am I missing something?
>
> Best Regards,
> Martin
>
>> From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
>> To: bitcoin-dev@lists.linuxfoundation.org
>> Cc:
>> Bcc:
>> Date: Tue, 21 Mar 2017 16:18:26 +0100
>> Subject: Re: [bitcoin-dev] Inquiry: Transaction Tiering
>> (I'm not a lawyer...)
>>
>> I'm not sure if I can make sense of your email.
>>
>> On Mon, 2017-03-20 at 20:12 +0000, Martin Stolze via bitcoin-dev wrote:
>>> 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]
>>
>> Ignoring the rest, I don't think that the physical location /
>> jurisdiction of the miner has any legal implications for law applicable
>> to the relationship between sender and receiver of a payment.
>>
>> This is not particular to Bitcoin. We're both in Germany (I guess).
>> Assume we have a contract without specific agreements and I pay you in
>> Icelandic kronur via PayPal (in Luxembourg) and my HTTPS requests to
>> PayPal went via Australia and the US. Then German law applies to our
>> contract, nothing in the middle can change that.
>>
>> Also ignoring possible security implications, there is just no need for
>> a mechanism that enables users to select miners. I claim that almost
>> nobody cares who will mine a transaction, because it makes no technical
>> difference. If you don't want a specific miner to mine your
>> transaction, then don't use Bitcoin.
>>
>> Tim
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>