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
|
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 <pete@petertodd.org>) id 1VnoIQ-0003uq-NI
for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 11:37:42 +0000
Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.148.112 as permitted sender)
client-ip=62.13.148.112; envelope-from=pete@petertodd.org;
helo=outmail148112.authsmtp.co.uk;
Received: from outmail148112.authsmtp.co.uk ([62.13.148.112])
by sog-mx-2.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VnoIP-0005uQ-Ju for bitcoin-development@lists.sourceforge.net;
Tue, 03 Dec 2013 11:37:42 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt9.authsmtp.com (8.14.2/8.14.2) with ESMTP id rB3BbYjE092812;
Tue, 3 Dec 2013 11:37:34 GMT
Received: from tilt (ge-19-102-21.service.infuturo.it [151.19.102.21])
(authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB3BbSkU056185
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Tue, 3 Dec 2013 11:37:33 GMT
Date: Tue, 3 Dec 2013 06:37:25 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131203113725.GC12623@tilt>
References: <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>
<CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="rQ2U398070+RC21q"
Content-Disposition: inline
In-Reply-To: <CANEZrP0P9NTJXs22K8-4hnLkxV7Uo+tjvWKJ8msgxiFgJW6xvg@mail.gmail.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 4d6154d6-5c0f-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgEUHFAXAgsB AmUbWlVeU1p7Wmc7 ag9QcwRUfEtOXRto
UVdMSlVNFUsqcx9z VH1FNxl3cQROfTBx YENiWj5fCEJ7cEIp
RFNRRm1QeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4lGjk1 WxEEEn0hEEAeDyw1
I1QdEmBUF0IQP0Mu KjMA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 151.19.102.21/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.
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: petertodd.org]
-1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for
sender-domain
-0.0 SPF_PASS SPF: sender matches SPF record
X-Headers-End: 1VnoIP-0005uQ-Ju
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 11:37:42 -0000
--rQ2U398070+RC21q
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Tue, Dec 03, 2013 at 12:29:03PM +0100, Mike Hearn wrote:
> On Tue, Dec 3, 2013 at 12:07 PM, Gavin Andresen <gavinandresen@gmail.com>=
wrote:
>=20
> > Making it fee-per-kilobyte is a bad idea, in my opinion; users don't ca=
re
> > how many kilobytes their transactions are, and they will just be confus=
ed
> > if they're paying for a 10mBTC burger and are asked to pay 10.00011 or
> > 9.9994 because the merchant has no idea how many kilobytes the paying
> > transaction will be.
> >
>=20
> Wouldn't the idea be that the user always sees 10mBTC no matter what, but
> the receiver may receive less if the user decides to pay with a huge
> transaction?
>=20
> It may be acceptable that receivers don't always receive exactly what they
> requested, at least for person-to-business transactions. For
> person-to-person transactions of course any fee at all is confusing becau=
se
> you intuitively expect that if you send 1 mBTC, then 1 mBTC will arrive t=
he
> other end. I wonder if we'll end up in a world where buying things from
> shops involves paying fees, and (more occasional?) person-to-person
> transactions tend to be free and people just understand that the money
> isn't going to be spendable for a while. Or alternatively that wallets let
> you override the safeguards on spending unconfirmed coins when the user is
> sure that they trust the sender.
Person-to-person payments are an *excellent* argument for keeping fees
visible to end-users; people will pay other people commonly in Bitcoin
and they will be very confused if those transactions act weirdly
differently than payments to merchants.
NAK on unconfirmed overrides - if something goes wrong even by accident
it just makes fixing the problem much harder and less intuitive.
--=20
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
--rQ2U398070+RC21q
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJSncJ1AAoJECSBQD2l8JH7tj8IAJlG4aMK/+HjvkfaXe6fSjOO
I45tCamYPJzpx6cCjVasPyIRILyli8upWCZebSPNp2Drbd0cFnWmAbuLvTL4XXSm
kaelzHBkAjtA8vvcTaX9zl4/Eh5ingXXRWHOt2LctYmN9amxS+S63hg8hQjTsq6m
0ASOKBKLkDYLuopROwxt5ZtnAz2EyWYilYRGEIx7plKFmH1zIl785VPz7PvUyeRE
s1fwKBF/F4QCugzNePtGJL00YKCq3V+sy6m1vRBRg88Y8ZbVzYj9I3Nihi6V0TVk
4hIIJKUaQ90cLC4xeOfz6Hc8EQfq88v2jEa1pF1ZIi4iBQjjJ7mtuHopiMFCFlI=
=6uVK
-----END PGP SIGNATURE-----
--rQ2U398070+RC21q--
|
