BIP : User activated features (ROUGH OVERVIEW)
A proposed change to a usage of the 'OP_RETURN' script opcode in Bitcoin
transactions, allowing multiple changes (features) to be deployed in
parallel. It relies on interpreting the output field as a bit vector, where
each bit can be used to trac
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.
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
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 s
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 chartin
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 i
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
Instead of using vanity addresses, the transactions could just use an
OP_RETURN output and express the signalling there.
However, such a system could be easily gamed by people who simply spam
the network with transactions and by miners who choose what transactions
to include in their blocks.
On
Den 5 feb. 2017 16:33 skrev "John Hardy via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org>:
Currently in order to signal support for changes to Bitcoin, only miners
are able to do so on the blockchain through BIP9.
One criticism is that the rest of the community is not able to participate
Currently in order to signal support for changes to Bitcoin, only miners are
able to do so on the blockchain through BIP9.
One criticism is that the rest of the community is not able to participate in
consensus, and other methods of assessing community support are fuzzy and
easily manipulated
10 matches
Mail list logo
