<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 "economic majority" 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"><<a href="mailto:bitcoin-dev@lists.linuxfoundation.org" target="_blank">bitcoin-dev@lists.linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I don't have an opinion on whether signaling is a good idea in general.<br>
<br>
However I don'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">> I really like the idea of extending signalling capabilities to the<br>
> end-users. It gives stakeholders a voice in the decisions we take in<br>
> the network, and are a clear signal to all other involved parties. It<br>
> reminds me of a student thesis I supervised some time ago [1], in<br>
> which we explored various signalling ideas.<br>
><br>
> I think we have a number of fields that may be used for such a<br>
> signalling, e.g., OP_RETURN, locktime, and output scripts. I think<br>
> OP_RETURN is probably not the field you'd want to use though since it<br>
> adds data that needs to be transferred, stored for bootstrap, and<br>
> outputs in the UTXO would need to be tagged with additional<br>
> information. Locktime has the advantage of being mostly a freeform<br>
> field for values in the past, but it clashes with other uses that may<br>
> rely on it. Furthermore, it is the transaction creator that specifies<br>
> the locktime, hence the signal trails one hop behind the current<br>
> owner, i.e., the actual stakeholder.<br>
><br>
> I think probably the best field to signal would be the output<br>
> script. It is specified by the recipient of the funds, i.e., the<br>
> current owner, and is already stored in the UTXO, so a single pass<br>
> can<br>
> tally up the votes. We could for example use the last 4 bits of the<br>
> pubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1<br>
> depending on the stakeholders desired signal). We'd need to define<br>
> similar semantics for other script types, but getting the standard<br>
> scripts to be recognized should be simple.<br>
><br>
> In the spirit of full disclosure I'd like to also mention some of the<br>
> downsides of voting this way. Unlike the OP_RETURN proposal, users<br>
> that do not intend to signal will also be included in the tally. I'd<br>
> expect the signals of these users to be random with a 50% chance of<br>
> either outcome, so they should not influence the final result, but<br>
> may<br>
> muddy the water depending on what part of the population is<br>
> signalling. The opt-in should make sure that the majority of votes<br>
> are<br>
> actually voluntary votes, and not just users that randomly select a<br>
> pubkey/pubkeyhash, and can be adjusted as desired, though higher<br>
> values require more grinding on behalf of the users.<br>
><br>
> The grinding may also exacerbate some problems we already have with<br>
> the HD Wallet lookahead, since we now skip a number of addresses, so<br>
> we should not require too many opt-in bits.<br>
><br>
> So there are some problems we'd need to tackle, but I'm really<br>
> excited<br>
> about this, as it could provide data to make informed decisions, and<br>
> should put an end to the endless speculation about the will of the<br>
> economic majority.<br>
><br>
> Cheers,<br>
> Christian<br>
><br>
> [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">> ______________________________<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>
______________________________<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>