From: Gregory Maxwell <gmaxwell@gmail•com>
To: Watson Ladd <wbl@uchicago•edu>
Cc: bitcoin-development@lists•sourceforge.net
Subject: Re: [Bitcoin-development] Proposal for a new opcode
Date: Wed, 21 Mar 2012 20:49:20 -0400 [thread overview]
Message-ID: <CAAS2fgT1ZkGYx8y48SMSApMMYfaOOLwjsC-q0fTXGs1KHUfRMQ@mail.gmail.com> (raw)
In-Reply-To: <CACsn0cn70Kj+HbhNHEJtdbNSFQM_aeUWJ=dc+gDjpseRivT-qg@mail.gmail.com>
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— but the participants could
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— 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 hashes.
prev parent reply other threads:[~2012-03-22 0:49 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CACsn0c=P1veYnmXe4E3qU0OC=Xr9Aw6Fy=6Zm0sUAaSBEDvpMA@mail.gmail.com>
2012-03-02 19:57 ` [Bitcoin-development] Fwd: " Watson Ladd
2012-03-03 17:55 ` Gavin Andresen
2012-03-05 14:14 ` [Bitcoin-development] " Michael Grønager
2012-03-07 0:05 ` [Bitcoin-development] Fwd: " Gregory Maxwell
2012-03-07 0:42 ` Watson Ladd
2012-03-21 19:54 ` Gregory Maxwell
[not found] ` <CACsn0cmfwuBpFTTMZ9psOoTKb3ovmAdb=VTSYQ7LJaf8+YzTUg@mail.gmail.com>
2012-03-21 22:02 ` [Bitcoin-development] " Watson Ladd
2012-03-22 0:49 ` Gregory Maxwell [this message]
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=CAAS2fgT1ZkGYx8y48SMSApMMYfaOOLwjsC-q0fTXGs1KHUfRMQ@mail.gmail.com \
--to=gmaxwell@gmail$(echo .)com \
--cc=bitcoin-development@lists$(echo .)sourceforge.net \
--cc=wbl@uchicago$(echo .)edu \
/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