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
|
Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VoA9b-0001qT-Jr
for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 10:58:03 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.56 as permitted sender)
client-ip=62.13.149.56; envelope-from=pete@petertodd.org;
helo=outmail149056.authsmtp.com;
Received: from outmail149056.authsmtp.com ([62.13.149.56])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VoA9a-0000ie-2u for bitcoin-development@lists.sourceforge.net;
Wed, 04 Dec 2013 10:58:03 +0000
Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237])
by punt10.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB4AvtKw076676;
Wed, 4 Dec 2013 10:57:55 GMT
Received: from [10.28.39.245] (pa-18-178-222.service.infuturo.it
[151.18.178.222]) (authenticated bits=0)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB4AvpGY083443;
Wed, 4 Dec 2013 10:57:52 GMT
User-Agent: K-9 Mail for Android
In-Reply-To: <CANEZrP3D4WhXTdMAT7B=DaXEOSdXESc+bU0n7enu7hSaGtns8A@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>
<CABsx9T322nCvynRCL6Mb9C0f5EuJSfMDTSGiU+_JsYoSCb=_kQ@mail.gmail.com>
<op.w7jnreqwyldrnw@laptop-air.hsd1.ca.comcast.net>
<CANEZrP3D4WhXTdMAT7B=DaXEOSdXESc+bU0n7enu7hSaGtns8A@mail.gmail.com>
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Content-Type: text/plain;
charset=UTF-8
From: Peter Todd <pete@petertodd.org>
Date: Wed, 04 Dec 2013 11:57:48 +0100
To: Mike Hearn <mike@plan99.net>, Jeremy Spilman <jeremy@taplink.co>
Message-ID: <e4515a76-b4c1-4a5f-a884-6d692b8d3466@email.android.com>
X-Server-Quench: ecfc2f02-5cd2-11e3-94fa-002590a135d3
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgYUHFAXAgsB AmUbWlReVVp7XGc7 ag9QcwRVfEtJVxto
UkpWR1pVCwUmQ24F d1heJXByfwZCfH0+ ZENkW3cVCRcsJkQr
QkxJED5SZ3phaTUc TUlcIVJJcANIexZF O1F8UScOLwdSbGoL
NQ4vNDcwO3BTJTpY RgYVKF8UXXNDMDo7 TgwDGzpnE0AIXG06
KRBuEWYiVE0VM0g0 LUBJ
X-Authentic-SMTP: 61633532353630.1024:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 151.18.178.222/587
X-AuthVirus-Status: No virus detected - but ensure you scan with your own
anti-virus system.
X-Spam-Score: -1.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 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: plan99.net]
X-Headers-End: 1VoA9a-0000ie-2u
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:58:03 -0000
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
Mike Hearn <mike@plan99.net> wrote:
>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.
Here at the dark wallet conf there seems yo be rough consensus that replacement for fee bumping is a good thing and should be supported; I was talking to Taylor from hive specifically yesterday. The code is trivial on the node side of things and doesn't need consent of anymore than a small minority, and coinjoin forces wallets to handle double spends well anyway. I haven't heard anyone caring about zeroconf safety.
I'll be proposing it for "formal" inclusion in our wallet best practices guidelines.
Also fwiw apparently libbitcoin already implements a memory limited mempool and Amir is open to the idea of it using the satoshi consensus critical code for block validity. (therefor fairly safe mining) I wouldn't be surprised if libbitcoin based nodes start getting usage, and with a limited mempool it is very DoS attack safe for them to relay replacements regardless of miner support.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.0.9
iQFQBAEBCAA6BQJSnwqsMxxQZXRlciBUb2RkIChsb3cgc2VjdXJpdHkga2V5KSA8
cGV0ZUBwZXRlcnRvZGQub3JnPgAKCRAZnIM7qOfwhR5yCAC3vaQQeoBrLdqn/rO5
Dzblqwl1B6AE1UjFj5+abQEZ2+uPy5P+7dZidpUn8Ms+tDDcCCge6HVOg+UeseaE
8pDP3+VIHZHH+9n6Y3+4facLNpQ3dP/+Zsg4pC+QSAjVV6408+yWPLtpbC6V0apK
T6K4qdq0Ct6V+54Ol0Thx+5cJlWLI+XbW2eXze3WjJzj3FgZUK0udBcVWa8JyWAV
WD1tv8DpPoUvDDzdmjEyf0EdjvcmamH9mcIvtxRdVwzyY/siZoizv9X8/gXNL+fg
JJ3Oxwrl1dOYSeENgp9VP8fU7GK7855bT1Wxd5zGNW7p/1gNxN4Lnx57XSMz2IHc
dHbg
=dcYz
-----END PGP SIGNATURE-----
|
