'Vote with your bitcoins' voting system

[RealBitcoin]

I was commenting on the pdf.
I understand your proposal.But tying the BTC in your account for the duration of the voting process may not be well recieved.

Well unfortunately thats the only way to make sure no double-voting the same coins happen.

Is it possible to invalidate my vote and make outgoing transactions in case of an emergency?

Yes.

[1715169177]

1715169177

[1715169177]

1715169177

[1715169177]

1715169177

[1715169177]

1715169177

[1715169177]

1715169177

[RealBitcoin]

I would like to review this thought, and maybe somebody can pick it up as a formal project.

It could have big success if done correctly, and it can be beneficial for the community so that we can finally have a transparent formal discussion about bitcoin and it's future.

[Willemveen]

Seems good!

[Monnt]

This would make bitcoin a pump and dump. You see, this gives rich people an incentive to hoard bitcoin. Theyll buy up as much bitcoin as possible to get a huge amount of voting power, make an unstable change, then sell everything. *Shudders*

I was commenting on the pdf.
I understand your proposal.But tying the BTC in your account for the duration of the voting process may not be well recieved.

Well unfortunately thats the only way to make sure no double-voting the same coins happen.
emergency?

Yes.
[/quote]


What about a period of 7 days to set your vote, and on a certain block, everyone gets their vote counted. Or maybe votes are only valid if the coins have stayed in their wallet for more than X days

[RealBitcoin]

This would make bitcoin a pump and dump. You see, this gives rich people an incentive to hoard bitcoin. Theyll buy up as much bitcoin as possible to get a huge amount of voting power, make an unstable change, then sell everything. *Shudders*

Thats not how it works, change cant be made that easily.

Besides why would they destroy bitcoin when they can make huge profits on it during the course of their entire lifetime.

Even the most greedy person can see that bitcoin is a long term money tree, that you dont want to cut out.

What about a period of 7 days to set your vote, and on a certain block, everyone gets their vote counted. Or maybe votes are only valid if the coins have stayed in their wallet for more than X days

Sure, the details can be debated, but i just put forward the idea.

Yes the votes are only valid if you didnt made output transactions in the meantime, since otherwise you can just vote infinite amounts with the same coin.

[funkenstein]

I was commenting on the pdf.
I understand your proposal.But tying the BTC in your account for the duration of the voting process may not be well recieved.

Well unfortunately thats the only way to make sure no double-voting the same coins happen.

Nope!  Actually it is easy to confirm that no incoming vote signature corresponds to an output of existing coin-vote signatures.  The concept is sometimes referred to as "taint"..  any vote which is a signature corresponding to coin tainted by earlier coin-vote signatures is thrown out.  

