Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id C015C7AD for ; Sat, 8 Aug 2015 06:27:57 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-la0-f42.google.com (mail-la0-f42.google.com [209.85.215.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2C321A8 for ; Sat, 8 Aug 2015 06:27:57 +0000 (UTC) Received: by labjt7 with SMTP id jt7so60316947lab.0 for ; Fri, 07 Aug 2015 23:27:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=Mk/7WgBTJkRiOEJnZSgP0AzNoQWS/RvJLno3irAKJyI=; b=N58SrV4BSJbWY9Fk1gER88JXj/CTAAuIwFkt5QvYSIJDVOTnm/Mw8pP8TNOfVvsUay Vd5lMICy9O9gR+esNmKekDPxWw6Io+fwIXhFrv/YA1Zmt/16J41NUg+Tc+r/tcE/+Kkj myM3UiztQdKCvxEv5Am2qthLOaiilPyNK+3mide8efGQviEYF6aiVN0SrqPRGdDDzsPS zA5GwQlueV3choUzWNDtqnEPRDJkeXSPjCefgKSDzALYkNcaHH+OXPlyZCCrRObbGl6u 2ivrT8ZmZhP5i8SqFVn6LCob/LpQJrbS6B9Z1bCN4Mele/DCzLVUCZsMhCBVCY6+s+Im XOkA== X-Received: by 10.152.8.130 with SMTP id r2mr11616877laa.17.1439015275281; Fri, 07 Aug 2015 23:27:55 -0700 (PDT) MIME-Version: 1.0 Received: by 10.25.22.25 with HTTP; Fri, 7 Aug 2015 23:27:35 -0700 (PDT) From: Hector Chu Date: Sat, 8 Aug 2015 07:27:35 +0100 Message-ID: To: Bitcoin Dev Content-Type: multipart/alternative; boundary=089e0158b8e44f4233051cc6daee 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: [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:27:57 -0000 --089e0158b8e44f4233051cc6daee Content-Type: text/plain; charset=UTF-8 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. --089e0158b8e44f4233051cc6daee Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Has there ever been any discussion of locking coins till a= certain date for casting votes on an issue?

Say that th= e 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 scriptPubKe= y or an OP_RETURN data output.

On the date the vot= e closes the nodes tally up the coin values for the various vote options, a= nd 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%.<= /div>

The vote could be a rolling one. When the present = vote is decided the vote for the next 3 months starts.
--089e0158b8e44f4233051cc6daee--