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 B986D183B for ; Mon, 28 Sep 2015 17:14:17 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 95A682CD for ; Mon, 28 Sep 2015 17:14:16 +0000 (UTC) Received: by iofb144 with SMTP id b144so183376177iof.1 for ; Mon, 28 Sep 2015 10:14:16 -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=T1GedvRr1tX3d1HrZe08FuiciTYlt0IafWOSnh/PrZo=; b=VPOxAbAw+t6ERj212gdoHj9yAiLcbrEEGN/8qa4cBYJCsnKJNimXfTefMDlqimeFb5 B/ksMAgS2+4/1na1SZh762lq53ah1shs0M7iypNb3B21J3jpycpG0NbvqXhSkV0IbUQn ws9DUWzs47qikuNZ1WW2WFAAHjOHUsZ7Z3hlc= 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=T1GedvRr1tX3d1HrZe08FuiciTYlt0IafWOSnh/PrZo=; b=HChiza4se1G3qYDLxfY14PNRRZiy7x68a0uA5FkQ4AW4hJJ2TOqBhfWpvUGPPXBxKI BNnNv5mG9yM+i7ZnjmrhaIeSP8TJ36XgKAUNKbYnlsz+02GSAIjzySME1wnt//XOnlXB wN4GpY+MV7ZVG761pwhNnurtp+YzbhRO+h95EjgTN6l5Wsi2nSXYwMEWIu4pNynMycSD bnWN+Yvdn0yGpGUyffLu2L/8RZpyvJ1Q9f4PaFrWQCzVfW/uFEdBGWV76B3atnNjT2N2 rpl2F1GhXg52LJEdjyuBpHWJgOf6ZAsQZchfkM7U0cZ1ChWfBY7wFUpr6fDEU5E7krhR LCsw== X-Gm-Message-State: ALoCoQmpOoql+7gNpsSKDW+5J2Cly/iX8o9ewrDxO4anCIs0kZhGX2qNe5aoS5/Yevkxs862FHRV MIME-Version: 1.0 X-Received: by 10.107.137.144 with SMTP id t16mr20860560ioi.102.1443460455869; Mon, 28 Sep 2015 10:14:15 -0700 (PDT) Received: by 10.50.226.144 with HTTP; Mon, 28 Sep 2015 10:14:15 -0700 (PDT) In-Reply-To: <8461c6195ca65ce7355f693fa24bb177@xbt.hk> References: <20150927185031.GA20599@savin.petertodd.org> <20150928132127.GA4829@savin.petertodd.org> <20150928142953.GC21815@savin.petertodd.org> <20150928144318.GA28939@savin.petertodd.org> <20150928150543.GB28939@savin.petertodd.org> <8461c6195ca65ce7355f693fa24bb177@xbt.hk> Date: Mon, 28 Sep 2015 19:14:15 +0200 Message-ID: From: Mike Hearn To: jl2012@xbt.hk Content-Type: multipart/alternative; boundary=001a113fb1e4b84bd20520d1d37e 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 17:14:17 -0000 --001a113fb1e4b84bd20520d1d37e Content-Type: text/plain; charset=UTF-8 > > Let me try to answer this question. Softfork is beneficial to non-mining > full nodes as they will follow the majority chain. That is not a benefit. That is a description of what the software will do, but not why you would want it. In case this seems like a pedantic point, consider the consequences of following a chain you aren't checking properly. You get SPV level security and might calculate a corrupted ledger. In the case of P2SH, I could make a transaction that spends someone elses money to myself. In the case of CLTV, I could ignore the locktime requirement. Now yes, eventually, the miner majority will correct and uncorrupt your ledger for you. But by then it might be too late, you may have already acted upon the incorrect data by e.g. selling me lots of stuff that I paid for with somebody else's coins. If you don't care about that risk, hey, switch to an SPV wallet and save yourself a lot of disk space. > In a hardfork, however, there is no mechanism to stop the old fork and we > may have 2 chains co-exist for a long time. > There isn't any difference in how long the divergent state exists for. That depends only on how fast people upgrade, which is unaffected by the rollout strategy used. --001a113fb1e4b84bd20520d1d37e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Let me try to answer this question. Softfork is beneficial to = non-mining full nodes as they will follow the majority chain. =

That is not a benefit. That is a description of what th= e software will do, but not why you would want it.

In case this seems like a pedantic point, consider the consequences of fol= lowing a chain you aren't checking properly. You get SPV level security= and might calculate a corrupted ledger.=C2=A0

In = the case of P2SH, I could make a transaction that spends someone elses mone= y to myself. In the case of CLTV, I could ignore the locktime requirement.<= /div>

Now yes, eventually, the miner majority will corre= ct and uncorrupt your ledger for you. But by then it might be too late, you= may have already acted upon the incorrect data by e.g. selling me lots of = stuff that I paid for with somebody else's coins. If you don't care= about that risk, hey, switch to an SPV wallet and save yourself a lot of d= isk space.
=C2=A0
In a hardfork, however, t= here is no mechanism to stop the old fork and we may have 2 chains co-exist= for a long time.

There isn't any d= ifference in how long the divergent state exists for. That depends only on = how fast people upgrade, which is unaffected by the rollout strategy used.<= /div>
--001a113fb1e4b84bd20520d1d37e--