From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-2.v43.ch3.sourceforge.com ([172.29.43.192] helo=mx.sourceforge.net) by sfs-ml-4.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VR5MQ-0007RL-7j for bitcoin-development@lists.sourceforge.net; Tue, 01 Oct 2013 19:11:54 +0000 Received-SPF: pass (sog-mx-2.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.46 as permitted sender) client-ip=74.125.83.46; envelope-from=adam.back@gmail.com; helo=mail-ee0-f46.google.com; Received: from mail-ee0-f46.google.com ([74.125.83.46]) by sog-mx-2.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VR5MO-0005VB-2L for bitcoin-development@lists.sourceforge.net; Tue, 01 Oct 2013 19:11:54 +0000 Received: by mail-ee0-f46.google.com with SMTP id c13so3652342eek.33 for ; Tue, 01 Oct 2013 12:11:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=gEhIVy9w0Qsa6yHmhQOdSXBgkWGFLP8bUxJtqZPtPFk=; b=DftSQEW8AqRJSpcUocHcG8oCN4Cdqhb2zrhfxm4D5NvB4Izo7i4kz5Ws4Ut9BIoLfR z5dpeWGg40FI2sKk/pkVPKZ8ndw5vc9Tl3aYbr2lctYtbkU7WG9fAexFihOY3AOvbm7M 2ke0njSX9md9hqz8CR+EphojRsb61d2rTxSpuv04xXd8rt2jOWQpY0xWWiIvBd4StVxQ cu3FOzpr4Pdy2GybaTUi1QylYHp8oY2KTad0Ko/o/DFKoRW6B4Quz/JllU4t/qa7jRjz OtyG9sXqKTZ7wh2RWduNw9uQMeJBA34kZ4wx886hs5H3DN3waPJ1xnoGSC93hh/flk0+ 1OFQ== X-Received: by 10.14.177.199 with SMTP id d47mr47846447eem.14.1380654705694; Tue, 01 Oct 2013 12:11:45 -0700 (PDT) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id m54sm16479481eex.2.1969.12.31.16.00.00 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Tue, 01 Oct 2013 12:11:45 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id 8A8862E0B63; Tue, 1 Oct 2013 21:11:44 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Tue, 1 Oct 2013 21:11:43 +0200 Date: Tue, 1 Oct 2013 21:11:43 +0200 From: Adam Back To: Mark Friedenbach Message-ID: <20131001191143.GA16116@netbook.cypherspace.org> References: <2c70dbfc173749cf4198c591f19a7d33@astutium.com> <20130929093708.GA16561@netbook.cypherspace.org> <5248680C.60404@monetize.io> <20131001142603.GA9208@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20131001142603.GA9208@netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:131001:mark@monetize.io::ykSiHrXFHuytHKL6:01Rxm X-Hashcash: 1:20:131001:bitcoin-development@lists.sourceforge.net::vrjmBlYcVdp1O gyn:000000000000000000001wuU X-Hashcash: 1:20:131001:adam@cypherspace.org::BZ1SCJDOWLGT8Tla:00000000000000000 0000000000000000000000003nMj X-Spam-Score: -1.5 (-) X-Spam-Report: Spam Filtering performed by mx.sourceforge.net. See http://spamassassin.org/tag/ for more details. -1.5 SPF_CHECK_PASS SPF reports sender host as permitted sender for sender-domain 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (adam.back[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 URIBL_BLOCKED ADMINISTRATOR NOTICE: The query to URIBL was blocked. See http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more information. [URIs: bitcointalk.org] X-Headers-End: 1VR5MO-0005VB-2L Cc: Bitcoin Dev Subject: Re: [Bitcoin-development] homomorphic coin value (validatable but encrypted) (Re: smart contracts -- possible use case? yes or no?) X-BeenThere: bitcoin-development@lists.sourceforge.net X-Mailman-Version: 2.1.9 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Oct 2013 19:11:54 -0000 Err actually not (efficient) I made a mistake that came out when I started writing it up about how the t parameter in the proof relates to bitcoin precision and coin representation (I thought t=2, but t=51). Damn! Back to the not so efficient version (which is more zerocoin-esque in size/cost), or the more experimental Schoenmaker non-standard p, q non EC one, or other creative ideas to change the coin representation to simplify the proof (of which this was a failed attempt). See the bitcointalk thread for details. https://bitcointalk.org/index.php?topic=305791.new#new Adam On Tue, Oct 01, 2013 at 04:26:03PM +0200, Adam Back wrote: >On Sun, Sep 29, 2013 at 10:49:00AM -0700, Mark Friedenbach wrote: >>This kind of thing - providing external audits of customer accounts >>without revealing private data - would be generally useful beyond >>taxation. If you have any solutions, I'd be interested to hear them >>(although bitcoin-dev is probably not the right place yet). > >Thanks for providing the impetus to write down the current state, the >efficient version of which I only figured out a few days ago :) > >I have been researching this for a few months on and off, because it seems >like an interesting construct in its own right, a different aspect of >payment privacy (eg for auditable but commercial sensistive information) but >also that other than its direct use it may enable some features that we have >not thought of yet. > >I moved it to bitcointalk: > >https://bitcointalk.org/index.php?topic=305791.new#new > >Its efficient finally (after many dead ends): approximately 2x cost of >current in terms of coin size and coin verification cost, however it also >gives some perf advantages back in a different way - necessary changes to >schnorr (EC version of Schnorr based proofs) allow n of n multiparty sigs, >or k of n multiparty sigs for the verification cost and signature size of >one pair of ECS signatures, for n > 2 its a space and efficiency improvement >over current bitcoin. > >Adam