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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <mh.in.england@gmail.com>) id 1Vo9sF-0002SO-Ul
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 10:40:07 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
designates 209.85.214.179 as permitted sender)
client-ip=209.85.214.179; envelope-from=mh.in.england@gmail.com;
helo=mail-ob0-f179.google.com;
Received: from mail-ob0-f179.google.com ([209.85.214.179])
by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128)
(Exim 4.76) id 1Vo9sE-0008Jl-5x
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 10:40:07 +0000
Received: by mail-ob0-f179.google.com with SMTP id wm4so15687702obc.24
for <bitcoin-development@lists.sourceforge.net>;
Wed, 04 Dec 2013 02:40:00 -0800 (PST)
MIME-Version: 1.0
X-Received: by 10.60.16.97 with SMTP id f1mr93562oed.77.1386153600580; Wed, 04
Dec 2013 02:40:00 -0800 (PST)
Sender: mh.in.england@gmail.com
Received: by 10.76.3.134 with HTTP; Wed, 4 Dec 2013 02:40:00 -0800 (PST)
In-Reply-To: <op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net>
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>
<CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>
<op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net>
Date: Wed, 4 Dec 2013 11:40:00 +0100
X-Google-Sender-Auth: 3Sv82EhHJjhUU50O-NmkjZIZD0c
Message-ID: <CANEZrP3D4WhXTdMAT7B=DaXEOSdXESc+bU0n7enu7hSaGtns8A@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Jeremy Spilman <jeremy@taplink.co>
Content-Type: multipart/alternative; boundary=089e013d08c4f7864e04ecb30835
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
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: 1Vo9sE-0008Jl-5x
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: Wed, 04 Dec 2013 10:40:08 -0000
--089e013d08c4f7864e04ecb30835
Content-Type: text/plain; charset=UTF-8
I think this US/other cultural issue is complicating things more than we
appreciate.
I am trying to imagine in my head how all this will work and what it will
look like with allow_fee, and I just can't see it. Merchants want customers
to pay the sticker price, deviance from that social norm is extremely rare
even after the credit card company contracts that required it have been
invalidated. The only time it happens to me is when buying flight tickets
with credit cards: but it's only for that method, other payment methods are
still treated as "free" a.k.a interior fees.
If you walk into a physical shop and try to pay a large bill with bags of
pennies, the merchant won't enter into a complicated agreement where they
agree to split the cost of processing with you. They will just reject the
payment out of hand and tell you to get real. It has to be that way because
otherwise the shop would carry the cost of counting all the pennies and
hauling them around, not the buyer (who "knows" he put the right number of
pennies in the bags).
As a buyer, I do not care about whether my transaction will confirm. If I
try to pay with dust, there is no incentive for me to attach a higher fee
than allow_fee to make that confirm, especially if the merchant has no way
to reject the payment. What's more, as Jeremy points out, no clean fail
mechanism means large piles of manual work and lots of disputes due to
payments not clearing before the exchange rate shifts and other things like
that.
Trying to make the success of payment confirmation a two-person dance seems
to have so many edge cases it makes my head hurt. For most pay-to-merchant
cases, it has to be the receivers job to get a transaction confirmed, and
if the sender doesn't follow the instructions a payment should hard fail
and require trying again. If Bitcoin-Qt can't handle that today, that does
seem like a problem.
In the case of a transaction with too-low fee, either the payer can
> double-spend with a higher fee
You can't do that. When a tx doesn't have the right fee attached you're out
of luck today, except for the fact that some pools run with a custom child
pays for parent patch. So respending it would bump priority for some miners
and not others.
--089e013d08c4f7864e04ecb30835
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"><div=
>I think this US/other cultural issue is complicating things more than we a=
ppreciate.</div><div><br></div><div>I am trying to imagine in my head how a=
ll this will work and what it will look like with allow_fee, and I just can=
't see it. Merchants want customers to pay the sticker price, deviance =
from that social norm is extremely rare even after the credit card company =
contracts that required it have been invalidated. The only time it happens =
to me is when buying flight tickets with credit cards: but it's only fo=
r that method, other payment methods are still treated as "free" =
a.k.a interior fees.</div>
<div><br></div><div>If you walk into a physical shop and try to pay a large=
bill with bags of pennies, the merchant won't enter into a complicated=
agreement where they agree to split the cost of processing with you. They =
will just reject the payment out of hand and tell you to get real. It has t=
o be that way because otherwise the shop would carry the cost of counting a=
ll the pennies and hauling them around, not the buyer (who "knows"=
; he put the right number of pennies in the bags).</div>
<div><br></div><div>As a buyer, I do not care about whether my transaction =
will confirm. If I try to pay with dust, there is no incentive for me to at=
tach a higher fee than allow_fee to make that confirm, especially if the me=
rchant has no way to reject the payment. What's more, as Jeremy points =
out, no clean fail mechanism means large piles of manual work and lots of d=
isputes due to payments not clearing before the exchange rate shifts and ot=
her things like that.=C2=A0</div>
<div><br></div><div>Trying to make the success of payment confirmation a tw=
o-person dance seems to have so many edge cases it makes my head hurt. For =
most pay-to-merchant cases, it has to be the receivers job to get a transac=
tion confirmed, and if the sender doesn't follow the instructions a pay=
ment should hard fail and require trying again. If Bitcoin-Qt can't han=
dle that today, that does seem like a problem.</div>
<div><br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0p=
x 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-lef=
t-style:solid;padding-left:1ex">In the case of a transaction with too-low f=
ee, either the payer can double-spend with a higher fee</blockquote>
<div><br></div><div>You can't do that. When a tx doesn't have the r=
ight fee attached you're out of luck today, except for the fact that so=
me pools run with a custom child pays for parent patch. So respending it wo=
uld bump priority for some miners and not others.</div>
</div></div></div>
--089e013d08c4f7864e04ecb30835--
|
