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
|
Return-Path: <pete@petertodd.org>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id E4773B14
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 03:02:31 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from outmail148101.authsmtp.com (outmail148101.authsmtp.com
[62.13.148.101])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1D513CF
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 29 Sep 2017 03:02:30 +0000 (UTC)
Received: from mail-c247.authsmtp.com (mail-c247.authsmtp.com [62.13.128.247])
by punt22.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8T32SvX081529;
Fri, 29 Sep 2017 04:02:28 +0100 (BST)
Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com
[52.5.185.120]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id v8T32Rcd001895
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO);
Fri, 29 Sep 2017 04:02:28 +0100 (BST)
Received: from [127.0.0.1] (localhost [127.0.0.1])
by petertodd.org (Postfix) with ESMTPSA id 7579C4010A;
Fri, 29 Sep 2017 03:02:26 +0000 (UTC)
Received: by localhost (Postfix, from userid 1000)
id 8EDC3205E4; Thu, 28 Sep 2017 23:02:25 -0400 (EDT)
Date: Thu, 28 Sep 2017 23:02:25 -0400
From: Peter Todd <pete@petertodd.org>
To: Mark Friedenbach <mark@friedenbach.org>
Message-ID: <20170929030225.GA12614@savin.petertodd.org>
References: <359FFE85-86AF-4FBD-9491-3528382E5002@friedenbach.org>
<20170929020227.GA12192@savin.petertodd.org>
<FAD5BE01-52B5-49C6-B018-47BF234A5EF2@friedenbach.org>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="HlL+5n6rz5pIUxbD"
Content-Disposition: inline
In-Reply-To: <FAD5BE01-52B5-49C6-B018-47BF234A5EF2@friedenbach.org>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-Server-Quench: a0a1f056-a4c2-11e7-a0cc-0015176ca198
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aAdMdAsUC1AEAgsB AmEbW1BeUF97W2s7 bghPaBtcak9QXgdq
T0pMXVMcUg0MAh5j VUoeUhh6fgAIcXhz ZQgzXiFaCkR/c1ss
Rh1WCGwHMGB9OWBM A11YdwJRcQRMLU5E Y1gxNiYHcQ5VPz4z
GA41ejw8IwAXEilf Sx0EJ1YfCUgGEyV0 CVgDGz4iG1EEWSh2
NBUoJxYSEUtZN0wo MlY9Qjp/
X-Authentic-SMTP: 61633532353630.1038:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 52.5.185.120/25
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW
autolearn=disabled version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
smtp1.linux-foundation.org
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets
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: Fri, 29 Sep 2017 03:02:32 -0000
--HlL+5n6rz5pIUxbD
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Thu, Sep 28, 2017 at 07:45:02PM -0700, Mark Friedenbach wrote:
>=20
>=20
> > On Sep 28, 2017, at 7:02 PM, Peter Todd <pete@petertodd.org> wrote:
> >=20
> >> On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin=
-dev wrote:
> >> Unlike other proposed fixes to the fee model, this is not trivially
> >> broken by paying the miner out of band. If you pay out of band fee
> >> instead of regular fee, then your transaction cannot be included with
> >> other regular fee paying transactions without the miner giving up all
> >> regular fee income. Any transaction paying less fee in-band than the
> >> otherwise minimum fee rate needs to also provide ~1Mvbyte * fee rate
> >> difference fee to make up for that lost income. So out of band fee is
> >> only realistically considered when it pays on top of a regular feerate
> >> paying transaction that would have been included in the block anyway.
> >> And what would be the point of that?
> >=20
> > This proposed fix is itself broken, because the miner can easily includ=
e *only*
> > transactions paying out-of-band, at which point the fee can be anything.
>=20
> And in doing so either reduce the claimable income from other transaction=
s (miner won=E2=80=99t do that), or require paying more non-rebateable fee =
than is needed to get in the block (why would the user do that?)
>=20
> This is specifically addressed in the text you quoted.=20
I specifically outlined a scenario where that text isn't relevant: *all*
transaction in a block can be paying out of band.
> > Equally, miners can provide fee *rebates*, forcing up prices for everyo=
ne else
> > while still allowing them to make deals.
>=20
> Discounted by the fact rebates would not be honored by other miners. The =
rebate would have to be higher than what they could get from straight fee c=
ollection, making it less profitable than doing nothing.=20
You're making the incorrect assumption that all transactions have to be
broadcast publicly; they don't.
> > Also, remember that you can pay fees via anyone-can-spend outputs, as m=
iners
> > have full ability to control what transactions end up spending those ou=
tputs.
>=20
> You=E2=80=99d still have to pay the minimum fee rate of the other transac=
tions or you=E2=80=99d bring down the miners income. Otherwise this is near=
ly the same cost as the rebate fee, since they both involve explicit output=
s claimed by the miner, but the rebate goes back to you. So why would you n=
ot want to do that instead?
>=20
> A different way of looking at this proposal is that it creates a penalty =
for out of band payments.=20
It certainly does not. It simply adds another level of complexity and overh=
ead
to the out-of-band payment situation, which is not desirable. If we can't
eliminate out of band payments entirely, we do not want to make the playing
field of them even more unbalanced than it already is.
This is a typical academic proposal that only considers first order effects
while ignoring second order effects.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--HlL+5n6rz5pIUxbD
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
iQEcBAEBCAAGBQJZzbe+AAoJECSBQD2l8JH7678H/Rpz4ND8MBsxF3j5BG4jr4zJ
HLxryWqkE1pgsNMEFOVbOYuElDKfiVw+J0YnctjLzs60pM8D7jA6C2RodajdFiEZ
aZME/0D385RoWAUq/yj7hkhdzldCOE7yVugKnOSGLntBTmy+guCOjkt4CPMBKsrD
mnWmqNP/eTGm0eniz7yXPC0ZYLnmgK154klgFNwGq6UuF1TUHWMXNdlhB97kfLfA
Xzf82Up12PO+AoyjkfXh2hXr4IdjYiscsKUGl5lZ6/EavSFaDKPGjMA0ZUeQ0wk6
dBd4/s7ucbGeJYYIlsTG8IDaCQ1ujrjy50DOdlmua9hV/H5/FxtFjNkPzR5O0Xc=
=EYsw
-----END PGP SIGNATURE-----
--HlL+5n6rz5pIUxbD--
|
