MIME-Version: 1.0
In-Reply-To: <CAAO2FKEFA5ujJKe8F4-5Wnp0DCYuyHWNWhdtk5O=nCZ-zGu0rg@mail.gmail.com>
References: <CAAO2FKEFA5ujJKe8F4-5Wnp0DCYuyHWNWhdtk5O=nCZ-zGu0rg@mail.gmail.com>
From: Hector Chu <hectorchu@gmail.com>
Date: Sat, 8 Aug 2015 07:36:04 +0100
Message-ID: <CAAO2FKG-BpYA=qSQkjVVajtQWqZgXGEFEL7N8zJj=9Xu1E6SZw@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113472faad38de051cc6f8c2
Subject: Re: [bitcoin-dev] Voting by locking coins
Precedence: list

--001a113472faad38de051cc6f8c2
Content-Type: text/plain; charset=UTF-8

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:

> 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.
>

--001a113472faad38de051cc6f8c2
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">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.</div><div class=3D"gmail_extra"><br><div class=3D"gmail_q=
uote">On 8 August 2015 at 07:27, Hector Chu <span dir=3D"ltr">&lt;<a href=
=3D"mailto:hectorchu@gmail.com" target=3D"_blank">hectorchu@gmail.com</a>&g=
t;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0=
 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr">Has the=
re ever been any discussion of locking coins till a certain date for castin=
g votes on an issue?<div><br></div><div>Say that the date for counting vote=
s 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, lo=
ck more coins. Write your choice in the scriptPubKey or an OP_RETURN data o=
utput.</div><div><br></div><div>On the date the vote closes the nodes tally=
 up the coin values for the various vote options, and the choice with the h=
ighest total is the winner.</div><div><br></div><div>Not saying this could =
be used to solve the block size issue necessarily, but we could have choice=
s like:</div><div>1) Keep block size the same</div><div>2) Reduce block siz=
e by 10%.</div><div>3) Increase block size by 10%.</div><div><br></div><div=
>The vote could be a rolling one. When the present vote is decided the vote=
 for the next 3 months starts.</div></div>
</blockquote></div><br></div>

--001a113472faad38de051cc6f8c2--