path: root/a5/72ce13f9d5382fc51c06ffb6aaac8459ccbb46

Return-Path: <jgarzik@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 89742BC7
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 23:57:03 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 31EFEF2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 23:57:02 +0000 (UTC)
Received: by wgjx7 with SMTP id x7so41017838wgj.2
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Sat, 27 Jun 2015 16:57:00 -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
	:cc:content-type;
	bh=rOP2KwKLWaQcn8uzaRMkRkMBpPojL22BKuF/jZDSTkU=;
	b=q2qBfLUau5bbNZKWj99dgPgb1byJvJyXrkSB+kqxiC6tcwZNrVB0gGCqSIWxw/4zew
	bzirilDpG/4gLWuoqal0Ue9PgwsPa4NHcCPwxQ4bWE3s6gwdxJYlBSI+nNJmk0WLU0q9
	BsVAT8IkoI8tb/0xHnanYP+Jo1pCrN2OOyXJ6DKvz34toIqMcka7dPGGEASxjhl0fgpZ
	1LUp4hA9awJxCzmeb2ab5Qin/MbMUsQ4GPMa/irMQl0WCDUz6ujvYUZvcyALApzzhaYQ
	7BcqA8QN/k1M/Y8k8OUli6VvIfeFnlWWKYr/LT97QEfXtQmdKCELw9AsHoBugxNfd+Tx
	tfYA==
MIME-Version: 1.0
X-Received: by 10.194.176.201 with SMTP id ck9mr15628130wjc.108.1435449420899; 
	Sat, 27 Jun 2015 16:57:00 -0700 (PDT)
Received: by 10.28.140.196 with HTTP; Sat, 27 Jun 2015 16:57:00 -0700 (PDT)
In-Reply-To: <CAAt2M1_ijqnARvh5UHhmtCGRKyMY1VwbP=3ms7a8OkfsrQm-EA@mail.gmail.com>
References: <CAAt2M1-cRNBr9SAOCDEKm8C8GzOMRtY4JprwYk9y8w4xVqgWYw@mail.gmail.com>
	<CAAt2M1_ijqnARvh5UHhmtCGRKyMY1VwbP=3ms7a8OkfsrQm-EA@mail.gmail.com>
Date: Sat, 27 Jun 2015 16:57:00 -0700
Message-ID: <CADm_WcYyKHNzgJhZkkn=90Nc863c88UAoQ0LptgOY=a5GiEojQ@mail.gmail.com>
From: Jeff Garzik <jgarzik@gmail.com>
To: Natanael <natanael.l@gmail.com>
Content-Type: multipart/alternative; boundary=089e013d1eb4d36c3a0519889c61
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
Cc: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [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 23:57:03 -0000

--089e013d1eb4d36c3a0519889c61
Content-Type: text/plain; charset=UTF-8

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
>
>

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

<div dir=3D"ltr">Older nodes have been phased out in the past.=C2=A0 For ex=
ample, protocol versions older than 209 were phased out.<br><br>Follow the =
yellow brick git trail starting at 18c0fa97d0408a3ee8e4cb39c08156f7667f99ac=
<div><br></div></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo=
te">On Sat, Jun 27, 2015 at 3:53 PM, Natanael <span dir=3D"ltr">&lt;<a href=
=3D"mailto:natanael.l@gmail.com" target=3D"_blank">natanael.l@gmail.com</a>=
&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0=
 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir=3D"ltr">Old ver=
sions of software that can&#39;t be sandboxed from the world by design must=
 eventually die. The reason is simple - otherwise it will be abused, exploi=
ted and end up actively countering its own intended purpose. Either through=
 security holes or other means of abusing the outdated 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>
<br>_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
<br></blockquote></div><br></div>

--089e013d1eb4d36c3a0519889c61--