MIME-Version: 1.0
In-Reply-To: <D996F4E8-ACC6-4A49-B841-0F3285344DF6@xbt.hk>
References: <CAPg+sBgKY-nmL=x+LVubtB0fFBAwd-1CDHT7zhidX8p9DLSGyg@mail.gmail.com>
	<CAPg+sBh4CESPV_5TpPn0H3Zpv2Ump_0txxS63W_S2f3Lxezq1A@mail.gmail.com>
	<CAAS2fgRXYtTyqqQp8Ehs_q_KsT7usA+vYSmngStnndd1rWNVNw@mail.gmail.com>
	<D996F4E8-ACC6-4A49-B841-0F3285344DF6@xbt.hk>
From: Pieter Wuille <pieter.wuille@gmail.com>
Date: Thu, 31 May 2018 17:25:04 -0700
Message-ID: <CAPg+sBgEUV5KNFi1L4MhR-3KAX9gbQKdzWneaEzF+QsKSXYu8A@mail.gmail.com>
To: Johnson Lau <jl2012@xbt.hk>
Content-Type: text/plain; charset="UTF-8"
Cc: bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Should Graftroot be optional?
Precedence: list

On Fri, May 25, 2018 at 3:14 AM, Johnson Lau <jl2012@xbt.hk> wrote:
> A graftroot design like this is a strict subset of existing signature checking rules. If this is dangerous, the existing signature checking rules must be dangerous.

While you may be right in this situation, I'm not sure that conclusion
follows from your argument. Whether or not a construction is safe does
not just depend on the consensus rules, but also on how it is used.
Otherwise you could as well argue that since OP_TRUE is possible right
now which is obviously insecure, nothing more dangerous can be
accomplished through any soft fork.

The best argument for why Graftroot does not need to be optional I
think was how Greg put it: "since the signer(s) could have signed an
arbitrary transaction instead, being able to delegate is strictly less
powerful.".

Cheers,

-- 
Pieter