public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed

* [bitcoin-dev] Bulletproof CT as basis for election voting?
@ 2018-03-11 12:44 JOSE FEMENIAS CAÑUELO
  2018-03-12  4:14 ` ZmnSCPxj
  2018-03-12  9:32 ` Tim Ruffing
  0 siblings, 2 replies; 4+ messages in thread
From: JOSE FEMENIAS CAÑUELO @ 2018-03-11 12:44 UTC (permalink / raw)
  To: bitcoin-dev

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?

^ permalink raw reply	[flat|nested] 4+ messages in thread

• * Re: [bitcoin-dev] Bulletproof CT as basis for election voting?
    2018-03-11 12:44 [bitcoin-dev] Bulletproof CT as basis for election voting? JOSE FEMENIAS CAÑUELO
  @ 2018-03-12  4:14 ` ZmnSCPxj
    2018-03-12  6:46   ` ZmnSCPxj
    2018-03-12  9:32 ` Tim Ruffing
    1 sibling, 1 reply; 4+ messages in thread
  From: ZmnSCPxj @ 2018-03-12  4:14 UTC (permalink / raw)
    To: JOSE FEMENIAS CAÑUELO, Bitcoin Protocol Discussion
  
  Good morning Jose,
  
  By my understanding, the sender needs to reveal some secrets to the receiver, and the receiver will then know if it received 0 or 1 coin from that sender.  (At least from my understanding of MimbleWimble; it might not be the case for CT, but MW is an extension of CT so...)
  
  If voters send vote-coins directly to The Party, then The Party knows the votes of particular voters, and may then dispatch subcontractors to dispatch those voters.  It may be possible to have aggregators/mixers, but then you would have to trust the aggregators/mixers operate correctly and send to the correct destination party, and that the mixers are not recording voters.
  
  Maybe in combination with something like CoinSwap or CoinJoin protocol would work to obscure the source of coins: a voter would have to swap several times with many, many other voters to ensure increased anonymity set (and then maybe some voters may report their transactions to The Party).
  
  In any case sending directly from the tx of the Voting Authority to another tx to your selected The Party would let The Party members who secretly control the Voting Authority records to figure out, which voters got which txouts of the Voting Authority (presumably the Voting Authority has strict public records of which txout went to which voter, in order to prevent the Voting Authority secretly giving multiple vote-coins to a single One Man, All Votes).
  
  Regards,
  ZmnSCPxj
  
  
  ​Sent with ProtonMail Secure Email.​
  
  ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐
  
  On March 11, 2018 8:44 PM, JOSE FEMENIAS CAÑUELO via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org> 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
  
  
  
  
  ^ permalink raw reply	[flat|nested] 4+ messages in thread

• • * Re: [bitcoin-dev] Bulletproof CT as basis for election voting?
      2018-03-12  4:14 ` ZmnSCPxj
    @ 2018-03-12  6:46   ` ZmnSCPxj
      0 siblings, 0 replies; 4+ messages in thread
    From: ZmnSCPxj @ 2018-03-12  6:46 UTC (permalink / raw)
      To: JOSE FEMENIAS CAÑUELO, Bitcoin Protocol Discussion
    
    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
    
    
    ^ permalink raw reply	[flat|nested] 4+ messages in thread

• * Re: [bitcoin-dev] Bulletproof CT as basis for election voting?
    2018-03-11 12:44 [bitcoin-dev] Bulletproof CT as basis for election voting? JOSE FEMENIAS CAÑUELO
    2018-03-12  4:14 ` ZmnSCPxj
  @ 2018-03-12  9:32 ` Tim Ruffing
    1 sibling, 0 replies; 4+ messages in thread
  From: Tim Ruffing @ 2018-03-12  9:32 UTC (permalink / raw)
    To: bitcoin-dev
  
  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
  
  
  ^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2018-03-12  9:33 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2018-03-11 12:44 [bitcoin-dev] Bulletproof CT as basis for election voting? JOSE FEMENIAS CAÑUELO
2018-03-12  4:14 ` ZmnSCPxj
2018-03-12  6:46   ` ZmnSCPxj
2018-03-12  9:32 ` Tim Ruffing

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox