Probably a bad idea for various reasons, but tagging (fee paying)transactions with info about the capabilities of the node that createdit might be interesting? Might be useful to gauge economic support forcertain upgrades, especially if excluding long transaction chains,etc. In the very least it would be a far better indicator than simplycounting reachable nodes.

On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-devIf users added a signal to OP_RETURN, might it be possible to tag allvalidated input addresses with that signal.Then a node can activate a new feature after the percentage of tagged inputaddresses reaches a certain level within a certain period of time?This could be used in addition to a flag day to trigger activation of afeature with some reassurance of user uptake._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Just to be clear, the tagging would occur on the addresses, and theweighting would be by value, so it's a measure of economic significance.Major exchanges will regularly tag massive amounts of Bitcoins with theircapabilities.

Just adding a nice bit-field and a tagging standard, and then charting itmight be enough to "think about how to use it later". The only problemwould be that this would interfere with "other uses of op_return" ...colored coins, etc.

Personally, I think that's OK, since the purpose is to tag economicallymeaningful nodes to the Bitcoin ecosystem and colored coins, by definition,only have value to "other ecosystems".

(Counterargument: Suppose in some future where this is used as analternative to BIP9 for a user-coordinated code release - especially insituations where miners have rejected activation of a widely-regardedproposal. Suppose also, in that future, colored coin ICO's that useop-return are regularly used to float the shares of major corporation. Itmight be irresponsible to exclude them from coordinating protocol changes.)

Post by Marcel Jamin via bitcoin-devProbably a bad idea for various reasons, but tagging (fee paying)transactions with info about the capabilities of the node that createdit might be interesting? Might be useful to gauge economic support forcertain upgrades, especially if excluding long transaction chains,etc. In the very least it would be a far better indicator than simplycounting reachable nodes.On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev

Post by Erik Aronesty via bitcoin-devIf users added a signal to OP_RETURN, might it be possible to tag allvalidated input addresses with that signal.Then a node can activate a new feature after the percentage of tagged

input

Post by Erik Aronesty via bitcoin-devaddresses reaches a certain level within a certain period of time?This could be used in addition to a flag day to trigger activation of afeature with some reassurance of user uptake._______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I really like the idea of extending signalling capabilities to theend-users. It gives stakeholders a voice in the decisions we take inthe network, and are a clear signal to all other involved parties. Itreminds me of a student thesis I supervised some time ago [1], inwhich we explored various signalling ideas.

I think we have a number of fields that may be used for such asignalling, e.g., OP_RETURN, locktime, and output scripts. I thinkOP_RETURN is probably not the field you'd want to use though since itadds data that needs to be transferred, stored for bootstrap, andoutputs in the UTXO would need to be tagged with additionalinformation. Locktime has the advantage of being mostly a freeformfield for values in the past, but it clashes with other uses that mayrely on it. Furthermore, it is the transaction creator that specifiesthe locktime, hence the signal trails one hop behind the currentowner, i.e., the actual stakeholder.

I think probably the best field to signal would be the outputscript. It is specified by the recipient of the funds, i.e., thecurrent owner, and is already stored in the UTXO, so a single pass cantally up the votes. We could for example use the last 4 bits of thepubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1depending on the stakeholders desired signal). We'd need to definesimilar semantics for other script types, but getting the standardscripts to be recognized should be simple.

In the spirit of full disclosure I'd like to also mention some of thedownsides of voting this way. Unlike the OP_RETURN proposal, usersthat do not intend to signal will also be included in the tally. I'dexpect the signals of these users to be random with a 50% chance ofeither outcome, so they should not influence the final result, but maymuddy the water depending on what part of the population issignalling. The opt-in should make sure that the majority of votes areactually voluntary votes, and not just users that randomly select apubkey/pubkeyhash, and can be adjusted as desired, though highervalues require more grinding on behalf of the users.

