From b82dc80a989d48e73bda642f043d04fb4499a90d Mon Sep 17 00:00:00 2001
From: Anthony Towns <aj@erisian.com.au>
Date: Thu, 8 Oct 2015 01:00:14 +1000
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

---
 72/b51cc96e500b900bcbcca15ffd83f6527cd387 | 172 ++++++++++++++++++++++++++++++
 1 file changed, 172 insertions(+)
 create mode 100644 72/b51cc96e500b900bcbcca15ffd83f6527cd387

diff --git a/72/b51cc96e500b900bcbcca15ffd83f6527cd387 b/72/b51cc96e500b900bcbcca15ffd83f6527cd387
new file mode 100644
index 000000000..82d172464
--- /dev/null
+++ b/72/b51cc96e500b900bcbcca15ffd83f6527cd387
@@ -0,0 +1,172 @@
+Return-Path: <aj@erisian.com.au>
+Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
+	[172.17.192.35])
+	by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CC651B8C
+	for <bitcoin-dev@lists.linuxfoundation.org>;
+	Wed,  7 Oct 2015 15:00:22 +0000 (UTC)
+X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
+Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212])
+	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 7523211A
+	for <bitcoin-dev@lists.linuxfoundation.org>;
+	Wed,  7 Oct 2015 15:00:21 +0000 (UTC)
+Received: from aj@azure.erisian.com.au (helo=navy.erisian.com.au)
+	by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian))
+	id 1ZjqCX-0003Sq-Ii for <bitcoin-dev@lists.linuxfoundation.org>;
+	Thu, 08 Oct 2015 01:00:19 +1000
+Received: by navy.erisian.com.au (sSMTP sendmail emulation);
+	Thu, 08 Oct 2015 01:00:14 +1000
+Date: Thu, 8 Oct 2015 01:00:14 +1000
+From: Anthony Towns <aj@erisian.com.au>
+To: bitcoin-dev@lists.linuxfoundation.org
+Message-ID: <20151007150014.GA21849@navy>
+References: <20150927185031.GA20599@savin.petertodd.org>
+	<CA+w+GKRCVr-9TVk66utp7xLRgTxNpxYoj3XQE-6y_N8JS6eO6Q@mail.gmail.com>
+	<CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
+MIME-Version: 1.0
+Content-Type: text/plain; charset=us-ascii
+Content-Disposition: inline
+In-Reply-To: <CAAS2fgSEDGBd67m7i8zCgNRqtmQrZyZMj7a5TsYo41Dh=tdhHQ@mail.gmail.com>
+User-Agent: Mutt/1.5.24 (2015-08-30)
+X-Spam-Score: -1.9
+X-Spam-Score-int: -18
+X-Spam-Bar: -
+X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD,
+	UNPARSEABLE_RELAY autolearn=ham version=3.3.1
+X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
+	smtp1.linux-foundation.org
+Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
+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: Wed, 07 Oct 2015 15:00:22 -0000
+
+On Tue, Sep 29, 2015 at 06:31:28PM +0000, Gregory Maxwell via bitcoin-dev wrote:
+> On Mon, Sep 28, 2015 at 10:48 AM, Mike Hearn via bitcoin-dev
+> <bitcoin-dev@lists.linuxfoundation.org> wrote:
+> > There is no consensus on using a soft fork to deploy this feature. It will
+> > result in the same problems as all the other soft forks - SPV wallets will
+> > become less reliable during the rollout period. I am against that, as it's
+> > entirely avoidable.
+> > Make it a hard fork and my objection will be dropped.
+> I'm surprised to see this response-- [...]
+> I am having a little difficulty making sense of this complaint. [...]
+
+I think I finally understand this objection.
+
+For a hard fork, activated by a majority of nodes/hashpower upgrading
+to a new bitcoin release, the behaviour is:
+
+ - upgraded bitcoin nodes: everything works fine
+
+ - non-upgraded bitcoin nodes: total breakage. there will be a push
+   alert telling you to upgrade. anyone who doesn't will think they're
+   tracking "bitcoin" but will actually be tracking a new "bitcoin-old"
+   altcoin. most non-upgraded miners will presumably realise they're
+   wasting hashpower and stop doing this pretty quick; and remaining
+   miners will only create blocks very slowly due to sudden reduced
+   hashpower, without possibility of difficulty adjustment. users who
+   don't uprade will try to do transactions, but won't see them confirm
+   for hours or days due to lack of hashpower.
+
+ - SPV nodes: they track the upgraded majority, everything works fine
+   even if they don't upgrade
+
+For a soft fork, again activated by the majority of upgraded hashpower,
+the behaviour is:
+
+ - upgraded bitcoin nodes: everything works fine
+
+ - non-upgraded bitcoin miners willing to mine newly unacceptable txs:
+   may produce orphaned blocks; may be able to be forced into producing
+   blocks that will be orphaned
+
+ - other non-upgraded bitcoin nodes: everything works fine
+
+ - SPV nodes: partial breakage -- may track invalid blocks for 1-2
+   confirmations until the set of "non-upgraded bitcoin miners willing
+   to produce newly unacceptable txs" becomes vanishingly few.
+
+In the hard fork case, all non-upgraded nodes get a DoS attack, but
+aren't likey to be hit by doublespends. That's inconvenient, but it's
+not too bad.
+
+In the soft fork case, if there's likely to be old nodes mining
+previously invalid transactions, SPV clients become very unreliable,
+to the point of possibly seeing semi-regular double-spends with 1 or
+2 confirmation, until miners that aren't paying attention notice their
+blocks are getting orphaned and upgrade. That is pretty bad IMHO; and
+there are a lot more *people* running SPV clients than bitcoin nodes,
+so its impact is potentially worse in both ways.
+
+Comparing generic hard forks versus generic soft forks, the above says
+to me that a hard fork would be less harmful to users in general, and
+thus a better approach.
+
+*But* a soft fork that only forbids transactions that would previously
+not have been mined anyway should be the best of both worlds, as it
+automatically reduces the liklihood of old miners building newly invalid
+blocks to a vanishingly small probability; which means that upgraded
+bitcoin nodes, non-upgraded bitcoin nodes, /and/ SPV clients *all*
+continuing to work fine during the upgrade.
+
+AFAICS, that's what BIP65 achieves, as will similar OP_NOP* replacements
+like BIP112.
+
+But that only applies to a subset of potential soft forks, not every
+soft fork.
+
+Maybe a good way to think about it is something like this.  Consensus
+(IsValid) is always less restrictive than (default) policy (previously
+IsStandard, not sure how to summarise it now, maybe it's just OP_NOP
+redefinition?).  So choosing a new consensus rule will be one of:
+
+  * even less restrictive than consensus (hard fork)
+
+  * more restrictive than consensus, but less restrictive than policy
+    (safe soft fork)
+
+  * more restrictive than IsStandard etc (damaging soft fork)
+
+Hmm, in particular, following this line of thinking it's not clear to
+me that BIP68 is actually less restrictive than current policy? At
+least, I can't see anything that prevents txs with nSequence set to
+something other than 0 or ~0 from being relayed?
+
+If it's not, and nodes currently happily mine and relay transactions
+with nSequence set without caring what it's set to, doesn't this mean
+BIP68 is of the "damaging soft fork" variety? That is, if it activated
+as a soft-fork with a majority of miners using it, but a minority of ~5%
+not upgraded, then
+
+ - someone could construct an tx with nSequence set to sometime in
+   the future, but not using OP_CSV
+
+ - this tx would get relayed by old nodes (but not upgraded nodes
+   due to CheckLockTime)
+
+ - non-upgraded miners would mine it into a block immediately, which
+   would then get orphaned by majority hashpower
+
+ - before it got orphaned, non-upgraded nodes and SPV clients would
+   be misled and vulnerable to double spend attacks of txs with 0, 1 or
+   maybe 2 confirmations
+
+(BIP65 with OP_CLTV and BIP112 with OP_CSV don't have that problem as
+they both redefine a non-standard opcode and would not get relayed or
+mined by old, non-upgraded nodes, and are thus "safe soft forks" per
+above terminology. This is just BIP68)
+
+Can anyone confirm or refute the above?
+
+Cheers,
+aj
+
+
-- 
cgit v1.2.3