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
|
Received: from sog-mx-4.v43.ch3.sourceforge.com ([172.29.43.194]
helo=mx.sourceforge.net)
by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76)
(envelope-from <pete@petertodd.org>) id 1VnBVK-0001IG-S9
for bitcoin-development@lists.sourceforge.net;
Sun, 01 Dec 2013 18:12:26 +0000
Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of petertodd.org
designates 62.13.149.77 as permitted sender)
client-ip=62.13.149.77; envelope-from=pete@petertodd.org;
helo=outmail149077.authsmtp.com;
Received: from outmail149077.authsmtp.com ([62.13.149.77])
by sog-mx-4.v43.ch3.sourceforge.com with esmtp (Exim 4.76)
id 1VnBVI-0007V7-Rt for bitcoin-development@lists.sourceforge.net;
Sun, 01 Dec 2013 18:12:26 +0000
Received: from mail-c235.authsmtp.com (mail-c235.authsmtp.com [62.13.128.235])
by punt15.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB1ICI1x057770;
Sun, 1 Dec 2013 18:12:18 GMT
Received: from tilt (ppp-82-84-150-184.cust-adsl.tiscali.it [82.84.150.184]
(may be forged)) (authenticated bits=128)
by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id rB1ICBbK043441
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO);
Sun, 1 Dec 2013 18:12:14 GMT
Date: Sun, 1 Dec 2013 13:12:11 -0500
From: Peter Todd <pete@petertodd.org>
To: Mike Hearn <mike@plan99.net>
Message-ID: <20131201181211.GA20533@tilt>
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>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha256;
protocol="application/pgp-signature"; boundary="liOOAslEiF7prFVr"
Content-Disposition: inline
In-Reply-To: <39921E12-B411-4430-9D56-04F53906B109@plan99.net>
User-Agent: Mutt/1.5.21 (2010-09-15)
X-Server-Quench: 1b0239f6-5ab4-11e3-b802-002590a15da7
X-AuthReport-Spam: If SPAM / abuse - report it at:
http://www.authsmtp.com/abuse
X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR
aQdMdgMUHFAXAgsB AmUbWlxeUV97WGc7 YwhPZQFDY09OQQRi
VFdMSlVNFUsqcx14 dWxMKRl2dAFCeTBx YkFgVj5aDkR4dk8r
RFNRRD8CeGZhPWMC AkhYdR5UcAFPdx8U a1UrBXRDAzANdhES
HhM4ODE3eDlSNilR RRkIIFQOdA4lGjk1 WxEEEn0hEEAeDyw1
I1QdEmBUF0IQP0Mu KjMA
X-Authentic-SMTP: 61633532353630.1023:706
X-AuthFastPath: 0 (Was 255)
X-AuthSMTP-Origin: 82.84.150.184/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: petertodd.org]
X-Headers-End: 1VnBVI-0007V7-Rt
Cc: bitcoin-development@lists.sourceforge.net,
Andreas Schildbach <andreas@schildbach.de>
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: Sun, 01 Dec 2013 18:12:27 -0000
--liOOAslEiF7prFVr
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Dec 01, 2013 at 06:19:14PM +0100, Mike Hearn wrote:
> > Both can be combined into adapting the current generic messages ("This
> > payment should become spendable shortly" for incoming and "This payment
> > has not been transmitted yet" for outgoing transactions).=20
>=20
> What would the new messages say?
>=20
> We need to get away from the notion of senders attaching fees anyway. Thi=
s is the wrong way around because it=E2=80=99s the recipient who cares abou=
t double spending risk, not the sender. That=E2=80=99s why merchants keep r=
unning into issues with people attaching zero fees. Of course they attach z=
ero fees. They know they aren=E2=80=99t going to double spend. It=E2=80=99s=
the merchant who cares about getting the security against that.
>=20
> The UI for sending money should end up dead simple - no mention of fees a=
nywhere, IMO.
>=20
> The UI for receiving money could be a bit more complicated but even then =
- I think if ordinary people using smartphone wallets are having to think a=
bout how quickly they want their transaction to confirm and adjust fees, et=
c on the receiving side then we=E2=80=99re getting dangerously close to the=
usability failure zone.
>=20
> Unfortunately we lack the protocol pieces to get the right UI here :( Som=
eone needs to sit down and figure out what the UI *should* look like, in th=
e ideal world, and then work backwards to figure out what needs to be done =
to get us there.
>=20
> > For outgoing transactions, if it is very clear that they're never going
> > to be confirmed, I'd like to see a "Revoke" button.
>=20
> Disagree. There should never be any cases in which a transaction doesn=E2=
=80=99t confirm. Period. I know there have been bugs with bitcoinj that cou=
ld cause this in the past, but they were bugs and they got fixed/will get f=
ixed.
>=20
> Settlement failure is just unacceptable and building a UI around the poss=
ibility will just encourage people to think of it as normal, when it should=
not be so.
Bitcoin is and always will be limited in capacity - transactions may not
confirm in a reasonable about of time because of high-demand and/or DoS
attacks. Giving senders and/or receivers the ability to increase fees
after the fact is the only way you'll ever be able to deal with these
situations. Of course, in those situations revoke isn't going to be 100%
reliable until the txins get spent elsewhere, but that just indicates
the UI problem is around that kind of functionality is subtle.
re: merchants paying tx fees, child-pays-for-parent is inefficient, and
micropayments direct to miners isn't implemented. (though I did write up
a rough sketch of how to do that in a decentralized fashion on
#bitcoin-dev) Propose something concrete.
--=20
'peter'[:-1]@petertodd.org
000000000000000f9102d27cfd61ea9e8bb324593593ca3ce6ba53153ff251b3
--liOOAslEiF7prFVr
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)
iQEcBAEBCAAGBQJSm3v6AAoJECSBQD2l8JH7Hh0IAJ20OKXnaJ39hcrzUlRBuR21
UGeJ5Giw4+q9UWroRujaLwuPJw94WNlf/ZU+xselhVCAo01+yjpqT83WnZX6nA8v
M/721PC0sbspaqHfLUqTBn0mgeIaZIl63fLR12DNTbFy/BtyC0x9355yfu+5BoXz
2i4gzeFyEtc3l2cQQnkIw2SbW9gKta5sFnnKhiMzaArJep6nLbghIWxxCl4NJz4X
iOjhw1tdgGpKJHLD0ALDkKLaB9Q/HJKH2ZgjuJwUjwzMO+xcQU6SjxKjuVykmoBc
lKhCzjAMOnPalHjY59/imf02KQREGSkF/voCeMHhNgdnVdN9i9aGMc1c83eI2XI=
=cXrX
-----END PGP SIGNATURE-----
--liOOAslEiF7prFVr--
|
