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; 
Date: Tue, 18 Feb 2014 16:47:22 -0500
From: Peter Todd <pete@petertodd.org>
To: "Ryan X. Charles" <ryan@bitpay.com>
Message-ID: <20140218214721.GA25356@savin>
References: <le05ca$qn5$1@ger.gmane.org>
 <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)
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] BIP70 proposed changes
Precedence: list


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