From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from sog-mx-3.v43.ch3.sourceforge.com ([172.29.43.193] helo=mx.sourceforge.net) by sfs-ml-2.v29.ch3.sourceforge.com with esmtp (Exim 4.76) (envelope-from ) id 1VTG3T-0001EY-Di for bitcoin-development@lists.sourceforge.net; Mon, 07 Oct 2013 19:01:19 +0000 Received-SPF: pass (sog-mx-3.v43.ch3.sourceforge.com: domain of gmail.com designates 74.125.83.42 as permitted sender) client-ip=74.125.83.42; envelope-from=adam.back@gmail.com; helo=mail-ee0-f42.google.com; Received: from mail-ee0-f42.google.com ([74.125.83.42]) by sog-mx-3.v43.ch3.sourceforge.com with esmtps (TLSv1:RC4-SHA:128) (Exim 4.76) id 1VTG3O-0000Z9-HH for bitcoin-development@lists.sourceforge.net; Mon, 07 Oct 2013 19:01:19 +0000 Received: by mail-ee0-f42.google.com with SMTP id b45so3535046eek.1 for ; Mon, 07 Oct 2013 12:01:08 -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=YgjAImPr1Snht60RBi+PikqEc5RboRkegRfHXAqSqn4=; b=mfaskqxDBMa0t2vxLWwE/AQP6rp1ATI2vRMbr0zWovPsc/xqzIFDQK8CfMmIpUbWol Y4+l6rgSXy5bk6yqww1Fj77jjmt/rZXTS6QjuZdiZUhfF0sr6z2Hh+iyJER6BbaNJFy9 7X9AVb/pMCIsiEbvUidcGgkVxpoD1xPbRotJAEVMGOEQvcgFUytPmCZjyr0OjrOscNXu PstOjOC0Aexeo7XIw5Qarau7C8CDndodqv8WBiVlSN4rees8lQyLYWxT/Gx/F8bYm5Wg 2dpmI2VVLwP/Lw8fTmqr4ghtUS6Souaj4JdUoINjIwr/w1c+SV59+5U1oMqU7B6DUWJh FNDA== X-Received: by 10.14.122.132 with SMTP id t4mr51803905eeh.20.1381172467986; Mon, 07 Oct 2013 12:01:07 -0700 (PDT) Received: from netbook (c83-90.i07-21.onvol.net. [92.251.83.90]) by mx.google.com with ESMTPSA id m54sm66547420eex.2.1969.12.31.16.00.00 (version=TLSv1.1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Mon, 07 Oct 2013 12:01:07 -0700 (PDT) Received: by netbook (Postfix, from userid 1000) id 259572E0AA7; Mon, 7 Oct 2013 21:01:06 +0200 (CEST) Received: by flare (hashcash-sendmail, from uid 1000); Mon, 7 Oct 2013 21:01:03 +0200 Date: Mon, 7 Oct 2013 21:01:03 +0200 From: Adam Back To: Mark Friedenbach Message-ID: <20131007190103.GA6811@netbook.cypherspace.org> References: <2c70dbfc173749cf4198c591f19a7d33@astutium.com> <20130929093708.GA16561@netbook.cypherspace.org> <5248680C.60404@monetize.io> <20131001142603.GA9208@netbook.cypherspace.org> <20131001191143.GA16116@netbook.cypherspace.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20131001191143.GA16116@netbook.cypherspace.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Hashcash: 1:20:131007:mark@monetize.io::iQVnqxd1ZuDqYDAx:03AqJ X-Hashcash: 1:20:131007:bitcoin-development@lists.sourceforge.net::MrUrvOwS8IBQm 3vw:0000000000000000000099Ol X-Hashcash: 1:20:131007:adam@cypherspace.org::/J2F0sHXI6xjtpb7:00000000000000000 0000000000000000000000006JLc 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: 1VTG3O-0000Z9-HH 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: Mon, 07 Oct 2013 19:01:19 -0000 An update on the homomorphic coins, some more math validation & a test implementation needs to be done, but a surprisingly good outcome so far of predicted 2.5kB homomorphic valued coin. Only coin splitting has to incur the 2.5kB range proof. Coin adding, full spending and mining is "free", because adding existing range proofed and validated coins cant overflow by definition (21 mil coin cap). You can also (obviously I guess) add a homomorphicaly encrypted "0" value to a few other peoples coin balance to get a kind of taint mitigation. https://bitcointalk.org/index.php?topic=305791.msg3294618#msg3294618 Adam On Tue, Oct 01, 2013 at 09:11:43PM +0200, Adam Back wrote: >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