The grinding may also exacerbate some problems we already have withthe HD Wallet lookahead, since we now skip a number of addresses, sowe should not require too many opt-in bits.

So there are some problems we'd need to tackle, but I'm really excitedabout this, as it could provide data to make informed decisions, andshould put an end to the endless speculation about the will of theeconomic majority.

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 thishas privacy implications. For example, it makes it much easier to linkthe addresses, e.g., inputs with change address. (The change addressvotes for the same proposal as the input address.)

Tim

On Tue, 2017-04-18 at 18:07 +0000, Christian Decker via bitcoin-dev

Post by Christian Decker via bitcoin-devI really like the idea of extending signalling capabilities to theend-users. It gives stakeholders a voice in the decisions we take inthe network, and are a clear signal to all other involved parties. Itreminds me of a student thesis I supervised some time ago [1], inwhich we explored various signalling ideas.I think we have a number of fields that may be used for such asignalling, e.g., OP_RETURN, locktime, and output scripts. I thinkOP_RETURN is probably not the field you'd want to use though since itadds data that needs to be transferred, stored for bootstrap, andoutputs in the UTXO would need to be tagged with additionalinformation. Locktime has the advantage of being mostly a freeformfield for values in the past, but it clashes with other uses that mayrely on it. Furthermore, it is the transaction creator that specifiesthe locktime, hence the signal trails one hop behind the currentowner, i.e., the actual stakeholder.I think probably the best field to signal would be the outputscript. It is specified by the recipient of the funds, i.e., thecurrent owner, and is already stored in the UTXO, so a single pass cantally up the votes. We could for example use the last 4 bits of thepubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1depending on the stakeholders desired signal). We'd need to definesimilar semantics for other script types, but getting the standardscripts to be recognized should be simple.In the spirit of full disclosure I'd like to also mention some of thedownsides of voting this way. Unlike the OP_RETURN proposal, usersthat do not intend to signal will also be included in the tally. I'dexpect the signals of these users to be random with a 50% chance ofeither outcome, so they should not influence the final result, but maymuddy the water depending on what part of the population issignalling. The opt-in should make sure that the majority of votes areactually voluntary votes, and not just users that randomly select apubkey/pubkeyhash, and can be adjusted as desired, though highervalues require more grinding on behalf of the users.The grinding may also exacerbate some problems we already have withthe HD Wallet lookahead, since we now skip a number of addresses, sowe should not require too many opt-in bits.So there are some problems we'd need to tackle, but I'm reallyexcitedabout this, as it could provide data to make informed decisions, andshould put an end to the endless speculation about the will of theeconomic majority.Cheers,Christian[1] http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

I agree, addresses create vulnerability, an OP_RETURN signal seems thesafest way to go for UA signalling. I can model a BIP after BIP9, withsome discussion of how to properly collect statistics, and the ability fornodes to activate features based on an "economic majority" defined in thisway.

On Tue, Apr 18, 2017 at 6:29 PM, Tim Ruffing via bitcoin-dev <

Post by Tim Ruffing via bitcoin-devI 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 thishas privacy implications. For example, it makes it much easier to linkthe addresses, e.g., inputs with change address. (The change addressvotes for the same proposal as the input address.)TimOn Tue, 2017-04-18 at 18:07 +0000, Christian Decker via bitcoin-dev

