diff options
| author | ZmnSCPxj <ZmnSCPxj@protonmail.com> | 2018-03-12 02:46:39 -0400 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2018-03-12 06:46:50 +0000 |
| commit | 69c6cd7ca072d069230c2355ed2de4ec0a1566a0 (patch) | |
| tree | 9b3a66160b1788eca6f7a9d2f68afa1765ecd0b2 | |
| parent | 5989f3f93b34c126f4b92b8ebd2417ed3e93cd42 (diff) | |
| download | pi-bitcoindev-69c6cd7ca072d069230c2355ed2de4ec0a1566a0.tar.gz pi-bitcoindev-69c6cd7ca072d069230c2355ed2de4ec0a1566a0.zip | |
Re: [bitcoin-dev] Bulletproof CT as basis for election voting?
| -rw-r--r-- | 62/997f83c838aa7143a0d1b5127aaceb2bf72b70 | 113 |
1 files changed, 113 insertions, 0 deletions
diff --git a/62/997f83c838aa7143a0d1b5127aaceb2bf72b70 b/62/997f83c838aa7143a0d1b5127aaceb2bf72b70 new file mode 100644 index 000000000..3798ae227 --- /dev/null +++ b/62/997f83c838aa7143a0d1b5127aaceb2bf72b70 @@ -0,0 +1,113 @@ +Return-Path: <ZmnSCPxj@protonmail.com> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id 49061132D + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 12 Mar 2018 06:46:50 +0000 (UTC) +X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 +Received: from mail3.protonmail.ch (mail3.protonmail.ch [185.70.40.25]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 3FC412C3 + for <bitcoin-dev@lists.linuxfoundation.org>; + Mon, 12 Mar 2018 06:46:48 +0000 (UTC) +Date: Mon, 12 Mar 2018 02:46:39 -0400 +DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; + s=default; t=1520837206; + bh=SAbcvQFL+lgCd4i7nE7pfLbJ7uBmXIW3UQc7ZYZ5K7I=; + h=Date:To:From:Reply-To:Subject:In-Reply-To:References:Feedback-ID: + From; + b=aZFFeUbvDuEC3gF4ImjpM793hGOf+StqXb6dmmMRufmWPAsjR3TL0XLDsIu2Au3uy + nNIrTW0jj19/mpLg+uXrotsBJLONP7uyDEK8ux0DV6Azb4l99I1KfLWvN1bAzgnFoJ + wN9zk6JcAzCkpwzF8kkHUY+Epcd9EhHcLylKbgE0= +To: =?UTF-8?Q?JOSE_FEMENIAS_CA=C3=91UELO?= <jose.femenias@gmail.com>, + Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org> +From: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Reply-To: ZmnSCPxj <ZmnSCPxj@protonmail.com> +Message-ID: <K9SaeVjj0_bUr7O-78hlSUwsQqa0SYI-UUOj6L_hnDSF4zhk4dFLg4XWBOQ9xBHD2vu5H-y7nrjLjKlXue6Fi5sR5TGbGIY2f0KwnYINgBU=@protonmail.com> +In-Reply-To: <Us9RkES7hdpIyleB-Di6Cb3p-ydB293c8hKvumN3uJI9v_5b33YIMkSK6zGSgtWm4bclRklNeCAIcqBk-9MK7TFUjWbyZsNGgftfVW4KPHY=@protonmail.com> +References: <90096274-9576-4A08-A86A-E1C4F3E3B5DE@gmail.com> + <Us9RkES7hdpIyleB-Di6Cb3p-ydB293c8hKvumN3uJI9v_5b33YIMkSK6zGSgtWm4bclRklNeCAIcqBk-9MK7TFUjWbyZsNGgftfVW4KPHY=@protonmail.com> +Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: quoted-printable +X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, + DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, + RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 +X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on + smtp1.linux-foundation.org +X-Mailman-Approved-At: Mon, 12 Mar 2018 13:11:24 +0000 +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 <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: Mon, 12 Mar 2018 06:46:50 -0000 + +Good morning again Jose, + +Another idea is that with sufficiently high stakes (i.e. control of the gov= +ernment of an entire country) it would be possible for a miner-strong The P= +arty to censor transactions that do not give it non-zero amounts of coins. = + If The Party has a strong enough power over miners (or is composed of mine= +rs) then it would be possible for The Party to censor transactions using so= +me simple heuristics: (1) At least one output goes to The Party (2) the num= +ber of inputs equals the number of vote-coins that go to The Party output. = + Since The Party must know how many vote-coins it received, it can know #2,= + and it assumes that each input has 1 coin, since that is what is issued by= + the Voting Authority. This prevents mixing, too, since transactions that = +do not involve The Party cannot be confirmed. + +Presumably other parties may exist that have some miners, but if everyone s= +tarts censoring transactions then parties end up voting by their controlled= + hashpower rather than anything else (simply censor all transactions that f= +ail the above heuristics and build the longest chain: as long as you get ev= +en 1 vote and all others get 0 votes on the longest chain, you win. since p= +resumably you are also a valid voter, you can just give that single vote-co= +in issued to you-as-voter to you-as-party, then censor all other transactio= +ns in the blockchain so that other voters cannot give their coins to their = +preferred parties). One could try using proof-of-stake if one has managed = +to create a solution to nothing-at-stake and stake-grinding that itself doe= +s not require proof-of-work (hint, there are none). + +This can be mitigated by using a multi-asset international blockchain with = +confidential assets, such that no single The Party can control enough hashp= +ower to censor, but that makes small blocks even more important to help fig= +ht against centralization (and control of cheap energy becomes even more im= +portant such that some international entity may very well bend elections in= + individual countries to its favor to get more energy with which to control= + more energy, and so on). + +You can only trust the miners of the blockchain to the extent that you pay = +fees to those miners, effectively buying a portion of hashrate in a (mostly= +) fair auction. You can expect that miners will attempt to charge as much = +as they can for the hashrate, and therefore that vote transfers (if they ca= +n be detected by miners) are likely to be charged at whatever is the going = +rate for that vote. If what is being voted on is important enough, you can= + assure yourself, that miners will ally with politicians and use the fact t= +hat CT is confidential only between receiver and sender to discern preferre= +d vote transfers. + +Uncensorability may be possible though; I think Peter Todd was working on t= +hose. A simple one is a two-step commitment, where an earlier miner only k= +nows of a sealed commitment (a hash of a transaction), publishes it, then a= + future commitment shows the entire transaction and the earlier miner gets = +paid only if the second commitment pushes through (the fee gets split someh= +ow between the earlier and later miner). But once you reveal a transaction= + and it is not one of those desired by the later miner, if the vote is valu= +able enough then the miner might very well forgo its fee in favor of never = +confirming the second commitment. + +It may be better to focus more on libertarian solutions (e.g. assurance con= +tracts) on top of blockchains than attempting to shoehorn democractic ideal= +s on top of blockchains. + +Regards, +ZmnSCPxj + |