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 39C471A42 for ; Mon, 28 Sep 2015 14:17:08 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f173.google.com (mail-io0-f173.google.com [209.85.223.173]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id AF64D1A0 for ; Mon, 28 Sep 2015 14:17:07 +0000 (UTC) Received: by ioiz6 with SMTP id z6so175825433ioi.2 for ; Mon, 28 Sep 2015 07:17:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=vinumeris.com; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=RjiM/jz0BASZP64YrAJ5kLmHUtmkhClOjsPvLMu31GE=; b=fk9inRsTAj2ysfTVqZGkgq1TOvcZrSNKvHLhzZposQrhz3lOVVrlGFbmM4GPytMbxA 7aeOFsDtAmKBWXpAoPv+yeAof98wR/pZ+B09paAtnPoO1v2WpSslRobz28v5lns57aKX oQhruyGbXCKR8FTYDtEP1t+RkBOx/UQVeflXs= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=RjiM/jz0BASZP64YrAJ5kLmHUtmkhClOjsPvLMu31GE=; b=UEAMUIAnAQLKwIV0HKrBu9zP0yYnWVNF5pCSdr/xGUiDfBQr2heBn86FStjcqMV7ED luMh9/WuZE7GKDA9yIZZhaRh/BxKqblnec7K0boOulg2qqnKLPR0wJz4SKfxCvF536IT 8RYut9tbqwOSlCLle/WPKfgxbwgcAgdHsofjq31WL0k7+/gO4CdTzjsKSsrcqegkjxud gTxjlIRQKFgZoNk2OcAVCckylsuzBAXjTSKyuk73WKtl05qlM9grMfeE8n2bs9TZegLp k2i9exdM6vpke1C+i+5SI7cXw3g3jsrIzM+M4s2XQaJxWzB4XHX/iWMcIoks1h0tZ/L1 l5YQ== X-Gm-Message-State: ALoCoQkzAeYvU4gbPMJU1qBAZKGeTKzl8A27Sd4d31UUW1AIIx1UWnUb/C9zCua1pnK2I/7RVJPw MIME-Version: 1.0 X-Received: by 10.107.137.144 with SMTP id t16mr19757881ioi.102.1443449826977; Mon, 28 Sep 2015 07:17:06 -0700 (PDT) Received: by 10.50.226.144 with HTTP; Mon, 28 Sep 2015 07:17:06 -0700 (PDT) In-Reply-To: References: <20150927185031.GA20599@savin.petertodd.org> Date: Mon, 28 Sep 2015 16:17:06 +0200 Message-ID: From: Mike Hearn To: Btc Drak Content-Type: multipart/alternative; boundary=001a113fb1e430579d0520cf5abb X-Spam-Status: No, score=-2.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,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 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: Mon, 28 Sep 2015 14:17:08 -0000 --001a113fb1e430579d0520cf5abb Content-Type: text/plain; charset=UTF-8 > > 2. As for SPV wallets need to handle awareness of the new blocks. > There is simply no need for any wallets to change. Making the spec a hard fork instead of a soft fork means all existing software does the right thing automatically. To repeat, please bear in mind that bitcoinj is no longer the only SPV wallet implementation. BreadWallet has its own code in Objective-C and is the second most popular SPV implementation (and growing). Additionally, bitcoinj is incorporated into lots of apps that'd have to have new versions released, some of which don't have any way to force a user to update. So it's not just my time you'd waste: it's lots of different people's. One thing I haven't seen yet is the justification for why a soft fork should be used here. There's no requirement that it be so, and there are real downsides. As Eric said, the fact that the mechanism has issues is not under dispute. The normal justification for this it's that it's forwards compatible. But that's not a justification, that's a description. Re: XT, I already addressed this above. --001a113fb1e430579d0520cf5abb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
2. As for SPV wallets need to handle awareness of th= e new blocks.

There i= s simply no need for any wallets to change. Making the spec a hard fork ins= tead of a soft fork means all existing software does the right thing automa= tically.

To repeat, please bear in mind that bitco= inj is no longer the only SPV wallet implementation. BreadWallet has its ow= n code in Objective-C and is the second most popular SPV implementation (an= d growing). Additionally, bitcoinj is incorporated into lots of apps that&#= 39;d have to have new versions released, some of which don't have any w= ay to force a user to update.

So it's not just= my time you'd waste: it's lots of different people's.

One thing I haven't seen yet is the justification for = why a soft fork should be used here. There's no requirement that it be = so, and there are real downsides. As Eric said, the fact that the mechanism= has issues is not under dispute.

The normal justi= fication for this it's that it's forwards compatible. But that'= s not a justification, that's a description.
=C2=A0
Re: XT, I already addressed this above.
--001a113fb1e430579d0520cf5abb--