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 777561721 for ; Mon, 5 Oct 2015 12:08:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-qg0-f49.google.com (mail-qg0-f49.google.com [209.85.192.49]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id E7FE61A6 for ; Mon, 5 Oct 2015 12:08:37 +0000 (UTC) Received: by qgev79 with SMTP id v79so146757632qge.0 for ; Mon, 05 Oct 2015 05:08:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-type; bh=CIS/nn39HjrxDMPo5HWeajGkHGOpUUOKoLR0oYl3xeE=; b=lZhhqNql8tqpoPin49LW6iFqCZQ3GdIxcrfYuaMUj2YhDwFdeqnWa3kzpFEcGe2mm5 SY8sjgmEAhLA7wHpFwo1yuYnw97HGC4Zl5W0NAXeLq0BvHCyHcKddzLfCYuPuk2npG0j FBnCfcbw79jkGLuCbYN/60PEEEUuyHC2hO03zeu6SXfdMtbfTxE9lHEQz6eF9f83RdYx av8kUSAK+SVsR0PsZ0RcsYMTu/4M41kAwE9Z8Eyxp5ByxMRaV0BlOmgwJ6nnrcMEWZqW ZMjf8xqLfh/AMEeVNqAHZEsq2ZMll6d4iXKTMwblrC7biU8BYxmJqrw5WUGiGWljtzt8 cjYg== X-Received: by 10.140.150.131 with SMTP id 125mr40314342qhw.88.1444046917065; Mon, 05 Oct 2015 05:08:37 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Cl=C3=A9ment_Elbaz?= Date: Mon, 05 Oct 2015 12:08:27 +0000 Message-ID: To: =?UTF-8?B?Sm9yZ2UgVGltw7Nu?= , Mike Hearn Content-Type: multipart/alternative; boundary=001a11376a7287e85105215a5f0e 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 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, 05 Oct 2015 12:08:38 -0000 --001a11376a7287e85105215a5f0e Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable It will get correct results about : - the existence every block - the existence of every transaction It will get incorrect results : - about the *nature* of some transactions - and therefore, about the balances of some wallets. I fully agree with Mike here. Le lun. 5 oct. 2015 =C3=A0 14:04, Jorge Tim=C3=B3n < bitcoin-dev@lists.linuxfoundation.org> a =C3=A9crit : > > On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > Well, let's agree to disagree on these two things: > > > > - I define "working" for a full node as verifying everything; if a node > starts skipping bits then I'd say it's not really "working" according to > its original design goals > > But assuming the hashrate majority has upgraded (and we're using 95% as > the miner upgrade confirmation threshold to start activation, so that > assumption seems pretty safe), a non-upgraded full node and an upgraded > full will converge on what they see: "the most-work valid chain" will be > the same for both. A non-upgraded full node wallet waiting for several > confirmations (for example, 6 confirmations) will be just as safe as an > upgraded one. In that sense, it keeps working. On top of that, nodes (of > any kind) can use unknown block version numbers to notify the user or eve= n > stop working (the same notification mechanism you would use with hardfork= s). > > I agree that hardforks are necessary and we should deploy a hardfork asap > to show the world they are indeed possible (bip99 proposes a likely > uncontroversial one), but I still believe that is clear that softfork > deployment is preferrable in many cases like this one. > > Are you going to produce a bip65 hardfork alternative to try to convince > people of its advantages over bip65 (it is not clear to me how you includ= e > a new script operand via hardfork)? > _______________________________________________ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > --001a11376a7287e85105215a5f0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
It will get correct results about :
- the existence ev= ery block
- the existence of every transaction

It will get incorrect results :
- about the nature = of some transactions
- and therefore, about the balances of some = wallets.

I fully agree with Mike here.
=
Le=C2=A0lun. 5 oct. 2015 = =C3=A0=C2=A014:04, Jorge Tim=C3=B3n <bitcoin-dev@lists.linuxfoundation.org> a =C3= =A9crit=C2=A0:


On Oct 5, 2015 1:28 PM, "Mike Hearn via bitcoin-dev" <bitcoin= -dev@lists.linuxfoundation.org> wrote:
>
> Well, let's agree to disagree on these two things:
>
> - I define "working" for a full node as verifying everything= ; if a node starts skipping bits then I'd say it's not really "= ;working" according to its original design goals

But assuming the hashrate majority has upgraded (and we'= re using 95% as the miner upgrade confirmation threshold to start activatio= n, so that assumption seems pretty safe), a non-upgraded full node and an u= pgraded full will converge on what they see: "the most-work valid chai= n" will be the same for both. A non-upgraded full node wallet waiting = for several confirmations (for example, 6 confirmations) will be just as sa= fe as an upgraded one. In that sense, it keeps working. On top of that, nod= es (of any kind) can use unknown block version numbers to notify the user o= r even stop working (the same notification mechanism you would use with har= dforks).

I agree that hardforks are necessary and we should deploy a = hardfork asap to show the world they are indeed possible (bip99 proposes a = likely uncontroversial one), but I still believe that is clear that softfor= k deployment is preferrable in many cases like this one.

Are you going to produce a bip65 hardfork alternative to try= to convince people of its advantages over bip65 (it is not clear to me how= you include a new script operand via hardfork)?

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev
--001a11376a7287e85105215a5f0e--