path: root/b3/58729c956ee47762f4f7911864dabbbdd6c3f8

Return-Path: <natanael.l@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 39FE9BC4
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 22:53:11 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-la0-f53.google.com (mail-la0-f53.google.com
	[209.85.215.53])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9817221E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 22:53:09 +0000 (UTC)
Received: by lagx9 with SMTP id x9so89982037lag.1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 15:53:07 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113;
	h=mime-version:in-reply-to:references:date:message-id:subject:from:to
	:content-type; bh=CnnqMVoUhnmml/1vdh3d2g/L8WJLtORFj5c8Y3dd7n4=;
	b=vnmhquC3fRXYK5AlBtItuL1uc+GYL27ffQ3nve5vo/xfGlFtOtu44l1AeOD2eI3Upa
	R968+AZsvqepDQsjWGfP+naO+AU9nquIujP63Skh6boMUcnd/FYSzeax1nDyAJI2w9bc
	s87buJMHyYN02bWsVb2qJ5dcyjfPRp+mjs7YYIhlZzHVWjJTZkNScyYXrslLK61BdVNm
	KcLNxinlLyrMibttaCKgQSL/t+KZNMrWdRaMhCH40dxVZcblbK041Ih3gb3LESEaN534
	v9wKI3seADtLyC32t9zNTqWa4S/gswbHv5k59hL9UlWr3wTxxQU9X5609/A7bkHVIs6B
	1riA==
MIME-Version: 1.0
X-Received: by 10.112.168.102 with SMTP id zv6mr7633347lbb.45.1435445587469;
	Sat, 27 Jun 2015 15:53:07 -0700 (PDT)
Received: by 10.114.184.175 with HTTP; Sat, 27 Jun 2015 15:53:07 -0700 (PDT)
Received: by 10.114.184.175 with HTTP; Sat, 27 Jun 2015 15:53:07 -0700 (PDT)
In-Reply-To: <CAAt2M1-cRNBr9SAOCDEKm8C8GzOMRtY4JprwYk9y8w4xVqgWYw@mail.gmail.com>
References: <CAAt2M1-cRNBr9SAOCDEKm8C8GzOMRtY4JprwYk9y8w4xVqgWYw@mail.gmail.com>
Date: Sun, 28 Jun 2015 00:53:07 +0200
Message-ID: <CAAt2M1_ijqnARvh5UHhmtCGRKyMY1VwbP=3ms7a8OkfsrQm-EA@mail.gmail.com>
From: Natanael <natanael.l@gmail.com>
To: bitcoin-dev@lists.linuxfoundation.org
Content-Type: multipart/alternative; boundary=001a11c33d3255ecd7051987b868
X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_LOW
	autolearn=ham version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
Subject: [bitcoin-dev] Outroduction of old non-updated full nodes through
 graceful degradation to SPV mode
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
	<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Sat, 27 Jun 2015 22:53:11 -0000

--001a11c33d3255ecd7051987b868
Content-Type: text/plain; charset=UTF-8

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

--001a11c33d3255ecd7051987b868
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<p dir=3D"ltr">Old versions of software that can&#39;t be sandboxed from th=
e world by design must eventually die. The reason is simple - otherwise it =
will be abused, exploited and end up actively countering its own intended p=
urpose. Either through security holes or other means of abusing the outdate=
d code&#39;s behavior. </p>
<p dir=3D"ltr">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&#39;t perfect - thi=
s will toss incompatible old full nodes off the greatest-PoW blockchain. Th=
is is inevitable - not all instances of the software will get updated. Scan=
ning the Internet for Internet accessible hardware will reveal tons of outd=
ated software versions. </p>
<p dir=3D"ltr">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&#39;m suggesting beh=
aviors that would simplify transition to new versions over time with minima=
l disruption. </p>
<p dir=3D"ltr">* Expiration dates. Nodes so old that they are behind by num=
erous soft forks and likely are to be deprecated by a hard fork should swit=
ch to SPV mode automatically while also alerting the node owner. This behav=
ior extends the lifetime while not by itself breaking anything with minimal=
 disruption. It also allows node owners which look at the status of their n=
odes but don&#39;t think of updating (maybe it is automatically deployed ol=
d software images) to realize an update is sin necessary. SPV mode also nee=
ds to have an expiration date before complete node shutdown. Expiration dat=
es 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 rea=
sonable default IMHO, with node shutdown after 5 years. Any other suggestio=
ns? </p>
<p dir=3D"ltr">* Explicit declaration of block policy / rules in blocks, in=
cluding miner votes for changes, and explicit declaration of incompatibilit=
y with old versions. Having votes visible in the blocks for implementing ch=
anges incompatible with the policy and rules your node runs allows it to al=
ert the node owner of impending necessity to update. Switching to SPV mode =
again provides for minimal disruption. Please take note that even old SPV n=
odes may eventually be deprecated through data structure changes, this too =
should be declared and then cause alerts and halt / shutdown of those nodes=
. </p>
<p dir=3D"ltr">This also protects against another issue - an old abandoned =
node will not automatically trust a fresh longer chain (likely malicious) u=
sing its own policy if it remembers an earlier fork voting for change, inst=
ead 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 o=
wn 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 jus=
t 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 sim=
ply logged. </p>
<p dir=3D"ltr">Seeing a block also explicitly declare being incompatible wi=
th the policy a node follows including for SPV nodes, rather than just usin=
g version numbers, simplifies things too. It ensures the nodes know they ca=
n&#39;t validate the blocks with their old code, which simultaneously ensur=
es that behavior changes that doesn&#39;t violate the old validation code b=
ut yet causes incompatibility then will not silently fork the network, inst=
ead it will let the node owners know their nodes are incompatible with the =
main chain. This allows them to investigate and update of necessary.</p>
<p dir=3D"ltr">---</p>
<p dir=3D"ltr">The primary reason for me suggesting switching to SPV mode i=
s simple - it buys time for everybody. Hard forks no longer become a critic=
al deadline for getting the ENTIRE network upgraded - you just need to worr=
y about the miners and major players in the short term. Long term you do ne=
ed information campaigns to get SPV fallback nodes updated, but it won&#39;=
t need to be rushed. The information campaigns no longer need to be FULLY c=
ompleted BEFORE deployment. </p>
<p dir=3D"ltr">Feedback? </p>
<p dir=3D"ltr">- Sent from my tablet</p>

--001a11c33d3255ecd7051987b868--