* [Bitcoin-development] Fwd: Proposal for a new opcode
[not found] <CACsn0c=P1veYnmXe4E3qU0OC=Xr9Aw6Fy=6Zm0sUAaSBEDvpMA@mail.gmail.com>
@ 2012-03-02 19:57 ` Watson Ladd
2012-03-03 17:55 ` Gavin Andresen
` (3 more replies)
0 siblings, 4 replies; 8+ messages in thread
From: Watson Ladd @ 2012-03-02 19:57 UTC (permalink / raw)
To: bitcoin-development
Dear all,
I am proposing a new opcode for the purposes of anonymous
transactions. This new opcode enables scripts to be given proof that
the receiver can carry out or has carried out a previous transaction.
I'm currently working on a paper that discusses using this opcode for
anonymous transactions.
Name: OP_CHECKEXPSIG
Stack before: <sig><pk><hash>
Stack after: T/F, where is true if sig is a ECDSA signature under pk
for the hash hash. (Hash is the hash of a message).
Uses: Preexisting digital cash techniques relied on keeping track of a
list of turned in notes to forbid double spending. Using
OP_CHECKEXPSIG we can instead pass the script that gives the nth note
value proof that the notes {1,...n-1} were turned in and are distinct.
This enables a coupling of the strong double spend protection of
Bitcoin with traditional digital cash's strong anonymity.
Sincerely,
Watson Ladd
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Fwd: Proposal for a new opcode
2012-03-02 19:57 ` [Bitcoin-development] Fwd: Proposal for a new opcode Watson Ladd
@ 2012-03-03 17:55 ` Gavin Andresen
2012-03-05 14:14 ` [Bitcoin-development] " Michael Grønager
` (2 subsequent siblings)
3 siblings, 0 replies; 8+ messages in thread
From: Gavin Andresen @ 2012-03-03 17:55 UTC (permalink / raw)
To: Watson Ladd; +Cc: bitcoin-development
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl@uchicago•edu> wrote:
> Dear all,
> I am proposing a new opcode for the purposes of anonymous
> transactions.
That's very exciting! I'm eager to read the paper for all of the
details, and working out what else would need to be done besides a new
opcode to enable strong anonymity (at the very least, I assume we'll
need one or more new 'standard' transaction types that clients
understand).
--
--
Gavin Andresen
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Proposal for a new opcode
2012-03-02 19:57 ` [Bitcoin-development] Fwd: Proposal for a new opcode Watson Ladd
2012-03-03 17:55 ` Gavin Andresen
@ 2012-03-05 14:14 ` Michael Grønager
2012-03-07 0:05 ` [Bitcoin-development] Fwd: " Gregory Maxwell
2012-03-21 19:54 ` Gregory Maxwell
3 siblings, 0 replies; 8+ messages in thread
From: Michael Grønager @ 2012-03-05 14:14 UTC (permalink / raw)
To: Watson Ladd; +Cc: bitcoin-development
Sounds interesting, however, even after a couple of days, I cannot see how you maintain protection against double spend using OP_CHECKEXPSIG. It is not until you redeem the OP_CHECKEXPSIG transaction that you reveal which former transactions that was involved?
I guess I am missing a point here?
/M
On 02/03/2012, at 20:57, Watson Ladd wrote:
> Dear all,
> I am proposing a new opcode for the purposes of anonymous
> transactions. This new opcode enables scripts to be given proof that
> the receiver can carry out or has carried out a previous transaction.
> I'm currently working on a paper that discusses using this opcode for
> anonymous transactions.
>
> Name: OP_CHECKEXPSIG
> Stack before: <sig><pk><hash>
> Stack after: T/F, where is true if sig is a ECDSA signature under pk
> for the hash hash. (Hash is the hash of a message).
> Uses: Preexisting digital cash techniques relied on keeping track of a
> list of turned in notes to forbid double spending. Using
> OP_CHECKEXPSIG we can instead pass the script that gives the nth note
> value proof that the notes {1,...n-1} were turned in and are distinct.
> This enables a coupling of the strong double spend protection of
> Bitcoin with traditional digital cash's strong anonymity.
>
> Sincerely,
> Watson Ladd
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Michael Gronager, PhD
Director, Ceptacle
Jens Juels Gade 33
2100 Copenhagen E
Mobile: +45 31 45 14 01
E-mail: gronager@ceptacle•com
Web: http://www.ceptacle.com/
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Fwd: Proposal for a new opcode
2012-03-02 19:57 ` [Bitcoin-development] Fwd: Proposal for a new opcode Watson Ladd
2012-03-03 17:55 ` Gavin Andresen
2012-03-05 14:14 ` [Bitcoin-development] " Michael Grønager
@ 2012-03-07 0:05 ` Gregory Maxwell
2012-03-07 0:42 ` Watson Ladd
2012-03-21 19:54 ` Gregory Maxwell
3 siblings, 1 reply; 8+ messages in thread
From: Gregory Maxwell @ 2012-03-07 0:05 UTC (permalink / raw)
To: Watson Ladd; +Cc: bitcoin-development
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl@uchicago•edu> wrote:
> I am proposing a new opcode for the purposes of anonymous
> transactions. This new opcode enables scripts to be given proof that
> the receiver can carry out or has carried out a previous transaction.
> I'm currently working on a paper that discusses using this opcode for
> anonymous transactions.
I believe I understand what the opcode does directly— it just
validates an opaque signautre. I don't understand how it enables
anonymous transactions.
Can you spell this out for me?
In particular I don't see why it is not, from the perspective of the
blockchain, isomorphic to a hash locked transaction. (This
equivalence is more obvious when you think about how lamport
signtures turn simple hashing into a one time signature).
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Fwd: Proposal for a new opcode
2012-03-07 0:05 ` [Bitcoin-development] Fwd: " Gregory Maxwell
@ 2012-03-07 0:42 ` Watson Ladd
0 siblings, 0 replies; 8+ messages in thread
From: Watson Ladd @ 2012-03-07 0:42 UTC (permalink / raw)
To: Gregory Maxwell; +Cc: bitcoin-development
On Tue, Mar 6, 2012 at 6:05 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl@uchicago•edu> wrote:
>> I am proposing a new opcode for the purposes of anonymous
>> transactions. This new opcode enables scripts to be given proof that
>> the receiver can carry out or has carried out a previous transaction.
>> I'm currently working on a paper that discusses using this opcode for
>> anonymous transactions.
>
> I believe I understand what the opcode does directly— it just
> validates an opaque signautre. I don't understand how it enables
> anonymous transactions.
>
> Can you spell this out for me?
One doesn't use this opcode as the sole thing to secure a transaction.
Instead this opcode prevents double spend attacks against
anonymization schemes. The idea is for Alice to give signatures to the
recipients of funds, all signatures being equivalent. To avoid this
from leading to a double-spend, we use a quorum method based on
showing earlier redemptions happened.
>
> In particular I don't see why it is not, from the perspective of the
> blockchain, isomorphic to a hash locked transaction. (This
> equivalence is more obvious when you think about how lamport
> signtures turn simple hashing into a one time signature).
Because you can't blind a lamport signature, it isn't. I'm searching
for a place to post the current draft: it's not ready for anything
official yet, but does seem to be of interest. Drop me a (offlist)line
if you have ideas about where I can put it.
Sincerely,
Watson Ladd
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Fwd: Proposal for a new opcode
2012-03-02 19:57 ` [Bitcoin-development] Fwd: Proposal for a new opcode Watson Ladd
` (2 preceding siblings ...)
2012-03-07 0:05 ` [Bitcoin-development] Fwd: " Gregory Maxwell
@ 2012-03-21 19:54 ` Gregory Maxwell
[not found] ` <CACsn0cmfwuBpFTTMZ9psOoTKb3ovmAdb=VTSYQ7LJaf8+YzTUg@mail.gmail.com>
3 siblings, 1 reply; 8+ messages in thread
From: Gregory Maxwell @ 2012-03-21 19:54 UTC (permalink / raw)
To: Watson Ladd; +Cc: bitcoin-development
On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl@uchicago•edu> wrote:
> Dear all,
> I am proposing a new opcode for the purposes of anonymous
> transactions. This new opcode enables scripts to be given proof that
> the receiver can carry out or has carried out a previous transaction.
> I'm currently working on a paper that discusses using this opcode for
> anonymous transactions.
Here is an alternative protocol:
N parties wish to purchase equal amounts of Bitcoin without the
exchange being able to link their future transactions, they each put
the relevant amount of gold/whatever up at the exchange.
The exchange provides the exchanges public key, and the user provides
a public key for signing. Externally the N participants agree on a
collection of non-cooperating mixers (the mixers may actually just be
the participants themselves, independent third parties, etc). Each
participant generates a new bitcoin address, and encrypts it with the
the public keys of the the exchange and all the mixers using an
appropriate communicative homorophic scheme (or just a layers stack of
regular encryption keys). The participants then combine their
encrypted addresess into a block and hand it off to the mixing chain.
Each mixer randomizes the order and decrypts all the messages with its
key.
At the end of the chain the exchange does the final decryption and
presents a list of addresses to the involved users. Users validate
that their address is in the set and sign the entire set. Once all
involved users have signed, the exchange pays.
This requires no changes to the Bitcoin system and could be trivially
implemented by anyone interested. It provides anonymity which is
strong so long as any one of the mixers is uncompromised. It has very
low overhead. It is not directly resistant to disruption, but if
participation in an identified round requires a key provided by the
exchange, abusive users can be detected and excluded.
Have I explained this clearly enough? I could probably implement the
whole system it if its unclear.
Can you contrast this with your proposal for me?
^ permalink raw reply [flat|nested] 8+ messages in thread
* [Bitcoin-development] Proposal for a new opcode
[not found] ` <CACsn0cmfwuBpFTTMZ9psOoTKb3ovmAdb=VTSYQ7LJaf8+YzTUg@mail.gmail.com>
@ 2012-03-21 22:02 ` Watson Ladd
2012-03-22 0:49 ` Gregory Maxwell
0 siblings, 1 reply; 8+ messages in thread
From: Watson Ladd @ 2012-03-21 22:02 UTC (permalink / raw)
To: bitcoin-development
On Wed, Mar 21, 2012 at 3:54 PM, Gregory Maxwell <gmaxwell@gmail•com> wrote:
> On Fri, Mar 2, 2012 at 2:57 PM, Watson Ladd <wbl@uchicago•edu> wrote:
>> Dear all,
>> I am proposing a new opcode for the purposes of anonymous
>> transactions. This new opcode enables scripts to be given proof that
>> the receiver can carry out or has carried out a previous transaction.
>> I'm currently working on a paper that discusses using this opcode for
>> anonymous transactions.
>
>
> Here is an alternative protocol:
>
>
> N parties wish to purchase equal amounts of Bitcoin without the
> exchange being able to link their future transactions, they each put
> the relevant amount of gold/whatever up at the exchange.
>
> The exchange provides the exchanges public key, and the user provides
> a public key for signing. Externally the N participants agree on a
> collection of non-cooperating mixers (the mixers may actually just be
> the participants themselves, independent third parties, etc). Each
> participant generates a new bitcoin address, and encrypts it with the
> the public keys of the the exchange and all the mixers using an
> appropriate communicative homorophic scheme (or just a layers stack of
> regular encryption keys). The participants then combine their
> encrypted addresess into a block and hand it off to the mixing chain.
> Each mixer randomizes the order and decrypts all the messages with its
> key.
>
> At the end of the chain the exchange does the final decryption and
> presents a list of addresses to the involved users. Users validate
> that their address is in the set and sign the entire set. Once all
> involved users have signed, the exchange pays.
>
>
> This requires no changes to the Bitcoin system and could be trivially
> implemented by anyone interested. It provides anonymity which is
> strong so long as any one of the mixers is uncompromised. It has very
> low overhead. It is not directly resistant to disruption, but if
> participation in an identified round requires a key provided by the
> exchange, abusive users can be detected and excluded.
>
> Have I explained this clearly enough? I could probably implement the
> whole system it if its unclear.
>
> Can you contrast this with your proposal for me?
Contrasts
-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.
-You need a lot of online computation: the recipients need to be
involved with validating the mix. By contrast in mine you need to wait for
enough people to get their bitcoins to avoid partitioning. But this
might be a strength,
not a weakness.
-You avoid the problem of de-anonymizing through having the protocol
run incompletely: if the permutation is correctly computed the
transaction goes through.
-You also avoid all the problems with modifications to the bitcoin
clients and miners.
It's definitely a good alternative, once you fix the problem in 1.
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.
Sincerely,
Watson Ladd
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
--
"Those who would give up Essential Liberty to purchase a little
Temporary Safety deserve neither Liberty nor Safety."
-- Benjamin Franklin
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [Bitcoin-development] Proposal for a new opcode
2012-03-21 22:02 ` [Bitcoin-development] " Watson Ladd
@ 2012-03-22 0:49 ` Gregory Maxwell
0 siblings, 0 replies; 8+ messages in thread
From: Gregory Maxwell @ 2012-03-22 0:49 UTC (permalink / raw)
To: Watson Ladd; +Cc: bitcoin-development
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.
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2012-03-22 0:49 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <CACsn0c=P1veYnmXe4E3qU0OC=Xr9Aw6Fy=6Zm0sUAaSBEDvpMA@mail.gmail.com>
2012-03-02 19:57 ` [Bitcoin-development] Fwd: Proposal for a new opcode 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 is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox