<div dir="ltr"><div>I agree, addresses create vulnerability, an OP_RETURN signal seems the safest way to go for UA signalling.   I can model a BIP after BIP9, with some discussion of how to properly collect statistics, and the ability for nodes to activate features based on an &quot;economic majority&quot; defined in this way.<br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Apr 18, 2017 at 6:29 PM, Tim Ruffing via bitcoin-dev <span dir="ltr">&lt;<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don&#39;t have an opinion on whether signaling is a good idea in general.<br>
<br>
However I don&#39;t think that using addresses is a good idea, because this<br>
has privacy implications. For example, it makes it much easier to link<br>
the addresses, e.g., inputs with change address. (The change address<br>
votes for the same proposal as the input address.)<br>
<br>
Tim<br>
<br>
On Tue, 2017-04-18 at 18:07 +0000, Christian Decker via bitcoin-dev<br>
wrote:<br>
<div class="HOEnZb"><div class="h5">&gt; I really like the idea of extending signalling capabilities to the<br>
&gt; end-users. It gives stakeholders a voice in the decisions we take in<br>
&gt; the network, and are a clear signal to all other involved parties. It<br>
&gt; reminds me of a student thesis I supervised some time ago [1], in<br>
&gt; which we explored various signalling ideas.<br>
&gt;<br>
&gt; I think we have a number of fields that may be used for such a<br>
&gt; signalling, e.g., OP_RETURN, locktime, and output scripts. I think<br>
&gt; OP_RETURN is probably not the field you&#39;d want to use though since it<br>
&gt; adds data that needs to be transferred, stored for bootstrap, and<br>
&gt; outputs in the UTXO would need to be tagged with additional<br>
&gt; information. Locktime has the advantage of being mostly a freeform<br>
&gt; field for values in the past, but it clashes with other uses that may<br>
&gt; rely on it. Furthermore, it is the transaction creator that specifies<br>
&gt; the locktime, hence the signal trails one hop behind the current<br>
&gt; owner, i.e., the actual stakeholder.<br>
&gt;<br>
&gt; I think probably the best field to signal would be the output<br>
&gt; script. It is specified by the recipient of the funds, i.e., the<br>
&gt; current owner, and is already stored in the UTXO, so a single pass<br>
&gt; can<br>
&gt; tally up the votes. We could for example use the last 4 bits of the<br>
&gt; pubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1<br>
&gt; depending on the stakeholders desired signal). We&#39;d need to define<br>
&gt; similar semantics for other script types, but getting the standard<br>
&gt; scripts to be recognized should be simple.<br>
&gt;<br>
&gt; In the spirit of full disclosure I&#39;d like to also mention some of the<br>
&gt; downsides of voting this way. Unlike the OP_RETURN proposal, users<br>
&gt; that do not intend to signal will also be included in the tally. I&#39;d<br>
&gt; expect the signals of these users to be random with a 50% chance of<br>
&gt; either outcome, so they should not influence the final result, but<br>
&gt; may<br>
&gt; muddy the water depending on what part of the population is<br>
&gt; signalling. The opt-in should make sure that the majority of votes<br>
&gt; are<br>
&gt; actually voluntary votes, and not just users that randomly select a<br>
&gt; pubkey/pubkeyhash, and can be adjusted as desired, though higher<br>
&gt; values require more grinding on behalf of the users.<br>
&gt;<br>
&gt; The grinding may also exacerbate some problems we already have with<br>
&gt; the HD Wallet lookahead, since we now skip a number of addresses, so<br>
&gt; we should not require too many opt-in bits.<br>
&gt;<br>
&gt; So there are some problems we&#39;d need to tackle, but I&#39;m really<br>
&gt; excited<br>
&gt; about this, as it could provide data to make informed decisions, and<br>
&gt; should put an end to the endless speculation about the will of the<br>
&gt; economic majority.<br>
&gt;<br>
&gt; Cheers,<br>
&gt; Christian<br>
&gt;<br>
&gt; [1] <a href="http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf" rel="noreferrer" target="_blank">http://pub.tik.ee.ethz.ch/<wbr>students/2015-HS/SA-2015-30.<wbr>pdf</a><br>
</div></div><div class="HOEnZb"><div class="h5">&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt; <a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href="mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
<a href="https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" rel="noreferrer" target="_blank">https://lists.linuxfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>