From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 09A9A87A for ; Sat, 8 Aug 2015 06:36:27 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-lb0-f176.google.com (mail-lb0-f176.google.com [209.85.217.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 5DF50A8 for ; Sat, 8 Aug 2015 06:36:26 +0000 (UTC) Received: by lbbtg9 with SMTP id tg9so33449649lbb.1 for ; Fri, 07 Aug 2015 23:36:24 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :content-type; bh=55vYdCRmL6flb5U6w0n4OxftsXb9iFysQKcLeBGN8Q8=; b=F17wBAk59Wyr6Faz6R84NJSjdH3aVAgFw5nJqCssUzeJfiet067svA9IUt2mi7VEqu I4Gh29zBMncZn/UUtb65Ssn6GCSARO+FGgqB4YSY6nC1+EOiTjw//u5+QXtr1SXJcxN1 laqe7A7WIzGEAuB7YIoM1jQefUBlEvnaSstGYzCY5uF3VUn/rnmPtjQWPKN4AuS3R9Yj I9qNLtr40rXWzpO14OWVi4HrAY3mB8xyW5xmkeXWvE6A+VONLKbbl/yDe021nQ4EZMzo 2+t8apiM31P0TdbtSERKbNOR1n7lGV9JjShic5Fz9uuh5rTyJfqiXrHFGo0b9Kk513ef 1DPw== X-Received: by 10.152.203.172 with SMTP id kr12mr11596033lac.71.1439015784754; Fri, 07 Aug 2015 23:36:24 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.25 with HTTP; Fri, 7 Aug 2015 23:36:04 -0700 (PDT) In-Reply-To: References: From: Hector Chu Date: Sat, 8 Aug 2015 07:36:04 +0100 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=001a113472faad38de051cc6f8c2 X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] Voting by locking coins X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Development Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 08 Aug 2015 06:36:27 -0000 --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 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
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&g= t; wrote:
Has the= re ever been any discussion of locking coins till a certain date for castin= g votes on an issue?

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.

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.

Not saying this could = be used to solve the block size issue necessarily, but we could have choice= s like:
1) Keep block size the same
2) Reduce block siz= e 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--