Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.216.54 as permitted sender)
	client-ip=209.85.216.54; envelope-from=gmaxwell@gmail.com;
	helo=mail-qa0-f54.google.com; 
MIME-Version: 1.0
In-Reply-To: <CACsn0cn70Kj+HbhNHEJtdbNSFQM_aeUWJ=dc+gDjpseRivT-qg@mail.gmail.com>
References: <CACsn0c=P1veYnmXe4E3qU0OC=Xr9Aw6Fy=6Zm0sUAaSBEDvpMA@mail.gmail.com>
	<CACsn0cne5An+SyKDf9w4o4Secn7C9wqqbG7ff0HB3Dvk-XxHRg@mail.gmail.com>
	<CAAS2fgRQrD0=3p2aXUpXVWV3PeWw+=Do=2CAvx1cOqwYUFrOQw@mail.gmail.com>
	<CACsn0cmfwuBpFTTMZ9psOoTKb3ovmAdb=VTSYQ7LJaf8+YzTUg@mail.gmail.com>
	<CACsn0cn70Kj+HbhNHEJtdbNSFQM_aeUWJ=dc+gDjpseRivT-qg@mail.gmail.com>
Date: Wed, 21 Mar 2012 20:49:20 -0400
Message-ID: <CAAS2fgT1ZkGYx8y48SMSApMMYfaOOLwjsC-q0fTXGs1KHUfRMQ@mail.gmail.com>
From: Gregory Maxwell <gmaxwell@gmail.com>
To: Watson Ladd <wbl@uchicago.edu>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Cc: bitcoin-development@lists.sourceforge.net
Subject: Re: [Bitcoin-development] Proposal for a new opcode
Precedence: list

On Wed, Mar 21, 2012 at 6:02 PM, Watson Ladd <wbl@uchicago.edu> wrote:
> -My protocol works, your's doesn't. It's not enough to have a mix, the
> mix needs to be verifiable to avoid
> one of the mixers inserting their own key and removing a key that
> should be in there. That doesn't mean you can't make your protocol
> work with some more magic, but magic is required.

If the final step fails (someone says their address is missing) you
challenge the mixes to disclose half of their correspondences. You can
then prove which (if any) mixes defected.

Why I didn't bother elaborating is ... I think you can even avoid the
fancy protocol where you must take care to only disclose alternating
halves at each mix because the addresses are throwaway: If the it
fails in the final stage everyone publishes _everything_ and the
cheater is instantly and provably identified and can be excluded from
the next attempt which is then performed using totally new addresses
and the disclosed addresses are never used.  Care would need to be
taken to avoid fake-failures (e.g. the exchange says 'it fails'
triggering disclosure then sending anyways=E2=80=94 but the participants co=
uld
prove this cheating and stop using the exchange), I think there isn't
much risk there if the participants are themselves the mixes.  I need
to think this through a bit more.

[snip]
> On a related note, private keys and signatures have better proofs of
> knowledge then hashes. Has this been considered in the P2SH
> conversation? There might be ways to use this to make even better
> methods for enhancing anonymity.

It's not something I thought about=E2=80=94 In general the P2SH tends to be
a superset of other schemes, e.g. you can do a signature to prove you
access to a private key, then you can show someone a script using that
key to show control of a P2SH address.

There are lot of interesting things you can do with bitcoin if you can
construct (potentially interactive) proofs for knowing the preimages of has=
hes.