Discussion:
Transaction signalling
Add Reply
Erik Aronesty via bitcoin-dev
2017-04-17 15:50:51 UTC
Reply
Permalink
Raw Message
If users added a signal to OP_RETURN, might it be possible to tag all
validated input addresses with that signal.

Then a node can activate a new feature after the percentage of tagged input
addresses reaches a certain level within a certain period of time?

This could be used in addition to a flag day to trigger activation of a
feature with some reassurance of user uptake.
Marcel Jamin via bitcoin-dev
2017-04-18 14:52:04 UTC
Reply
Permalink
Raw Message
Probably a bad idea for various reasons, but tagging (fee paying)
transactions with info about the capabilities of the node that created
it might be interesting? Might be useful to gauge economic support for
certain upgrades, especially if excluding long transaction chains,
etc. In the very least it would be a far better indicator than simply
counting reachable nodes.

On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
If users added a signal to OP_RETURN, might it be possible to tag all
validated input addresses with that signal.
Then a node can activate a new feature after the percentage of tagged input
addresses reaches a certain level within a certain period of time?
This could be used in addition to a flag day to trigger activation of a
feature with some reassurance of user uptake.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2017-04-18 18:01:52 UTC
Reply
Permalink
Raw Message
Just to be clear, the tagging would occur on the addresses, and the
weighting would be by value, so it's a measure of economic significance.
Major exchanges will regularly tag massive amounts of Bitcoins with their
capabilities.

Just adding a nice bit-field and a tagging standard, and then charting it
might be enough to "think about how to use it later". The only problem
would 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 economically
meaningful 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 an
alternative to BIP9 for a user-coordinated code release - especially in
situations where miners have rejected activation of a widely-regarded
proposal. Suppose also, in that future, colored coin ICO's that use
op-return are regularly used to float the shares of major corporation. It
might be irresponsible to exclude them from coordinating protocol changes.)
Post by Marcel Jamin via bitcoin-dev
Probably a bad idea for various reasons, but tagging (fee paying)
transactions with info about the capabilities of the node that created
it might be interesting? Might be useful to gauge economic support for
certain upgrades, especially if excluding long transaction chains,
etc. In the very least it would be a far better indicator than simply
counting reachable nodes.
On 17 April 2017 at 17:50, Erik Aronesty via bitcoin-dev
Post by Erik Aronesty via bitcoin-dev
If users added a signal to OP_RETURN, might it be possible to tag all
validated 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-dev
addresses reaches a certain level within a certain period of time?
This could be used in addition to a flag day to trigger activation of a
feature with some reassurance of user uptake.
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Christian Decker via bitcoin-dev
2017-04-18 18:07:25 UTC
Reply
Permalink
Raw Message
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
Tim Ruffing via bitcoin-dev
2017-04-18 22:29:17 UTC
Reply
Permalink
Raw Message
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
Post by Christian Decker via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Erik Aronesty via bitcoin-dev
2017-04-20 16:14:18 UTC
Reply
Permalink
Raw Message
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.

On Tue, Apr 18, 2017 at 6:29 PM, Tim Ruffing via bitcoin-dev <
Post by Tim Ruffing via bitcoin-dev
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
Post by Christian Decker via bitcoin-dev
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
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
_______________________________________________
bitcoin-dev mailing list
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Loading...