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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-1.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1VnnU3-0000p0-VS
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 10:45:40 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.178 as permitted sender)
client-ip=209.85.214.178; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f178.google.com;
Received: from mail-ob0-f178.google.com ([209.85.214.178])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1VnnU2-0003KL-SV
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 10:45:39 +0000
Received: by mail-ob0-f178.google.com with SMTP id uz6so14171261obc.37
for <bitcoin-development@lists.sourceforge.net>;
Tue, 03 Dec 2013 02:45:33 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.182.48.130 with SMTP id l2mr5863149obn.44.1386067533439;
Tue, 03 Dec 2013 02:45:33 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.3.134 with HTTP; Tue, 3 Dec 2013 02:45:33 -0800 (PST)
In-Reply-To: <CANAnSg2kH+OeypDARUKyDTUmq26PiK2_U45wGaUOGTnkXj6jjA@mail.gmail.com>
References: <CANEZrP3tGdFh6oG5fbX9JbU6sYbbex1cq=0tQB-0A4aDrdbXrQ@mail.gmail.com>
<l7f97u$jdg$1@ger.gmane.org>
<5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net>
<l7fpbn$hf6$1@ger.gmane.org>
<39921E12-B411-4430-9D56-04F53906B109@plan99.net>
<CAGLkj4C9fyAX1CnB0oZH3BwLRQp6WOo9kLUqDhRUSA6y3LxYvg@mail.gmail.com>
<CANEZrP1C=Hc-3f-rqQ+wYrPn-eUj52HjN+qRQdJMWvnP+dkK=Q@mail.gmail.com>
<CAJHLa0P_uzEQ2OG2FTXyD2Zw4RzujNBxKbKD04CSS1sLNpLUUQ@mail.gmail.com>
<CANEZrP2hf2853w9f4__Ji9v3eRRU0u6pEzPxAmFN+iH067gtnA@mail.gmail.com>
<CABsx9T3NQDPL6=pz5BD5DsP0qh0x3LJOCj2H3yY5tzL2_DivGA@mail.gmail.com>
<CANEZrP1PLKemiUEgMJRGdiZXt7o=0_5fhLKYY0x3Ngb_iEm+2w@mail.gmail.com>
<CANAnSg2kH+OeypDARUKyDTUmq26PiK2_U45wGaUOGTnkXj6jjA@mail.gmail.com>
Date: Tue, 3 Dec 2013 11:45:33 +0100
X-Google-Sender-Auth: l56u5kyxus0Are4PKwcS0BWX_T8
Message-ID: <CANEZrP2iQ3P813qz9KL2R3WBTYpVq4AuL1xrfnwt5ay8Tk1oxw@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Drak <drak@zikula.org>
Content-Type: multipart/alternative; boundary=089e0160b3dcf72c4704ec9efe9d
X-Spam-Score: -0.5 (/)
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider
(mh.in.england[at]gmail.com)
-0.0 SPF_PASS SPF: sender matches SPF record
0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked.
See
http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block
for more information. [URIs: zikula.org]
1.0 HTML_MESSAGE BODY: HTML included in message
0.1 DKIM_SIGNED Message has a DKIM or DK signature,
not necessarily valid
-0.1 DKIM_VALID Message has at least one valid DKIM or DK signature
X-Headers-End: 1VnnU2-0003KL-SV
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
X-BeenThere: bitcoin-development@lists.sourceforge.net
X-Mailman-Version: 2.1.9
Precedence: list
List-Id: <bitcoin-development.lists.sourceforge.net>
List-Unsubscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=unsubscribe>
List-Archive: <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>
List-Post: <mailto:bitcoin-development@lists.sourceforge.net>
List-Help: <mailto:bitcoin-development-request@lists.sourceforge.net?subject=help>
List-Subscribe: <https://lists.sourceforge.net/lists/listinfo/bitcoin-development>,
<mailto:bitcoin-development-request@lists.sourceforge.net?subject=subscribe>
X-List-Received-Date: Tue, 03 Dec 2013 10:45:40 -0000
--089e0160b3dcf72c4704ec9efe9d
Content-Type: text/plain; charset=UTF-8
On Tue, Dec 3, 2013 at 11:36 AM, Drak <drak@zikula.org> wrote:
> I dont like the idea of putting the min fee in the hands of the receiver.
> Seems like that will work against the best interests of senders in the long
> run.
>
Senders have no interest in ever attaching any kind of fee, which is one
reason we explored child-pays-for-parent for a while. It's not the sender
who cares about double spending risk. Left to their own devices, all
senders would always attach no fee at all (or rather: whatever the min was
to get the transaction relayed to the merchant).
However, receivers do want a fee attached, and ideally we would do this
without redundant transactions. Hence, receivers asking senders to attach a
fee and effectively folding it into the price that is paid. That is, if you
go into a restaurant and the menu says "Burger: 10mBTC" then when you come
to pay, what you see on your phone screen is 10mBTC. The fact that actually
the shop with receiver 9.9mBTC and the tx fee is 0.1mBTC is hidden in the
user interface - creating a situation like many others, where receivers eat
a transaction cost. For instance in Europe sales taxes are included in the
price, not attached separately later.
There's no need to trust the vendor. If a vendor asks for a ridiculously
high tx fee, it will just surface as uncompetitively priced goods/services.
Buyers will go elsewhere.
> Why not try a different path of calculating the min fee like difficulty
> retarget. You can analyse the last 2016 blocks to find the average fee
> accepted per kb (which would include transactions that were included
> without fees) and then write that into the block as a soft recommendation
> that wallets could use in the UI. This way the price can vary up and down
> according to what people were willing to spend on fees and miners willing
> to accept.
>
That's what fee estimation does, essentially, minus the encoding into
blocks. Once you start getting miners telling people what fees are directly
you run into cases where they might try to lie about their behaviour or
otherwise influence the average. Querying all nodes avoids that problem.
--089e0160b3dcf72c4704ec9efe9d
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail_quote">On T=
ue, Dec 3, 2013 at 11:36 AM, Drak <span dir=3D"ltr"><<a href=3D"mailto:d=
rak@zikula.org" target=3D"_blank">drak@zikula.org</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">I dont like the idea of putting=
the min fee in the hands of the receiver. Seems like that will work agains=
t the best interests of senders in the long run.=C2=A0</div></div></blockqu=
ote><div>
<br></div><div>Senders have no interest in ever attaching any kind of fee, =
which is one reason we explored child-pays-for-parent for a while. It's=
not the sender who cares about double spending risk. Left to their own dev=
ices, all senders would always attach no fee at all (or rather: whatever th=
e min was to get the transaction relayed to the merchant).</div>
<div><br></div><div>However, receivers do want a fee attached, and ideally =
we would do this without redundant transactions. Hence, receivers asking se=
nders to attach a fee and effectively folding it into the price that is pai=
d. That is, if you go into a restaurant and the menu says "Burger: 10m=
BTC" then when you come to pay, what you see on your phone screen is 1=
0mBTC. The fact that actually the shop with receiver 9.9mBTC and the tx fee=
is 0.1mBTC is hidden in the user interface - creating a situation like man=
y others, where receivers eat a transaction cost. For instance in Europe sa=
les taxes are included in the price, not attached separately later.</div>
<div><br></div><div>There's no need to trust the vendor. If a vendor as=
ks for a ridiculously high tx fee, it will just surface as uncompetitively =
priced goods/services. Buyers will go elsewhere.</div><div>=C2=A0</div><blo=
ckquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #c=
cc solid;padding-left:1ex">
<div dir=3D"ltr"><div class=3D"gmail_extra">Why not try a different path of=
calculating the min fee like difficulty retarget. You can analyse the last=
2016 blocks to find the average fee accepted per kb (which would include t=
ransactions that were included without fees) and then write that into the b=
lock as a soft recommendation that wallets could use in the UI. This way th=
e price can vary up and down according to what people were willing to spend=
on fees and miners willing to accept.<br>
</div></div></blockquote><div><br></div><div>That's what fee estimation=
does, essentially, minus the encoding into blocks. Once you start getting =
miners telling people what fees are directly you run into cases where they =
might try to lie about their behaviour or otherwise influence the average. =
Querying all nodes avoids that problem.</div>
</div></div></div>
--089e0160b3dcf72c4704ec9efe9d--
|
