From: Peter Todd <pete@petertodd•org>
To: "Ryan X. Charles" <ryan@bitpay•com>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] BIP70 proposed changes
Date: Tue, 18 Feb 2014 16:47:22 -0500 [thread overview]
Message-ID: <20140218214721.GA25356@savin> (raw)
In-Reply-To: <5303B110.70603@bitpay.com>
[-- Attachment #1: Type: text/plain, Size: 2417 bytes --]
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
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]
next prev parent reply other threads:[~2014-02-18 21:47 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-02-18 17:31 Andreas Schildbach
2014-02-18 19:14 ` Ryan X. Charles
2014-02-18 20:15 ` Gavin Andresen
2014-02-18 21:40 ` Andreas Schildbach
2014-02-19 14:10 ` Jeff Garzik
2014-02-19 16:44 ` Mike Hearn
2014-05-06 2:35 ` Odinn Cyberguerrilla
2014-05-06 8:22 ` Alon Muroch
2014-02-18 21:47 ` Peter Todd [this message]
2014-02-18 23:41 ` Bernd Jendrissek
2014-02-18 22:02 ` Derber
2014-02-21 15:34 ` Mike Hearn
2014-03-05 10:18 ` Mike Hearn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20140218214721.GA25356@savin \
--to=pete@petertodd$(echo .)org \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=ryan@bitpay$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox