[bitcoin-dev] Outroduction of old non-updated full nodes through graceful degradation to SPV mode

[bitcoin-dev] Outroduction of old non-updated full nodes through graceful degradation to SPV mode

[Natanael]

[-- Attachment #1: Type: text/plain, Size: 4195 bytes --]

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

[-- Attachment #2: Type: text/html, Size: 4423 bytes --]

Re: [bitcoin-dev] Outroduction of old non-updated full nodes through graceful degradation to SPV mode

[Jeff Garzik]

[-- Attachment #1: Type: text/plain, Size: 4798 bytes --]

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@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@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 5383 bytes --]