1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
|
Return-Path: <hectorchu@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id C015C7AD
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <bitcoin-dev@lists.linuxfoundation.org>;
Sat, 8 Aug 2015 06:27:57 +0000 (UTC)
Received: by labjt7 with SMTP id jt7so60316947lab.0
for <bitcoin-dev@lists.linuxfoundation.org>;
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 <hectorchu@gmail.com>
Date: Sat, 8 Aug 2015 07:27:35 +0100
Message-ID: <CAAO2FKEFA5ujJKe8F4-5Wnp0DCYuyHWNWhdtk5O=nCZ-zGu0rg@mail.gmail.com>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org>
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 <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=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
<div dir=3D"ltr">Has there ever been any discussion of locking coins till a=
certain date for casting votes on an issue?<div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><di=
v>Not saying this could be used to solve the block size issue necessarily, =
but we could have choices like:</div><div>1) Keep block size the same</div>=
<div>2) Reduce block size 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>
--089e0158b8e44f4233051cc6daee--
|
