From: Tier Nolan <tier.nolan@gmail.com>
Cc: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] The first successful Zero-Knowledge Contingent Payment
Date: Fri, 26 Feb 2016 23:33:51 +0000 [thread overview]
Message-ID: <CAE-z3OVpd99Xyd9xenJir=7qfr4KOx=_hDpKtEKzAqtzteNMyQ@mail.gmail.com> (raw)
In-Reply-To: <CAKzdR-rp0Bqkj3PLWHx4etHejy2C997M3fGJy702jPdVThxPZg@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4175 bytes --]
That is very interesting.
There has been some recent discussion about atomic cross chain transfers
between Bitcoin and legacy altcoins. For this purpose a legacy altcoin is
one that has strict IsStandard() rules and none of the advanced script
opcodes.
It has a requirement that Bob sends Alice a pair [hash_of_bob_private_key,
bob_public_key]. Bob has to prove that the hash is actually the result of
hashing the private key that matches bob_public_key.
This can be achieved with a cut-and-choose scheme. It uses a fee so that
an attacker loses money on average. It is vulnerable to an attacker who
doesn't mind losing money as long as the target loses money too.
Bob would have to prove that he has an x such that
xG = <bob_public_key>
hash(x) = hash_of_bob_private_key
Is the scheme fast enough such that an elliptic curve multiply would be
feasible? You mention 20 seconds for 5 SHA256 operations, so I am guessing
no?
On Fri, Feb 26, 2016 at 11:06 PM, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Congratulations!
>
> It a property of the SKCP system that the person who performed the trusted
> setup cannot extract any information from a proof?
>
> In other words, is it proven hard to obtain information from a proof by
> the buyer?
>
> On Fri, Feb 26, 2016 at 6:42 PM, Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> I am happy to announce the first successful Zero-Knowledge Contingent
>> Payment (ZKCP) on the Bitcoin network.
>>
>> ZKCP is a transaction protocol that allows a buyer to purchase
>> information from a seller using Bitcoin in a manner which is private,
>> scalable, secure, and which doesn’t require trusting anyone: the
>> expected information is transferred if and only if the payment is
>> made. The buyer and seller do not need to trust each other or depend
>> on arbitration by a third party.
>>
>> Imagine a movie-style “briefcase swap” (one party with a briefcase
>> full of cash, another containing secret documents), but without the
>> potential scenario of one of the cases being filled with shredded
>> newspaper and the resulting exciting chase scene.
>>
>> An example application would be the owners of a particular make of
>> e-book reader cooperating to purchase the DRM master keys from a
>> failing manufacturer, so that they could load their own documents on
>> their readers after the vendor’s servers go offline. This type of sale
>> is inherently irreversible, potentially crosses multiple
>> jurisdictions, and involves parties whose financial stability is
>> uncertain–meaning that both parties either take a great deal of risk
>> or have to make difficult arrangement. Using a ZKCP avoids the
>> significant transactional costs involved in a sale which can otherwise
>> easily go wrong.
>>
>> In today’s transaction I purchased a solution to a 16x16 Sudoku puzzle
>> for 0.10 BTC from Sean Bowe, a member of the Zcash team, as part of a
>> demonstration performed live at Financial Cryptography 2016 in
>> Barbados. I played my part in the transaction remotely from
>> California.
>>
>> The transfer involved two transactions:
>>
>> 8e5df5f792ac4e98cca87f10aba7947337684a5a0a7333ab897fb9c9d616ba9e
>> 200554139d1e3fe6e499f6ffb0b6e01e706eb8c897293a7f6a26d25e39623fae
>>
>> Almost all of the engineering work behind this ZKCP implementation was
>> done by Sean Bowe, with support from Pieter Wuille, myself, and Madars
>> Virza.
>>
>>
>> Read more, including technical details at
>>
>> https://bitcoincore.org/en/2016/02/26/zero-knowledge-contingent-payments-announcement/
>>
>> [I hope to have a ZKCP sudoku buying faucet up shortly. :) ]
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
[-- Attachment #2: Type: text/html, Size: 5544 bytes --]
next prev parent reply other threads:[~2016-02-26 23:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 21:42 [bitcoin-dev] The first successful Zero-Knowledge Contingent Payment Gregory Maxwell
2016-02-26 23:06 ` Sergio Demian Lerner
[not found] ` <CAAS2fgT8RE7w87Yv9Be7arH-xGCtwcq0Ynbk21ZVpqJZrEN5EQ@mail.gmail.com>
2016-02-26 23:23 ` [bitcoin-dev] Fwd: " Gregory Maxwell
2016-02-26 23:33 ` Tier Nolan [this message]
2016-02-26 23:45 ` [bitcoin-dev] " Gregory Maxwell
2016-02-26 23:56 ` Tier Nolan
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='CAE-z3OVpd99Xyd9xenJir=7qfr4KOx=_hDpKtEKzAqtzteNMyQ@mail.gmail.com' \
--to=tier.nolan@gmail.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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