Doing this would place trust in those who are writing code of node software. It would also centralize control of Bitcoin.
The reason why a new version of node software would be released is because features were added and/or rules were changed (validation rules). If someone doesn't agree with these changes then they would likely not upgrade (although they may upgrade for other reasons). I held off upgrading my node for many months because I did not agree with RBF features added to then-most recent version of core, and even went as far as to use alternate implementations of Bitcoin software.
Some people argue that the current development team should be releaved of their duties of writing Bitcoin software. Your proposal would make this impossible, or nearly impossible.
Topic: Node signaling and auto upgrade; Possible incentivization? (Read 420 times)
I don't know if this has been addressed, I'd like to find a node focused channel / forum ideally. . Anyway...
What I want to achieve is auto update of nodes to current software.
A master node you trust uses an encrypted hash/string (signed, verified - not sure of the proper term) UA comment and other nodes that trust this node run the update command bringing them up to date if the UA comment is valid.
I'm really interested in distributed networks and torrent like communication.
Perhaps this could be a way of incentivizing full nodes? The verification and distribution of the node software itself.
What I want to achieve is auto update of nodes to current software.
A master node you trust uses an encrypted hash/string (signed, verified - not sure of the proper term) UA comment and other nodes that trust this node run the update command bringing them up to date if the UA comment is valid.
I'm really interested in distributed networks and torrent like communication.
Perhaps this could be a way of incentivizing full nodes? The verification and distribution of the node software itself.
Jump to: