From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id AB3671132 for ; Mon, 12 Mar 2018 09:33:17 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from juno.mpi-klsb.mpg.de (juno.mpi-klsb.mpg.de [139.19.86.40]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D0D0A5C2 for ; Mon, 12 Mar 2018 09:33:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=mmci.uni-saarland.de; s=mail200803; h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID; bh=jzPVqhfbxqR3Nni1A836EmOXow5wTBS4XSxfNBALT/I=; b=xvHp/DIsOeLU0f+xiRI0z3d7SwPoQqY62FTjV9Rx1ncjgrbCsoxE7GHNtwnfdMd4rEpz4vkRH8ctcTIzepUBqFQUMrH1rOBZfSzSBLM5Uu984ylF5QDElU2+HYACngJK4xE2YuzaqrrfoQpEMR4+ye/phfVe+4ULPfADNm6O/go=; Received: from srv-00-61.mpi-klsb.mpg.de ([139.19.86.26]:42184 helo=sam.mpi-klsb.mpg.de) by juno.mpi-klsb.mpg.de (envelope-from ) with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) id 1evJpQ-0004PH-Cx for bitcoin-dev@lists.linuxfoundation.org; Mon, 12 Mar 2018 10:33:14 +0100 Received: from [46.183.103.17] (port=13160 helo=tonno) by sam.mpi-klsb.mpg.de (envelope-from ) with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.84_2) id 1evJpO-0006dm-F7 for bitcoin-dev@lists.linuxfoundation.org; Mon, 12 Mar 2018 10:33:12 +0100 Message-ID: <1520847175.2339.14.camel@mmci.uni-saarland.de> From: Tim Ruffing To: bitcoin-dev@lists.linuxfoundation.org Date: Mon, 12 Mar 2018 10:32:55 +0100 In-Reply-To: <90096274-9576-4A08-A86A-E1C4F3E3B5DE@gmail.com> References: <90096274-9576-4A08-A86A-E1C4F3E3B5DE@gmail.com> Content-Type: text/plain; charset="UTF-8" X-Mailer: Evolution 3.26.5 Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-MPI-Local-Sender: true X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Bulletproof CT as basis for election voting? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Mar 2018 09:33:17 -0000 You're right that this is a simple electronic voting scheme. The thing is that cryptographers are working on e-voting for decades and the idea to use homomorphic commitments (or encryption) and zero-knowledge proofs is not new in this area. It's rather the case that e-voting inspired a lot of work on homomorphic crypto and related zero-knowledge proofs. For example, range proofs are overkill in e-voting. You just need to ensure that the sum of all my votes (over all candidates) is 1. E-voting protocols typically require some "bulletin board", where ballots are stored. A blockchain could indeed be helpful in specific cases (but not in all cases)... If you're interested in that stuff, I'd suggest you to read some literature about e-voting. (For example, https://arxiv.org/pdf/1801.08064 looks interesting for the connection to blockchains -- I haven't read it though). There are pretty sophisticated protocols in the literature. And I think that this mailing list may not be the best place to discuss these. Best, Tim On Sun, 2018-03-11 at 13:44 +0100, JOSE FEMENIAS CAÑUELO via bitcoin- dev wrote: > If I understand Bulletproof Confidential Transactions properly, their > main virtue is being able to hide not the senders/receivers of a coin > but the amount transferred. > That sounds to me like a perfect use case for an election. > For instance, in my country, every citizen is issued a National ID > Card with a digital certificate. > So, a naive implementation could simply be that the Voting Authority, > sends a coin (1 coin = 1 vote) to each citizen above 18. This would > be an open transaction, so it is easily auditable. > Later on, each voter sends her coin to her preferred party, as part > of a Bulletproof CT, along with 0 coins to other parties to disguise > her vote. > In the end, each party will accrue as may votes as coins received. > > Is there any gotcha I’m missing here? Are there any missing features > required in Bulletproof to support this use case? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev