From: ZmnSCPxj <ZmnSCPxj@protonmail•com>
To: "JOSE FEMENIAS CAÑUELO" <jose.femenias@gmail•com>,
"Bitcoin Protocol Discussion"
<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Bulletproof CT as basis for election voting?
Date: Mon, 12 Mar 2018 02:46:39 -0400 [thread overview]
Message-ID: <K9SaeVjj0_bUr7O-78hlSUwsQqa0SYI-UUOj6L_hnDSF4zhk4dFLg4XWBOQ9xBHD2vu5H-y7nrjLjKlXue6Fi5sR5TGbGIY2f0KwnYINgBU=@protonmail.com> (raw)
In-Reply-To: <Us9RkES7hdpIyleB-Di6Cb3p-ydB293c8hKvumN3uJI9v_5b33YIMkSK6zGSgtWm4bclRklNeCAIcqBk-9MK7TFUjWbyZsNGgftfVW4KPHY=@protonmail.com>
Good morning again Jose,
Another idea is that with sufficiently high stakes (i.e. control of the government of an entire country) it would be possible for a miner-strong The Party 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 miners) then it would be possible for The Party to censor transactions using some simple heuristics: (1) At least one output goes to The Party (2) the number 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 starts censoring transactions then parties end up voting by their controlled hashpower rather than anything else (simply censor all transactions that fail the above heuristics and build the longest chain: as long as you get even 1 vote and all others get 0 votes on the longest chain, you win. since presumably you are also a valid voter, you can just give that single vote-coin issued to you-as-voter to you-as-party, then censor all other transactions 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 does 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 hashpower to censor, but that makes small blocks even more important to help fight against centralization (and control of cheap energy becomes even more important 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 can 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 that CT is confidential only between receiver and sender to discern preferred vote transfers.
Uncensorability may be possible though; I think Peter Todd was working on those. A simple one is a two-step commitment, where an earlier miner only knows 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 somehow 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 valuable 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 contracts) on top of blockchains than attempting to shoehorn democractic ideals on top of blockchains.
Regards,
ZmnSCPxj
next prev parent reply other threads:[~2018-03-12 6:46 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-11 12:44 JOSE FEMENIAS CAÑUELO
2018-03-12 4:14 ` ZmnSCPxj
2018-03-12 6:46 ` ZmnSCPxj [this message]
2018-03-12 9:32 ` Tim Ruffing
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='K9SaeVjj0_bUr7O-78hlSUwsQqa0SYI-UUOj6L_hnDSF4zhk4dFLg4XWBOQ9xBHD2vu5H-y7nrjLjKlXue6Fi5sR5TGbGIY2f0KwnYINgBU=@protonmail.com' \
--to=zmnscpxj@protonmail$(echo .)com \
--cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
--cc=jose.femenias@gmail$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox