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.
> 
> 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/msg03508.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)

-- 
'peter'[:-1]@petertodd.org
000000000000000051ad2df596f45df71320fb44b3c5f1b50231a591ffeb1d24