Natanael [ARCHIVE] on Nostr: 📅 Original date posted:2015-06-27 📝 Original message:Old versions of software ...
📅 Original date posted:2015-06-27
📝 Original message:Old versions of software that can't be sandboxed from the world by design
must eventually die. The reason is simple - otherwise it will be abused,
exploited and end up actively countering its own intended purpose. Either
through security holes or other means of abusing the outdated code's
behavior.
Full nodes in Bitcoin validate all new transactions against their own
embedded policies and rules. Eventually the global concensus will agree on
a change of rules, as the current ruleset isn't perfect - this will toss
incompatible old full nodes off the greatest-PoW blockchain. This is
inevitable - not all instances of the software will get updated. Scanning
the Internet for Internet accessible hardware will reveal tons of outdated
software versions.
There is however currently no simple way to tell a node that it is
outdated. Even if you just incremented block versions, it will only lead to
some kind of alert (IIRC) for some versions. I'm suggesting behaviors that
would simplify transition to new versions over time with minimal
disruption.
* Expiration dates. Nodes so old that they are behind by numerous soft
forks and likely are to be deprecated by a hard fork should switch to SPV
mode automatically while also alerting the node owner. This behavior
extends the lifetime while not by itself breaking anything with minimal
disruption. It also allows node owners which look at the status of their
nodes but don't think of updating (maybe it is automatically deployed old
software images) to realize an update is sin necessary. SPV mode also needs
to have an expiration date before complete node shutdown. Expiration dates
also minimize risk for political disagreement regarding how and when to
take any manual action to trigger necessary alerts. 3 years to SPV is a
reasonable default IMHO, with node shutdown after 5 years. Any other
suggestions?
* Explicit declaration of block policy / rules in blocks, including miner
votes for changes, and explicit declaration of incompatibility with old
versions. Having votes visible in the blocks for implementing changes
incompatible with the policy and rules your node runs allows it to alert
the node owner of impending necessity to update. Switching to SPV mode
again provides for minimal disruption. Please take note that even old SPV
nodes may eventually be deprecated through data structure changes, this too
should be declared and then cause alerts and halt / shutdown of those
nodes.
This also protects against another issue - an old abandoned node will not
automatically trust a fresh longer chain (likely malicious) using its own
policy if it remembers an earlier fork voting for change, instead it
prompts for the node owner to either update (or stick to SPV on the
new-policy chain) or to accept this fresh fork. Nodes on a chain with its
own policy seeing a fork with a vote for change should look at the PoW
first. If it is close, alert the user (he might have brought the node
online just after the vote finished, to first see the fork that is on his
old policy), so he can investigate. If the PoW is far behind it may be
ignored, or simply logged.
Seeing a block also explicitly declare being incompatible with the policy a
node follows including for SPV nodes, rather than just using version
numbers, simplifies things too. It ensures the nodes know they can't
validate the blocks with their old code, which simultaneously ensures that
behavior changes that doesn't violate the old validation code but yet
causes incompatibility then will not silently fork the network, instead it
will let the node owners know their nodes are incompatible with the main
chain. This allows them to investigate and update of necessary.
---
The primary reason for me suggesting switching to SPV mode is simple - it
buys time for everybody. Hard forks no longer become a critical deadline
for getting the ENTIRE network upgraded - you just need to worry about the
miners and major players in the short term. Long term you do need
information campaigns to get SPV fallback nodes updated, but it won't need
to be rushed. The information campaigns no longer need to be FULLY
completed BEFORE deployment.
Feedback?
- Sent from my tablet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/e38a4379/attachment.html>;
📝 Original message:Old versions of software that can't be sandboxed from the world by design
must eventually die. The reason is simple - otherwise it will be abused,
exploited and end up actively countering its own intended purpose. Either
through security holes or other means of abusing the outdated code's
behavior.
Full nodes in Bitcoin validate all new transactions against their own
embedded policies and rules. Eventually the global concensus will agree on
a change of rules, as the current ruleset isn't perfect - this will toss
incompatible old full nodes off the greatest-PoW blockchain. This is
inevitable - not all instances of the software will get updated. Scanning
the Internet for Internet accessible hardware will reveal tons of outdated
software versions.
There is however currently no simple way to tell a node that it is
outdated. Even if you just incremented block versions, it will only lead to
some kind of alert (IIRC) for some versions. I'm suggesting behaviors that
would simplify transition to new versions over time with minimal
disruption.
* Expiration dates. Nodes so old that they are behind by numerous soft
forks and likely are to be deprecated by a hard fork should switch to SPV
mode automatically while also alerting the node owner. This behavior
extends the lifetime while not by itself breaking anything with minimal
disruption. It also allows node owners which look at the status of their
nodes but don't think of updating (maybe it is automatically deployed old
software images) to realize an update is sin necessary. SPV mode also needs
to have an expiration date before complete node shutdown. Expiration dates
also minimize risk for political disagreement regarding how and when to
take any manual action to trigger necessary alerts. 3 years to SPV is a
reasonable default IMHO, with node shutdown after 5 years. Any other
suggestions?
* Explicit declaration of block policy / rules in blocks, including miner
votes for changes, and explicit declaration of incompatibility with old
versions. Having votes visible in the blocks for implementing changes
incompatible with the policy and rules your node runs allows it to alert
the node owner of impending necessity to update. Switching to SPV mode
again provides for minimal disruption. Please take note that even old SPV
nodes may eventually be deprecated through data structure changes, this too
should be declared and then cause alerts and halt / shutdown of those
nodes.
This also protects against another issue - an old abandoned node will not
automatically trust a fresh longer chain (likely malicious) using its own
policy if it remembers an earlier fork voting for change, instead it
prompts for the node owner to either update (or stick to SPV on the
new-policy chain) or to accept this fresh fork. Nodes on a chain with its
own policy seeing a fork with a vote for change should look at the PoW
first. If it is close, alert the user (he might have brought the node
online just after the vote finished, to first see the fork that is on his
old policy), so he can investigate. If the PoW is far behind it may be
ignored, or simply logged.
Seeing a block also explicitly declare being incompatible with the policy a
node follows including for SPV nodes, rather than just using version
numbers, simplifies things too. It ensures the nodes know they can't
validate the blocks with their old code, which simultaneously ensures that
behavior changes that doesn't violate the old validation code but yet
causes incompatibility then will not silently fork the network, instead it
will let the node owners know their nodes are incompatible with the main
chain. This allows them to investigate and update of necessary.
---
The primary reason for me suggesting switching to SPV mode is simple - it
buys time for everybody. Hard forks no longer become a critical deadline
for getting the ENTIRE network upgraded - you just need to worry about the
miners and major players in the short term. Long term you do need
information campaigns to get SPV fallback nodes updated, but it won't need
to be rushed. The information campaigns no longer need to be FULLY
completed BEFORE deployment.
Feedback?
- Sent from my tablet
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150628/e38a4379/attachment.html>;