Post by Christian Decker via bitcoin-devI really like the idea of extending signalling capabilities to theend-users. It gives stakeholders a voice in the decisions we take inthe network, and are a clear signal to all other involved parties. Itreminds me of a student thesis I supervised some time ago [1], inwhich we explored various signalling ideas.I think we have a number of fields that may be used for such asignalling, e.g., OP_RETURN, locktime, and output scripts. I thinkOP_RETURN is probably not the field you'd want to use though since itadds data that needs to be transferred, stored for bootstrap, andoutputs in the UTXO would need to be tagged with additionalinformation. Locktime has the advantage of being mostly a freeformfield for values in the past, but it clashes with other uses that mayrely on it. Furthermore, it is the transaction creator that specifiesthe locktime, hence the signal trails one hop behind the currentowner, i.e., the actual stakeholder.I think probably the best field to signal would be the outputscript. It is specified by the recipient of the funds, i.e., thecurrent owner, and is already stored in the UTXO, so a single pass cantally up the votes. We could for example use the last 4 bits of thepubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1depending on the stakeholders desired signal). We'd need to definesimilar semantics for other script types, but getting the standardscripts to be recognized should be simple.In the spirit of full disclosure I'd like to also mention some of thedownsides of voting this way. Unlike the OP_RETURN proposal, usersthat do not intend to signal will also be included in the tally. I'dexpect the signals of these users to be random with a 50% chance ofeither outcome, so they should not influence the final result, but maymuddy the water depending on what part of the population issignalling. The opt-in should make sure that the majority of votes areactually voluntary votes, and not just users that randomly select apubkey/pubkeyhash, and can be adjusted as desired, though highervalues require more grinding on behalf of the users.The grinding may also exacerbate some problems we already have withthe HD Wallet lookahead, since we now skip a number of addresses, sowe should not require too many opt-in bits.So there are some problems we'd need to tackle, but I'm really excitedabout this, as it could provide data to make informed decisions, andshould put an end to the endless speculation about the will of theeconomic majority.Cheers,Christian[1] http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

A proposed change to a usage of the 'OP_RETURN' script opcode in Bitcointransactions, allowing multiple changes (features) to be deployed inparallel. It relies on interpreting the output field as a bit vector, whereeach bit can be used to track an independent change. Like BIP9, once aconsensus change succeeds or times out, there is a "fallow" pause afterwhich the bit can be reused for later changes.

==Motivation==

BIP 9 introduced a mechanism for doing soft-forking changes, relying onmeasuring miner support indicated by version bits in block headers. As itrelies on miner support, any change which may conflict with miners but isacceptable to users may be difficult to deploy. The alternative, aflag-day deployment can cause issues for users of a feature that has failedto achieve adequate miner support.

BIP XXXX, if used for deployment, can be used in conjunction with BIP 9, inorder to more safely deploy soft-forking changes that do not require asupermajority of miners, but do require a large percentage of activeusers.

Alternatively, BIP XXXX signalling can be used to gauge user support for"features" - independent of its use as a direct deployment mechanism. Inthis document a "feature" can be considered synonymous with "soft fork",but since this mechanism is "user activated", it is not necessarilyrestricted to soft-forks.

==Specification==

Each "feature" is specified by the sames set of per-chain parameters as inBIP9, with the same usage and meaning (name, bit, starttime and timeout).

===Bit flags===

If the outputs contain a zero valued OP_RETURN, and the length of the keyis 2 bytes, and if the first byte (prefix) of that OP_RETURN's keyparameter is 0x012, then the remaining byte is to be interpreted as an8-bit little-endian integer, and bits are selected within this integer asvalues (1 << N) where N is the bit number. This allows up to 8 features tobe in the STARTED state at a time.

===Array determination===

In order for this to successfully be used for deployment, a lightweightUTXO must be maintained in memory. For each bit in STARTED state, acorresponding bit is set in a map entry for each input address. Eachinput address is hashed to a 24 bit value using SHA3-256(input)[0:24]. Anarray with 16777216 2-byte entries (~32MB RAM) is used to record thecurrent activation state. The first byte contains the bit flags mostrecently associated with an entry.

The second byte contains the log base 2 of the number of "1/100th" bitcoinsmost recently associated with this entry. This is computed by taking thevalue, multiplying by 100, converting to an unsigned 32 bit integer, andusing the log2_32 function below (.... log2_32 func defined below ....).

This array is initialized to zero. The array must be stored andmaintained for each block. When a block is in the STARTED state for anybit, the array is updated for each transaction in the block according tothe rules above: a[i][0]=bits, a[i][1]=log2_32(....)

