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 ) 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 To: Mike Hearn Message-ID: <20131201181211.GA20533@tilt> References: <5E4597E4-C1C7-4536-8CF0-82EDD7715DAB@plan99.net> <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 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: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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--