From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 5CC651B8C for ; 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 ; 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 ; 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 To: bitcoin-dev@lists.linuxfoundation.org Message-ID: <20151007150014.GA21849@navy> References: <20150927185031.GA20599@savin.petertodd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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 > 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