There is no need to send coin or hold coin when voting.  Simply sign a statement with a key that holds coin (which isn't been linked to previous votes). 

Is it possible to invalidate my vote and make outgoing transactions in case of an emergency?

Yes.

No a proper coin-vote does not enable any cancelling of votes.  This is because you can't "unsign" a document.  Once you publish a signature, it remains published.  In theory you could publish another signature voting the other way but that would be rejected as a double-vote.

http://frass.woodcoin.org/introducing-coin-vote/

[RealBitcoin]

Nope!  Actually it is easy to confirm that no incoming vote signature corresponds to an output of existing coin-vote signatures.  The concept is sometimes referred to as "taint"..  any vote which is a signature corresponding to coin tainted by earlier coin-vote signatures is thrown out.  

There is no need to send coin or hold coin when voting.  Simply sign a statement with a key that holds coin (which isn't been linked to previous votes). 

Yea and you want to analyze all addresses and all addresses corespondingto all addresses.

That is just way too hard and requires supercomputers, my proposition is easy to implement, and it only requires people to give up using their coins for say 1 week.

If they really want to vote, such small sacrifice is not a big deal.

[funkenstein]

Nope!  Actually it is easy to confirm that no incoming vote signature corresponds to an output of existing coin-vote signatures.  The concept is sometimes referred to as "taint"..  any vote which is a signature corresponding to coin tainted by earlier coin-vote signatures is thrown out.  

There is no need to send coin or hold coin when voting.  Simply sign a statement with a key that holds coin (which isn't been linked to previous votes). 

Yea and you want to analyze all addresses and all addresses corespondingto all addresses.

That is just way too hard and requires supercomputers, my proposition is easy to implement, and it only requires people to give up using their coins for say 1 week.

If they really want to vote, such small sacrifice is not a big deal.

 

Not at all.  The time is of order N*(db query time) where N is the number of votes cast so far.  For every incoming vote, you simply check the address for taint from every existing vote.  This is not an "analysis" it is a straightforward database query and is nearly instant. 

For an example of a taint query on the blockchain see https://blockchain.info/taint/1dice6GV5Rz2iaifPvX7RMjfhaNPC8SXH

This is spelled out in my paper.  Did you read it? 

Our solution allows the user to spend the coin immediately, i.e. voting carries NO COST apart from the work of signing the statement and submitting it.  Don't you think that is better? 

[RealBitcoin]

Not at all.  The time is of order N*(db query time) where N is the number of votes cast so far.  For every incoming vote, you simply check the address for taint from every existing vote.  This is not an "analysis" it is a straightforward database query and is nearly instant. 

For an example of a taint query on the blockchain see https://blockchain.info/taint/1dice6GV5Rz2iaifPvX7RMjfhaNPC8SXH

This is spelled out in my paper.  Did you read it? 

Our solution allows the user to spend the coin immediately, i.e. voting carries NO COST apart from the work of signing the statement and submitting it.  Don't you think that is better? 

What if the two addresses had contact before, can the taint analysis have a timeframe?

Also you have to test each voter against  the entire voting pool, and to conserve resources, let's just assume that the testing only happens after the voting ended.

So you have to test each address against all other, and if they had any taint in that specific timeperiod, then remove both of them from the eligible voters . When it's filtered out, then the remaining votes can be counted.

[funkenstein]

Not at all.  The time is of order N*(db query time) where N is the number of votes cast so far.  For every incoming vote, you simply check the address for taint from every existing vote.  This is not an "analysis" it is a straightforward database query and is nearly instant.  

For an example of a taint query on the blockchain see https://blockchain.info/taint/1dice6GV5Rz2iaifPvX7RMjfhaNPC8SXH

This is spelled out in my paper.  Did you read it?  

Our solution allows the user to spend the coin immediately, i.e. voting carries NO COST apart from the work of signing the statement and submitting it.  Don't you think that is better?  

What if the two addresses had contact before, can the taint analysis have a timeframe?,

Yes. Specifically, voting is done not with an address but with an unspent output (but you can also choose to vote with every unspent output associated with an address).  When a new voting signature is submitted, we must go through every current vote and check the output tree from each to make sure the new vote is not on that output tree.  Typically the output tree is of length zero.  If somebody votes and then immediate sends this coin to a mixer, it would be longer.  However the query is still fast and unbreakable.     

Also you have to test each voter against  the entire voting pool, and to conserve resources, let's just assume that the testing only happens after the voting ended.

So you have to test each address against all other, and if they had any taint in that specific timeperiod, then remove both of them from the eligible voters . When it's filtered out, then the remaining votes can be counted.

Why would we do that?  Each vote is tested when it arrives, and before being added to the current running tally displayed.  It's important that everything is transparent and can be checked by anyone by looking at the record.  

Thanks for your replies and interest in verifiably fair votes using bitcoin!    

[RealBitcoin]

Yes. Specifically, voting is done not with an address but with an unspent output (but you can also choose to vote with every unspent output associated with an address).  When a new voting signature is submitted, we must go through every current vote and check the output tree from each to make sure the new vote is not on that output tree.  Typically the output tree is of length zero.  If somebody votes and then immediate sends this coin to a mixer, it would be longer.  However the query is still fast and unbreakable.     

Hold on a second I`m not sure we are on the same page. It's not the person that votes, but the coin. So it doesnt matter who owns which coin.

If you have 100 addresses, each having 1 btc, you can vote 100 times, but only 1 time with each address.

So 1 coin can only be counted once.

Now I`m not sure how you do that because if you allow a person to still send out money from that address, it will be difficult, because then he will just swap the coins with somebody else that didnt voted.

So you have address A with 2 bitcoin, you vote with 1 bitcoin, and keep 1 bitcoin. Then you swap the 1 bitcoin that voted with a  stranger, offchain, and vote again. Then swap again ,and vote again...

That would be silly.


So it's not the person that votes, not even the coin, but rather the address (and it's full balance) is voting. Also you still have to forbit outgoing TX from that address until the voting is over.


If you have 100 bitcoin but only you want to vote with 50, and use the other 50 for your personal spending, then you just send the voting 50 to another address and wont be moved until voting is over.

[etparle]

Don't a lot of alt coins implement a voting system, can't something like that be used for voting with Bitcoin?

[funkenstein]

Yes. Specifically, voting is done not with an address but with an unspent output (but you can also choose to vote with every unspent output associated with an address).  When a new voting signature is submitted, we must go through every current vote and check the output tree from each to make sure the new vote is not on that output tree.  Typically the output tree is of length zero.  If somebody votes and then immediate sends this coin to a mixer, it would be longer.  However the query is still fast and unbreakable.     

Hold on a second I`m not sure we are on the same page. It's not the person that votes, but the coin. So it doesnt matter who owns which coin.

If you have 100 addresses, each having 1 btc, you can vote 100 times, but only 1 time with each address.

So 1 coin can only be counted once.

Now I`m not sure how you do that because if you allow a person to still send out money from that address, it will be difficult, because then he will just swap the coins with somebody else that didnt voted.

So you have address A with 2 bitcoin, you vote with 1 bitcoin, and keep 1 bitcoin. Then you swap the 1 bitcoin that voted with a  stranger, offchain, and vote again. Then swap again ,and vote again...

That would be silly.


So it's not the person that votes, not even the coin, but rather the address (and it's full balance) is voting. Also you still have to forbit outgoing TX from that address until the voting is over.


If you have 100 bitcoin but only you want to vote with 50, and use the other 50 for your personal spending, then you just send the voting 50 to another address and wont be moved until voting is over.

Yeah, I think we are on the same page.  I would refer to it as 1 satoshi 1 vote, rather than one bitcoin one vote, but that's a minor quibble.  Just as bitcoin is uncounterfeitable and verifiable, votes are uncounterfeitable and verifiable.  You can't double spend, you can't double vote.  Yes, you're right that there is no need to tie any other forms of identity to this.      

One thing people often don't realize about bitcoin is that the ledger is not a collection of balances held at addresses.  It is a collection of unspent outputs (UTXOs).  In other words, you might say "I have 50k satoshi at address 1aaabc..".  However on the chain what we see is some number of unspent outputs all credited to 1aaabc which total 50k sat.  When spending the 50k sat you need to pick from which unspent outputs they come from (this is handled automatically or manually).

The reason that a proper coin-vote system needs to recognize this fact is that otherwise an attacker could vote, after which sending dust to other addresses with large holdings, thus making it look like future votes from those other large addresses are tainted and should be rejected as potential double-votes.  While you can thusly "taint" an address, it is impossible to thusly taint a UTXO.  

A proper coin-vote thus enables a voter to vote with all the UTXO associated with an address, or with specific UTXOs, to avoid such an attack.  

There is no need to forbid outgoing TX from an address, though if you were lazy and wanted to run a vote that way - yes it would also work to prevent the taint-attack (apart from the disincentive to voters who should rightly be allowed to spend their coin).  It would also make it kind of difficult to keep a running tally of the vote, seeing as you need to often check whether any coin has left an address used for voting (and then invalidate the vote).  This will wind up being a lot more database queries than proper checking of votes when they are submitted.  








 

[RealBitcoin]

Yeah, I think we are on the same page.  I would refer to it as 1 satoshi 1 vote, rather than one bitcoin one vote, but that's a minor quibble.  Just as bitcoin is uncounterfeitable and verifiable, votes are uncounterfeitable and verifiable.  You can't double spend, you can't double vote.  Yes, you're right that there is no need to tie any other forms of identity to this.      

One thing people often don't realize about bitcoin is that the ledger is not a collection of balances held at addresses.  It is a collection of unspent outputs (UTXOs).  In other words, you might say "I have 50k satoshi at address 1aaabc..".  However on the chain what we see is some number of unspent outputs all credited to 1aaabc which total 50k sat.  When spending the 50k sat you need to pick from which unspent outputs they come from (this is handled automatically or manually).

The reason that a proper coin-vote system needs to recognize this fact is that otherwise an attacker could vote, after which sending dust to other addresses with large holdings, thus making it look like future votes from those other large addresses are tainted and should be rejected as potential double-votes.  While you can thusly "taint" an address, it is impossible to thusly taint a UTXO.  

So now he cant send bitcoins to another address and vote? By swapping?

I send you bitcoin A, you send me bitcoin B, I vote with A and B (but i would only have 1 btc power, but i cheat to gain 2). Bitcoins are not fungible, so even if the address is not tainted it can still be double-voted.

If you want to make sure that absolutely not vote-cheating happens ,then you have to filter out addresses that had outgoing TX.

There is no need to forbid outgoing TX from an address, though if you were lazy and wanted to run a vote that way - yes it would also work to prevent the taint-attack (apart from the disincentive to voters who should rightly be allowed to spend their coin).  It would also make it kind of difficult to keep a running tally of the vote, seeing as you need to often check whether any coin has left an address used for voting (and then invalidate the vote).  This will wind up being a lot more database queries than proper checking of votes when they are submitted.  

There is not "forbidding" it's only that once you had a outgoing TX, your vote becomes invalid. You can vote again but but if you spend again then the TX is invalid again.

You dont need to check every time, the checking only happens after the timer runs out.

You should not have any outgoing TX during the voting process. If you cant handle locking your coin away for say 1 week, you can vote in the last hour before the timer runs out.

It is very simple and it makes 100% sure no cheating happens.

[funkenstein]

There is not "forbidding" it's only that once you had a outgoing TX, your vote becomes invalid. You can vote again but but if you spend again then the TX is invalid again.

You dont need to check every time, the checking only happens after the timer runs out.

You should not have any outgoing TX during the voting process. If you cant handle locking your coin away for say 1 week, you can vote in the last hour before the timer runs out.

It is very simple and it makes 100% sure no cheating happens.

Well you're still voting with coin, so more power to you.    

The way we implemented coin-vote.com, we are 100% sure no cheating happens - and users can spend their coin whenever they like, meanwhile there is no requirement to make an official "ending" of a vote, people could continue to send in votes as long as they want and the tally is ALWAYS accurate and verifiable.  Tallies will never decrease.

If you see some vulnerability is the system as i have described it, please do tell.  

We check that the UTXO or set of UTXOs are confirmed on the blockchain when you submit the vote and sum them to the weight of your vote, we check the vote is a corresponding proper signature of the english voting statement, then we check that each UTXO is not an output of a previously used UTXO, then we increment the tally.  Not really that complex.  

[RealBitcoin]

We check that the UTXO or set of UTXOs are confirmed on the blockchain when you submit the vote and sum them to the weight of your vote, we check the vote is a corresponding proper signature of the english voting statement, then we check that each UTXO is not an output of a previously used UTXO, then we increment the tally.  Not really that complex. 

You still dont understand the fungiblility problem.

Jonny has 1 Bitcoin = 1 BTC voting power  he votes yes on Brexit = 50%

Eve has 1 Bitcoin = 1 BTC voting power she votes no on Brexit. = 50%



Eve is smart so she votes, then swaps her BTC with Charlie and Charlie is not interested to vote again. She got a new BTC she votes again.
She then swaps the BTC again with Jimmy, and again Jimmy wont vote again.

Now Eve has only 1 BTC the whole time but she has voted 3 times with fresh coin.

Therefore the vote will end in 75% NO and 25% YES, because Eve cheated. It can be prevented if Jimmy and Charlie votes too, but not all people will vote all the time, so this kind of cheat will be very frequent in your system.

[funkenstein]

We check that the UTXO or set of UTXOs are confirmed on the blockchain when you submit the vote and sum them to the weight of your vote, we check the vote is a corresponding proper signature of the english voting statement, then we check that each UTXO is not an output of a previously used UTXO, then we increment the tally.  Not really that complex. 

You still dont understand the fungiblility problem.

Jonny has 1 Bitcoin = 1 BTC voting power  he votes yes on Brexit = 50%

Eve has 1 Bitcoin = 1 BTC voting power she votes no on Brexit. = 50%



Eve is smart so she votes, then swaps her BTC with Charlie and Charlie is not interested to vote again. She got a new BTC she votes again.
She then swaps the BTC again with Jimmy, and again Jimmy wont vote again.

Now Eve has only 1 BTC the whole time but she has voted 3 times with fresh coin.

Therefore the vote will end in 75% NO and 25% YES, because Eve cheated. It can be prevented if Jimmy and Charlie votes too, but not all people will vote all the time, so this kind of cheat will be very frequent in your system.

Aha!  Thanks for sticking with me and my stubbornness RealBitcoin, I see what you are talking about now.

Indeed, there is the interesting question here of what happens to non-voting coin (Charlie, in your example) and how it can be leveraged by voters.    

Yes, in the coin-vote as I have outlined it Eve could perhaps (for a small fee always) exchange her coin for "fresh" coin, that is - coin which has not voted, thusly increasing her voting power.  

If you set up your vote so that transfers invalidate votes, one can also pay a fee to leverage non-voting coin.  Charlie can simply be paid a small fee (free money for Charlie as he doesn't care about the vote) to sign the voting statement.  If Charlie is willing to make the exchange (non-vote for voted coin), it's likely he will be willing to sign a statement for a small fee.    

I don't see a huge difference between these two.. and indeed the question of how to handle non-voting coin and it's accessibility to voters (buying voting power) is outstanding and deserves further discussion.  Thanks for making it clear here.  

I see a couple potential solutions.  One is that one could mark certain coin as "voting coin".  This is the colored coin solution, that many have used already.  Votes can only be made with these coins and their children and no others.  No more problem from "non-voting coin".  

It seems that requiring coin to not be transfered as you suggest mitigates the issue somewhat, depending on the vote itself and interest.  For example it also stops somebody buying votes with coin that has already voted, though this isn't really much of a difference.  

To come to further conclusions here it seems we need to consider what kind of votes this system is designed for.  At first I thought it would be ideal for coin related issues such as BIPs or forks.  Then I realized that these things are mostly decided economically and the parties involved might not want their power and desire to be public.  For something like voting for a company director, the colored coin solution seems appropriate.  For something like public policy or election of public official, I'm not sure how appropriate it is.  What do you think?  

Cheers --    
  
  

[RealBitcoin]

We check that the UTXO or set of UTXOs are confirmed on the blockchain when you submit the vote and sum them to the weight of your vote, we check the vote is a corresponding proper signature of the english voting statement, then we check that each UTXO is not an output of a previously used UTXO, then we increment the tally.  Not really that complex. 

You still dont understand the fungiblility problem.

Jonny has 1 Bitcoin = 1 BTC voting power  he votes yes on Brexit = 50%

Eve has 1 Bitcoin = 1 BTC voting power she votes no on Brexit. = 50%



Eve is smart so she votes, then swaps her BTC with Charlie and Charlie is not interested to vote again. She got a new BTC she votes again.
She then swaps the BTC again with Jimmy, and again Jimmy wont vote again.

Now Eve has only 1 BTC the whole time but she has voted 3 times with fresh coin.

Therefore the vote will end in 75% NO and 25% YES, because Eve cheated. It can be prevented if Jimmy and Charlie votes too, but not all people will vote all the time, so this kind of cheat will be very frequent in your system.

Aha!  Thanks for sticking with me and my stubbornness RealBitcoin, I see what you are talking about now.

Indeed, there is the interesting question here of what happens to non-voting coin (Charlie, in your example) and how it can be leveraged by voters.     

Yes, in the coin-vote as I have outlined it Eve could perhaps (for a small fee always) exchange her coin for "fresh" coin, that is - coin which has not voted, thusly increasing her voting power. 

If you set up your vote so that transfers invalidate votes, one can also pay a fee to leverage non-voting coin.  Charlie can simply be paid a small fee (free money for Charlie as he doesn't care about the vote) to sign the voting statement.  If Charlie is willing to make the exchange (non-vote for voted coin), it's likely he will be willing to sign a statement for a small fee.   

I don't see a huge difference between these two.. and indeed the question of how to handle non-voting coin and it's accessibility to voters (buying voting power) is outstanding and deserves further discussion.  Thanks for making it clear here. 

Yes, the first one is just swapping coins, the second on is bribery.

Well both are dishonest, at least the coin swapping one can be filtered out by my proposal of not letting outgoing TX.

As for bribing Charlie, I dont think that would work, why would Charlie sell his vote?

If i had 100,000 BTC why would I lease out that voting power when I can just use that power to vote for my benefit. It would make no sense.

It's like if you had an army, and you would lease that army to your ally so that he can conquer an island. When you can just take the island yourself for yourself with your army.

It would make sense for smaller sums, but those guys dont have much voting power anyway.

If the 100,000 BTC i would have can give me enough power to influence the community, i would definitely not lease it out and use it my own.

[funkenstein]

Yes, the first one is just swapping coins, the second on is bribery.

Well both are dishonest, at least the coin swapping one can be filtered out by my proposal of not letting outgoing TX.

As for bribing Charlie, I dont think that would work, why would Charlie sell his vote?

If i had 100,000 BTC why would I lease out that voting power when I can just use that power to vote for my benefit. It would make no sense.

Well why would Charlie swap his un-voted coin for my voted coin then?   

It's like if you had an army, and you would lease that army to your ally so that he can conquer an island. When you can just take the island yourself for yourself with your army.

It would make sense for smaller sums, but those guys dont have much voting power anyway.

If the 100,000 BTC i would have can give me enough power to influence the community, i would definitely not lease it out and use it my own.

Your assumption was that Charlie didn't care about the vote in question.  In this case Charlie wants to take the island so that isn't the case. 

To get further into it we need more specifics.  How about a specific example of a coin-vote you have in mind? 

[RealBitcoin]

Well why would Charlie swap his un-voted coin for my voted coin then?   

Charlie doesnt have to know the purpose in the swapping case, but he will have to know in the bribery case.

If the swapping happens, it might just be an altcoin trade  BTC->LTC->BTC,  you dont even know Charlie, it just happens in an exchange or somewhere.


But if you were to bribe Charlie, then he will know what is going on and he will just rather vote on his own. Besides he doesnt want his coins become tainted to such dishonest things. Why would Charlie risk his reputation for this?

So bottom line, when the information is present, people react differently then when they dont know it.

Your assumption was that Charlie didn't care about the vote in question.  In this case Charlie wants to take the island so that isn't the case. 

To get further into it we need more specifics.  How about a specific example of a coin-vote you have in mind? 

He doesnt have to care, but he might care if you beg him to use his coins.

When the demand for his coins rises, he might charge you huge fees to use his coins, and then the whole thing will just become inneficient.

If he wants 1 BTC to use his BTC, then it will not be worth to bribe Charlie, because you just rather use that 1 extra BTC to vote for yourself.


So the bribe always has to be smaller than the voting power bought. If there are little coins to be swapped (because Charlie also has to denounce the usage of his coins for the voting period, which might be unconfortable), then the bribery fees go up.

So if 1 shady person stands there with 1000 BTC ready to provide for the cheaters, then he will rather just invest that in some other venture than to play this silly game, or he will just vote himself.

So if the bribery fee is too high, then it wont happen. If it's too low, then there wont be any available coins to use.


So I dont think bribery will happen that often to destabilize this voting mechanism