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
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
|
Return-Path: <tim.ruffing@mmci.uni-saarland.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 6C7C19FA
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2017 22:29:23 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from juno.mpi-klsb.mpg.de (srv-40-62.mpi-klsb.mpg.de [139.19.86.44])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7862B143
for <bitcoin-dev@lists.linuxfoundation.org>;
Tue, 18 Apr 2017 22:29:22 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mmci.uni-saarland.de; s=mail200803;
h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID;
bh=PV7NFpzP6mmrXH33Ix9sVcp5Qin5v6U+EDoEqj/zL6E=;
b=nFS7NibL19Eeb0RnofdqvazgrmrHrVBdWzdpbJSMRehqN9wUxcULmM7fgZaDNDr40D+zRXa8zVj3/aoB/eDx6PElrb2Jln42NiKEXaLeqYb8JqAxXu423CbZOCVyF8DmliOeusDKkUsqovfCRnE2zoSAVvwds3aR+4Ryv9ZivMU=;
Received: from srv-00-61.mpi-klsb.mpg.de ([139.19.86.26]:34892
helo=sam.mpi-klsb.mpg.de) by juno.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128)
(Exim 4.84_2) id 1d0bcb-000Ym1-Rw
for bitcoin-dev@lists.linuxfoundation.org;
Wed, 19 Apr 2017 00:29:20 +0200
Received: from x4db1c829.dyn.telefonica.de ([77.177.200.41]:39654
helo=calzone.fritz.box) by sam.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.84_2) id 1d0bcb-000QyM-J3
for bitcoin-dev@lists.linuxfoundation.org;
Wed, 19 Apr 2017 00:29:17 +0200
Message-ID: <1492554557.1625.4.camel@mmci.uni-saarland.de>
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Wed, 19 Apr 2017 00:29:17 +0200
In-Reply-To: <CALxbBHVY6_Xuq4Si9yQ0+dL_9DTCdwiWLDFStzFO2xRvHzTyBQ@mail.gmail.com>
References: <CAJowKgJ38kA_vPGF6KpKEnrRzStrk-Mj87bttaOw-dvLW675Jw@mail.gmail.com>
<CAJowKgK4j=sL2vh1bxWh2WWw0vw1PuxfJ39JW7bQS-UDzKh6CQ@mail.gmail.com>
<CAJowKgKAnrMKiLdONrXJtGQYhYgRSXq7JNWrY=zUEMvw4WSX9w@mail.gmail.com>
<CAJowKgL-NB0zF-Ud52Jr6n0Fo-uV=bXzVAFMOKmhAVA0RdRVuQ@mail.gmail.com>
<CAJowKgJGZJMondTmsdOLdqqY1mf9S+TaB8UmdCtsLF6PA2RSJw@mail.gmail.com>
<CAJowKg+gZcNO+-sdmt55KOt+zuN+8m7Hiqh77s9=gYpyszDwmA@mail.gmail.com>
<CAJowKgKC4+6vv0QUH_DRASVqU4jui-iXG6TDgEpGUHRkVwJFqg@mail.gmail.com>
<CAJowKgKH2h1QwpEvZ30OuEUsTCg1OoD6JcuXdmS+d_pKpygFcQ@mail.gmail.com>
<CAJowKg+EJGXA5=LjJhCo1YevQtBubEftSNPfnzE4b5ESCwrUMg@mail.gmail.com>
<CAJowKgLQCqL37oCzkJc8gPnUCkPYtF6G8_7Ug4AP5FpTOonBWQ@mail.gmail.com>
<CAJowKgJ-eoF6ZCKrWbJQDcMK8-jTZxD+J_6tGAyfXz+HYrqmXg@mail.gmail.com>
<CAJowKgKEVxS9OCg=Lioc1gRAy1Ftc27bp3nr2R9MQX-VQ9PrhQ@mail.gmail.com>
<CALxbBHVY6_Xuq4Si9yQ0+dL_9DTCdwiWLDFStzFO2xRvHzTyBQ@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.6
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
X-MPI-Local-Sender: true
X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED 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] Transaction signalling
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Tue, 18 Apr 2017 22:29:23 -0000
I don't have an opinion on whether signaling is a good idea in general.
However I don't think that using addresses is a good idea, because this
has privacy implications. For example, it makes it much easier to link
the addresses, e.g., inputs with change address. (The change address
votes for the same proposal as the input address.)
Tim
On Tue, 2017-04-18 at 18:07 +0000, Christian Decker via bitcoin-dev
wrote:
> I really like the idea of extending signalling capabilities to the
> end-users. It gives stakeholders a voice in the decisions we take in
> the network, and are a clear signal to all other involved parties. It
> reminds me of a student thesis I supervised some time ago [1], in
> which we explored various signalling ideas.
>
> I think we have a number of fields that may be used for such a
> signalling, e.g., OP_RETURN, locktime, and output scripts. I think
> OP_RETURN is probably not the field you'd want to use though since it
> adds data that needs to be transferred, stored for bootstrap, and
> outputs in the UTXO would need to be tagged with additional
> information. Locktime has the advantage of being mostly a freeform
> field for values in the past, but it clashes with other uses that may
> rely on it. Furthermore, it is the transaction creator that specifies
> the locktime, hence the signal trails one hop behind the current
> owner, i.e., the actual stakeholder.
>
> I think probably the best field to signal would be the output
> script. It is specified by the recipient of the funds, i.e., the
> current owner, and is already stored in the UTXO, so a single pass
> can
> tally up the votes. We could for example use the last 4 bits of the
> pubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1
> depending on the stakeholders desired signal). We'd need to define
> similar semantics for other script types, but getting the standard
> scripts to be recognized should be simple.
>
> In the spirit of full disclosure I'd like to also mention some of the
> downsides of voting this way. Unlike the OP_RETURN proposal, users
> that do not intend to signal will also be included in the tally. I'd
> expect the signals of these users to be random with a 50% chance of
> either outcome, so they should not influence the final result, but
> may
> muddy the water depending on what part of the population is
> signalling. The opt-in should make sure that the majority of votes
> are
> actually voluntary votes, and not just users that randomly select a
> pubkey/pubkeyhash, and can be adjusted as desired, though higher
> values require more grinding on behalf of the users.
>
> The grinding may also exacerbate some problems we already have with
> the HD Wallet lookahead, since we now skip a number of addresses, so
> we should not require too many opt-in bits.
>
> So there are some problems we'd need to tackle, but I'm really
> excited
> about this, as it could provide data to make informed decisions, and
> should put an end to the endless speculation about the will of the
> economic majority.
>
> Cheers,
> Christian
>
> [1] http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
