Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5BFCDC80 for ; Fri, 26 Feb 2016 23:33:52 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f172.google.com (mail-io0-f172.google.com [209.85.223.172]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9855712A for ; Fri, 26 Feb 2016 23:33:51 +0000 (UTC) Received: by mail-io0-f172.google.com with SMTP id g203so137647543iof.2 for ; Fri, 26 Feb 2016 15:33:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:cc; bh=iFmLe3wfdPw/s973IKm/Nvqnxvf3iNSNX13lGIfF/dg=; b=kcOlCDLwyNonkzs8Xqhqpoi1JCXx3auRm6mxVDlDyKy7BCbDX1Qf+0NhHeqt5o+/BJ uYP1K2FS8hLko5jIbqTc9Wxnj5qv2xRGlqwxTaTwzUQV2RSjWMcsIH9BcGDH2nQGi5sI 5bz+Bc0F/J0AEvRvapQf2B6IYYIHuSUu8Hdds/ivgT8IzwWQUTQqHGngY3GWBFkXiY84 dVcFU43dcvo71qqLZWzv8alP86zXPBUUUa2zODbOxWJEFVQBxe1GkSXsJxedKe8J3oo1 5+O5abBuK1soUqcm9s3qpoER4go1DV/HmJlaaREs/ou12HGawzZxncQ/1stysKSJfOhW Jj5w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:cc; bh=iFmLe3wfdPw/s973IKm/Nvqnxvf3iNSNX13lGIfF/dg=; b=FqkWFAEOZ8nBIhgLCrWw4oRCInQ/xY4mTpwXDRHbPubQD1gx0F1oaXj4NPZhzJWcYP cOopXISvlNoRnhZGHZu/jTiyyscOhzWqbRHKMv2otjX5iSN0659K9we3FzMgoVNuvvCe qoYTOYKqjRERUkmwsfvPK7Wb3bdlGY/GTA0daDnna5GU9ftip4wb2Ae8/Z4sPFQkMPD5 itjh9f4Ufsls+PdgQXgs/6N8U/joh9/hQSFZrdmlbCUVMSdGVzRwR3AiuEsXiE5k+pEc oge7zIy10U1TFK8PsSRMmyHW7pz5Cmdm1pkQ0MLO+wVkTAja/mejA/5S+KblPMv/ypnB zMTw== X-Gm-Message-State: AG10YORtii+kk65wiEl/8r5nf8YoaCeoQ4jPJmqNX4x7uAEHEOoIt/XKKXmsuQqjQ03y4JJzZJswPm/xrdamRA== MIME-Version: 1.0 X-Received: by 10.107.170.79 with SMTP id t76mr12917785ioe.71.1456529631092; Fri, 26 Feb 2016 15:33:51 -0800 (PST) Received: by 10.79.128.149 with HTTP; Fri, 26 Feb 2016 15:33:51 -0800 (PST) In-Reply-To: References: Date: Fri, 26 Feb 2016 23:33:51 +0000 Message-ID: From: Tier Nolan Cc: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a114157c6443213052cb4bb14 X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,MISSING_HEADERS, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] The first successful Zero-Knowledge Contingent Payment X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 26 Feb 2016 23:33:52 -0000 --001a114157c6443213052cb4bb14 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 =3D hash(x) =3D 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 truste= d > 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=E2=80=99t 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 =E2=80=9Cbriefcase swap=E2=80=9D (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=E2=80=99s servers go offline. This type o= f sale >> is inherently irreversible, potentially crosses multiple >> jurisdictions, and involves parties whose financial stability is >> uncertain=E2=80=93meaning 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=E2=80=99s 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 > > --001a114157c6443213052cb4bb14 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
That is very interesting.

There has= been some recent discussion about atomic cross chain transfers between Bit= coin and legacy altcoins.=C2=A0 For this purpose a legacy altcoin is one th= at 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].=C2=A0 Bob has to prove that the hash is a= ctually the result of hashing the private key that matches bob_public_key.<= br>
This can be achieved with a cut-and-choose scheme.=C2=A0 = It uses a fee so that an attacker loses money on average.=C2=A0 It is vulne= rable to an attacker who doesn't mind losing money as long as the targe= t loses money too.

Bob would have to prove that he has an= x such that

xG =3D <bob_public_key>
= hash(x) =3D hash_of_bob_private_key

Is the scheme fast en= ough such that an elliptic curve multiply would be feasible?=C2=A0 You ment= ion 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 <= span dir=3D"ltr"><bitcoin-dev@lists.linuxfoundation.org> w= rote:
Con= gratulations!

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 informati= on 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-Knowled= ge 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=E2=80=99t 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 =E2=80=9Cbriefcase swap=E2=80=9D (one party with a br= iefcase
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=E2=80=99s servers go offline. This type of s= ale
is inherently irreversible, potentially crosses multiple
jurisdictions, and involves parties whose financial stability is
uncertain=E2=80=93meaning that both parties either take a great deal of ris= k
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=E2=80=99s transaction I purchased a solution to a 16x16 Sudoku puz= zle
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://bitcoi= ncore.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/mail= man/listinfo/bitcoin-dev


_______________________________________________
bitcoin-dev mailing list
bitcoin-dev@lists.= linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a114157c6443213052cb4bb14--