From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <pete@petertodd.org> Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id D8007412 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 14 Nov 2017 10:07:34 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from outmail149043.authsmtp.co.uk (outmail149043.authsmtp.co.uk [62.13.149.43]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 11B72134 for <bitcoin-dev@lists.linuxfoundation.org>; Tue, 14 Nov 2017 10:07:33 +0000 (UTC) Received: from mail-c245.authsmtp.com (mail-c245.authsmtp.com [62.13.128.245]) by punt24.authsmtp.com. (8.15.2/8.15.2) with ESMTP id vAEA7WAZ037070; Tue, 14 Nov 2017 10:07:32 GMT (envelope-from pete@petertodd.org) Received: from petertodd.org (ec2-52-5-185-120.compute-1.amazonaws.com [52.5.185.120]) (authenticated bits=0) by mail.authsmtp.com (8.15.2/8.15.2) with ESMTPSA id vAEA7U23064429 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 14 Nov 2017 10:07:31 GMT (envelope-from pete@petertodd.org) Received: from [127.0.0.1] (localhost [127.0.0.1]) by petertodd.org (Postfix) with ESMTPSA id ACDFB400F9; Tue, 14 Nov 2017 10:07:29 +0000 (UTC) Received: by localhost (Postfix, from userid 1000) id 67B6523D13; Tue, 14 Nov 2017 05:07:28 -0500 (EST) Date: Tue, 14 Nov 2017 05:07:28 -0500 From: Peter Todd <pete@petertodd.org> To: Gregory Maxwell <greg@xiph.org>, Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> Message-ID: <20171114100728.GA29749@savin.petertodd.org> References: <CAAS2fgQ0Cb2B=Ye2TnpfQqP4=kpZCxMWRXYB0CcFa71sQJaGuw@mail.gmail.com> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="BOKacYhQ+x31HxR3" Content-Disposition: inline In-Reply-To: <CAAS2fgQ0Cb2B=Ye2TnpfQqP4=kpZCxMWRXYB0CcFa71sQJaGuw@mail.gmail.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Server-Quench: a0baaa56-c923-11e7-a554-9cb654bb2504 X-AuthReport-Spam: If SPAM / abuse - report it at: http://www.authsmtp.com/abuse X-AuthRoute: OCd2Yg0TA1ZNQRgX IjsJECJaVQIpKltL GxAVKBZePFsRUQkR aAdMdwYUFloCAgsB AmEbWlReUFp7WmI7 bghPaBtcak9QXgdq T0pMXVMcUnQdcBtk BB0eVB12dQwIfn13 YQgzXiIKDRV/c1su S0xXCGwHMGB9OWUa VF1RJFFSdQcYLB1A alQxNiYHcQ5VPz4z GA41ejw8IwAXFTxZ Sx0ANhoVRw4gGTgy RhwPGykuFElNez86 KQcvIUIdG0AKekg8 P1oqWF8eOA56 X-Authentic-SMTP: 61633532353630.1039:706 X-AuthFastPath: 0 (Was 255) X-AuthSMTP-Origin: 52.5.185.120/25 X-AuthVirus-Status: No virus detected - but ensure you scan with your own anti-virus system. X-Spam-Status: No, score=-0.7 required=5.0 tests=RCVD_IN_DNSWL_LOW autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Updates on Confidential Transactions efficiency X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org> List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> X-List-Received-Date: Tue, 14 Nov 2017 10:07:35 -0000 --BOKacYhQ+x31HxR3 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Nov 14, 2017 at 01:21:14AM +0000, Gregory Maxwell via bitcoin-dev w= rote: > The primary advantage of this approach is that it can be constructed > without any substantial new cryptographic assumptions (e.g., only > discrete log security in our existing curve), that it can be high > performance compared to alternatives, that it has no trusted setup, > and that it doesn't involve the creation of any forever-growing > unprunable accumulators. All major alternative schemes fail multiple > of these criteria (e.g., arguably Zcash's scheme fails every one of > them). Re: the unprunable accumulators, that doesn't need to be an inherent proper= ty of Zcash/Monero style systems. It'd be quite feasible to use accumulator epochs and either make unspent co= ins in a previous epoch unspendable after some expiry time is reached - allowing the spent coin accumulator data to be discarded - or make use of a merkeliz= ed key-value scheme with transaction provided proofs to shift the costs of maintaining the accumulator to wallets. The disadvantage of epoch schemes is of course a reduced k-anonymity set, b= ut if I understand the Confidential Transactions proposals correctly, they alr= eady have a significantly reduced k-anonymity set per transaction than Zcash theoretically could (modulo it's in practice low anonymity set due to lack = of actual usage). In that respect, epoch size is simply a tradeoff between sta= te size and k-anonymity set size. --=20 https://petertodd.org 'peter'[:-1]@petertodd.org --BOKacYhQ+x31HxR3 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature -----BEGIN PGP SIGNATURE----- iQEcBAEBCAAGBQJaCsBbAAoJECSBQD2l8JH7Fw0H/1z8v5SuFAjaVsCaBId6n26G bFtLPv2loZnasgRHZUdGbyvD14Z7WXr3Mufjw3xwx7Tpv0xMgB+6wmz6ZtzZBz7L 1HZUa2yQCfyiH9EOuGy1xcr4l8/p7a5xQ4AYlA3iOPD5zGCgNJ7wt4cdkV8o5ZF1 2Q05jQaIJWETCoIbZ5xOygta9WRueUG5sdklhef02lx2kmtWUiRz+dbTHuBGrLpo PZuO7AmORZZDVd/DWotEe7OaycKiHGKBDRRBd+WhvTr30XULiU2iklS7yfyzxsN0 kmqQymnNCxBhAruApHcva9Cmn++HYNJdz/pPgxqK4rQWMb0rrCH3wDBSENchaC0= =B/VI -----END PGP SIGNATURE----- --BOKacYhQ+x31HxR3--