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; 
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)
Cc: bitcoin-development@lists.sourceforge.net,
	Andreas Schildbach <andreas@schildbach.de>
Subject: Re: [Bitcoin-development] Floating fees and SPV clients
Precedence: list


--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--