Voting by locking coins
6 messages, 8 Aug 2015. Started by Hector Chu.
Hector Chu (4), Peter Todd (2)
Has there ever been any discussion of locking coins till a certain date for casting votes on an issue?
Say that the date for counting votes is 3 months from now. Every one who wants to cast a vote must lock coins until the vote closes (using CLTV). To increase the weight of your vote, lock more coins. Write your choice in the scriptPubKey or an OP_RETURN data output.
On the date the vote closes the nodes tally up the coin values for the various vote options, and the choice with the highest total is the winner.
Not saying this could be used to solve the block size issue necessarily, but we could have choices like: 1) Keep block size the same 2) Reduce block size by 10%. 3) Increase block size by 10%.
The vote could be a rolling one. When the present vote is decided the vote for the next 3 months starts.
Also there may need to be weighting depending on how long the coins have been locked for, to stop voting at the last minute having an undue influence.
On 8 August 2015 at 07:27, Hector Chu <hectorchu@gmail•com> wrote:
Quoted text (20 lines)
> Has there ever been any discussion of locking coins till a certain date > for casting votes on an issue? > > Say that the date for counting votes is 3 months from now. Every one who > wants to cast a vote must lock coins until the vote closes (using CLTV). To > increase the weight of your vote, lock more coins. Write your choice in the > scriptPubKey or an OP_RETURN data output. > > On the date the vote closes the nodes tally up the coin values for the > various vote options, and the choice with the highest total is the winner. > > Not saying this could be used to solve the block size issue necessarily, > but we could have choices like: > 1) Keep block size the same > 2) Reduce block size by 10%. > 3) Increase block size by 10%. > > The vote could be a rolling one. When the present vote is decided the vote > for the next 3 months starts. >
On 8 August 2015 02:27:35 GMT-04:00, Hector Chu via bitcoin-dev <bitcoin-dev@lists•linuxfoundation•org> wrote:
Quoted text (3 lines)
>Has there ever been any discussion of locking coins till a certain date >for >casting votes on an issue?
Yes, John Dillon proposed a very clever and viable blocksize vote scheme on this list awhile back: https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html
Thanks for this Peter. It is quite long winded and complicated so I just wanted to clarify one particular point. In John's proposal, are the coins actually locked up, or are they still freely spendable post-vote? Otherwise there is no real cost to casting votes. Locking coins up is related to the time-value of money and has a cost the longer they are locked up for.
On 8 August 2015 at 15:23, Peter Todd <pete@petertodd•org> wrote:
Quoted text (27 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 8 August 2015 02:27:35 GMT-04:00, Hector Chu via bitcoin-dev < > bitcoin-dev@lists•linuxfoundation•org> wrote: > >Has there ever been any discussion of locking coins till a certain date > >for > >casting votes on an issue? > > Yes, John Dillon proposed a very clever and viable blocksize vote scheme > on this list awhile back: > https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg02323.html > -----BEGIN PGP SIGNATURE----- > > iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVxhDI > AAoJEMCF8hzn9Lnc47AH/Rg+JEhId23fKmUUDvYo8FA4N03nPjbsYBNdAAXHufUQ > 6KQz8h+yjYKMBTU0r4ONyssQtqtsJtWQpLjANZlYlTB82WuPKNPhrAD3Kqkj7x+t > L6ROTktoBnGvhPLCkRdpIjnGwcBhVFFxePQCySJrRT+w+5WZtcyVtx0JDdttJREF > 5Ctdf2K6IbVJ10joQHY46IlGpVNiOhx4mJ2SyCHy5Ug4lWToHto0KYJplK5GDXTi > 8IfPNrnqTjm5ExeyE3/d86je9sbHJvSYIrMsUCk74e244+VTUK35ms8xoA0n2yyn > M1g6HAmA6OR61WvnQHaCYLT6f7XrDh8s0+BmpHrrF6E= > =p+Go > -----END PGP SIGNATURE----- > >
On 8 August 2015 11:03:04 GMT-04:00, Hector Chu <hectorchu@gmail•com> wrote:
Quoted text (9 lines)
>Thanks for this Peter. It is quite long winded and complicated so I >just >wanted to clarify one particular point. In John's proposal, are the >coins >actually locked up, or are they still freely spendable post-vote? >Otherwise >there is no real cost to casting votes. Locking coins up is related to >the >time-value of money and has a cost the longer they are locked up for.
John Dillon's proposal is essentially to have the economic majority give miners *permission* to raise the blocksize; making the vote costly is against the design intent of accurately capturing the broadest possible economic consensus.
I think that if a vote was free, no matter how much weight it carried, then it could be easily bought and the vote manipulated. If the cost of the vote was proportional to its weight, then it would be harder to manipulate the vote. I know I haven't explained that thoroughly, but as an analogy think to how markets determine the clearing price for a good. Votes in markets cost money.
On 8 August 2015 at 16:10, Peter Todd <pete@petertodd•org> wrote:
Quoted text (35 lines)
> -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 8 August 2015 11:03:04 GMT-04:00, Hector Chu <hectorchu@gmail•com> > wrote: > >Thanks for this Peter. It is quite long winded and complicated so I > >just > >wanted to clarify one particular point. In John's proposal, are the > >coins > >actually locked up, or are they still freely spendable post-vote? > >Otherwise > >there is no real cost to casting votes. Locking coins up is related to > >the > >time-value of money and has a cost the longer they are locked up for. > > John Dillon's proposal is essentially to have the economic majority give > miners *permission* to raise the blocksize; making the vote costly is > against the design intent of accurately capturing the broadest possible > economic consensus. > > -----BEGIN PGP SIGNATURE----- > > iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJVxhvv > AAoJEMCF8hzn9Lnc47AH/1/4QjqSS2yYndM5evkl4h9ZJDxpeq++21pDprKn1HSu > a5+0M8bcM1Jlk5+GSFqDLl920yQXTPZ5AOvJ9F6085/g2heGEg2iHP/iJsOGK6xe > VWF/yR8sFYEe41BXP9r/la/AUFPcQWFUBqZgPqDBCqr87k2Hn5d3t0VITNwNHCge > VJKlESGyyg3nMxfrvQq1YspKBkhTpIFMz1aw0CUh3kVOpmW2luFcA7SQzOWfBgDd > 3ZExFhcn/5GcK3GudRsvcPNSIZQzeZcX2uQHCzQa7kvPdlZ1XntkE2ojy31Zq0nv > Pj+CDBeKYtr4R0ZEn2bKhq39C3+1SZa5XkuCHAanBbQ= > =vp56 > -----END PGP SIGNATURE----- > >