From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-3.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1WFsVd-0005Pt-6H for bitcoin-development@lists.sourceforge.net; Tue, 18 Feb 2014 21:47:21 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of petertodd.org designates 62.13.148.98 as permitted sender) client-ip=62.13.148.98; envelope-from=pete@petertodd.org; helo=outmail148098.authsmtp.com; Received: from outmail148098.authsmtp.com ([62.13.148.98]) by sog-mx-3.v43.ch3.sourceforge.com with esmtp (Exim 4.76) id 1WFsVb-0000fP-Am for bitcoin-development@lists.sourceforge.net; Tue, 18 Feb 2014 21:47:21 +0000 Received: from mail-c237.authsmtp.com (mail-c237.authsmtp.com [62.13.128.237]) by punt17.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1ILlCI1099346; Tue, 18 Feb 2014 21:47:12 GMT Received: from savin (76-10-178-109.dsl.teksavvy.com [76.10.178.109]) (authenticated bits=128) by mail.authsmtp.com (8.14.2/8.14.2/) with ESMTP id s1ILl7N7013492 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 18 Feb 2014 21:47:10 GMT Date: Tue, 18 Feb 2014 16:47:22 -0500 From: Peter Todd To: "Ryan X. Charles" Message-ID: <20140218214721.GA25356@savin> References: <5303B110.70603@bitpay.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="0F1p//8PRICkK4MW" Content-Disposition: inline In-Reply-To: <5303B110.70603@bitpay.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-Server-Quench: 3849ab7f-98e6-11e3-94fa-002590a135d3 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwoUHlAWAgsB AmIbWVVeVFp7WGM7 bAxPbAVDY01GQQRq WVdMSlVNFUsrAGV9 WhlgVRlzdAFPejBx ZEFkXj5YVEBzJBR6 FFNdHTgAeGZhPWMC WUQOJh5UcAFPdx8U a1N6AHBDAzANdhES HhM4ODE3eDlSNilR RRkIIFQOdA4hPwZj H1gaBzI3GlYIS204 LxUgJVMHdAAA X-Authentic-SMTP: 61633532353630.1024:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 76.10.178.109/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 X-Headers-End: 1WFsVb-0000fP-Am Cc: bitcoin-development@lists.sourceforge.net Subject: Re: [Bitcoin-development] BIP70 proposed changes 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: Tue, 18 Feb 2014 21:47:21 -0000 --0F1p//8PRICkK4MW Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 18, 2014 at 02:14:24PM -0500, Ryan X. Charles wrote: > The payment protocol is also the perfect opportunity to implement merge > avoidance to increase customer and merchant privacy. The merchant can > simply deliver multiple outputs in the payment details, say 10 or so, > and the customer can spend multiple outputs to those outputs in separate > transactions. It would be great if BitPay could work with wallet authors > to make merge avoidance a reality in the near-term. >=20 > Merge avoidance would increase the need to have a bitcoin-paymentstatus > message since it's possible that some, but not all, of the transactions > would confirm, and so knowing the status of payment would be a complex > question that should be handled automatically by the software. Note that merge-avoidance implemented in conjunction CoinJoin doesn't have this problem - the CoinJoin'd transaction either does or doesn't confirm. Meanwhile being able to avoid merges, or more precisely, being able to be flexible with them, makes achiving good value-privacy much easier. Secondly merge-flexibility also makes cut-thru payments possible. For example BitPay can direct customers paying for goods to pay to addresses controlled by merchants and other parties who are owed money by BitPay. This skips a step, saving on transction fees as well as increasing privacy. Notably in this case the only parties that have to deal with accounting complexity are BitPay and the merchants - consumers' wallet software needs no changes beyond generic payment protocol support, and notably you can even use this technique without the payment protocol. See my post "DarkWallet Best Practices" for more info: http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg03= 508.html > On an unrelated note, X.509 is a terrible standard that should be > abandoned as quickly as possible. BitPay is working on a new standard > based on bitcoin-like addresses for authentication. It would be great if > we could work with the community to establish a complete, decentralized > authentication protocol. The sooner we can evolve beyond X.509 the better. What specifically do you dislike about X.509? The technical standard or the infrastructure around it? (IE the centralized authorities) --=20 'peter'[:-1]@petertodd.org 000000000000000051ad2df596f45df71320fb44b3c5f1b50231a591ffeb1d24 --0F1p//8PRICkK4MW Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.14 (GNU/Linux) iQGrBAEBCACVBQJTA9TpXhSAAAAAABUAQGJsb2NraGFzaEBiaXRjb2luLm9yZzAw MDAwMDAwMDAwMDAwMDA1MWFkMmRmNTk2ZjQ1ZGY3MTMyMGZiNDRiM2M1ZjFiNTAy MzFhNTkxZmZlYjFkMjQvFIAAAAAAFQARcGthLWFkZHJlc3NAZ251cGcub3JncGV0 ZUBwZXRlcnRvZC5vcmcACgkQJIFAPaXwkft5VQf9G7sebMqLguwzLRdssq1s5n5a 2CBz9Hl0oxO+CGMLVwTbCIqxZDd8g5mDWAZfyKmlp2PuRx3+brX1fr5oZOa1dZLr Uq5DsulDV8WmlHqo/WYFhfMXocVgCVMZ8q4Hzh1FVGkl9PnYIykNaOHsTwD5CHVC cYIpxm5XWx7EHIMGO1Sge9LWG/eEn1LAAja13472fPUOOWkWwTV9FWUotVVb8bcM GYc6tk3OuxUOmkeYC1UEGPPAVHtL5hcW5/MS3j+TtxZc0kKFX1pMlmQcyeGAUWFr MmX85gYFL7/X3SD/Cgo0oegGwQDEgYtDQErgOBjBbvLi+Jt/jkVxjxLrpLZHAw== =sijw -----END PGP SIGNATURE----- --0F1p//8PRICkK4MW--