Jeff Garzik [ARCHIVE] on Nostr: š Original date posted:2015-06-27 š Original message:Older nodes have been ...
š
Original date posted:2015-06-27
š Original message:Older nodes have been phased out in the past. For example, protocol
versions older than 209 were phased out.
Follow the yellow brick git trail starting at
18c0fa97d0408a3ee8e4cb39c08156f7667f99ac
On Sat, Jun 27, 2015 at 3:53 PM, Natanael <natanael.l at gmail.com> wrote:
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/7af5b0ef/attachment.html>;
š Original message:Older nodes have been phased out in the past. For example, protocol
versions older than 209 were phased out.
Follow the yellow brick git trail starting at
18c0fa97d0408a3ee8e4cb39c08156f7667f99ac
On Sat, Jun 27, 2015 at 3:53 PM, Natanael <natanael.l at gmail.com> wrote:
> 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
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150627/7af5b0ef/attachment.html>;