===State transitions===

State transitions work the same as BIP9, however, the determination of theLOCKED_IN tally is as follows:

For each bit in STARTED state, using the array above, the values aretotaled (unsigned int)(2 << a[i][1]) for each entry where this bit is setin a[i][0]. In addition the total of all the entries in a, irrespective ofbit, are computed. This can be done in a single pass, resulting in avector of up to 8 32 bit entries containing the "feature totals" for thearray, and one extra 32 bit entry for the sum total of observations sincethe start time.

The percentage of observations is computed for each bit. Up to 8 featurescan be computed at a time, with reuse similar to BIP9.

If 2016 sequential blocks have a value of 95% or greater, a feature is"LOCKED_IN", (75% on testnet)bit.

Similar to BIP9, a block's state never depends on its own transactions set;only on that of its ancestors. ACTIVE and FAILED are terminal states, etc.

Post by Erik Aronesty via bitcoin-devI agree, addresses create vulnerability, an OP_RETURN signal seems thesafest way to go for UA signalling. I can model a BIP after BIP9, withsome discussion of how to properly collect statistics, and the ability fornodes to activate features based on an "economic majority" defined in thisway.On Tue, Apr 18, 2017 at 6:29 PM, Tim Ruffing via bitcoin-dev <

Post by Tim Ruffing via bitcoin-devI 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 thishas privacy implications. For example, it makes it much easier to linkthe addresses, e.g., inputs with change address. (The change addressvotes for the same proposal as the input address.)TimOn Tue, 2017-04-18 at 18:07 +0000, Christian Decker via bitcoin-dev

Post by Christian Decker via bitcoin-devI really like the idea of extending signalling capabilities to theend-users. It gives stakeholders a voice in the decisions we take inthe network, and are a clear signal to all other involved parties. Itreminds me of a student thesis I supervised some time ago [1], inwhich we explored various signalling ideas.I think we have a number of fields that may be used for such asignalling, e.g., OP_RETURN, locktime, and output scripts. I thinkOP_RETURN is probably not the field you'd want to use though since itadds data that needs to be transferred, stored for bootstrap, andoutputs in the UTXO would need to be tagged with additionalinformation. Locktime has the advantage of being mostly a freeformfield for values in the past, but it clashes with other uses that mayrely on it. Furthermore, it is the transaction creator that specifiesthe locktime, hence the signal trails one hop behind the currentowner, i.e., the actual stakeholder.I think probably the best field to signal would be the outputscript. It is specified by the recipient of the funds, i.e., thecurrent owner, and is already stored in the UTXO, so a single pass cantally up the votes. We could for example use the last 4 bits of thepubkey/pubkeyhash to opt in (3 leading 0 bits) and the vote (0/1depending on the stakeholders desired signal). We'd need to definesimilar semantics for other script types, but getting the standardscripts to be recognized should be simple.In the spirit of full disclosure I'd like to also mention some of thedownsides of voting this way. Unlike the OP_RETURN proposal, usersthat do not intend to signal will also be included in the tally. I'dexpect the signals of these users to be random with a 50% chance ofeither outcome, so they should not influence the final result, but maymuddy the water depending on what part of the population issignalling. The opt-in should make sure that the majority of votes areactually voluntary votes, and not just users that randomly select apubkey/pubkeyhash, and can be adjusted as desired, though highervalues require more grinding on behalf of the users.The grinding may also exacerbate some problems we already have withthe HD Wallet lookahead, since we now skip a number of addresses, sowe should not require too many opt-in bits.So there are some problems we'd need to tackle, but I'm really excitedabout this, as it could provide data to make informed decisions, andshould put an end to the endless speculation about the will of theeconomic majority.Cheers,Christian[1] http://pub.tik.ee.ethz.ch/students/2015-HS/SA-2015-30.pdf_______________________________________________bitcoin-dev mailing listhttps://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev