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