Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 46FCCD80 for ; Fri, 25 May 2018 10:15:00 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o51.zoho.com (sender-of-o51.zoho.com [135.84.80.216]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 86EC86D3 for ; Fri, 25 May 2018 10:14:59 +0000 (UTC) Received: from [10.8.0.101] (n218103136198.netvigator.com [218.103.136.198]) by mx.zohomail.com with SMTPS id 1527243292402928.8070189995224; Fri, 25 May 2018 03:14:52 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 11.2 \(3445.5.20\)) From: Johnson Lau In-Reply-To: Date: Fri, 25 May 2018 18:14:48 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Gregory Maxwell , bitcoin-dev X-Mailer: Apple Mail (2.3445.5.20) X-ZohoMailClient: External X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE 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] Should Graftroot be optional? X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 25 May 2018 10:15:00 -0000 > On 24 May 2018, at 10:08 AM, Gregory Maxwell via bitcoin-dev = wrote: >=20 > On Thu, May 24, 2018 at 1:58 AM, Pieter Wuille via bitcoin-dev > wrote: >> Thanks everyone who commented so far, but let me clarify the context >> of this question first a bit more to avoid getting into the weeds too >> much. >=20 > since the signer(s) could have signed an arbitrary > transaction instead, being able to delegate is strictly less powerful. >=20 Actually, we could introduce graftroot-like delegation to all existing = and new P2PK and P2PKH UTXOs with a softfork: 1. Define SIGHASH_GRAFTROOT =3D 0x40. New rules apply if (nHashType & = SIGHASH_GRAFTROOT) 2. The third stack item MUST be at least 64 bytes, with 32-byte R and = 32-byte S, followed by a script of arbitrary size. It MUST be a valid = signature for the script with the original public key. 3. The remaining stack items MUST solve the script Conceptually this could be extended to arbitrary output types, not just = P2PK and P2PKH. But it might be too complicated to describe here. (We can=E2=80=99t do this in P2WPKH and P2WSH due to the implicit = CLEANSTACK rules. But nothing could stop us to do it by introducing = another witness structure (which is invisible to current nodes) and = store the extra graftroot signatures and scripts) 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. This also doesn=E2=80=99t have any problem with = blind signature, since the first signature will always sign the = outpoint, with or without ANYONECANPAY. (As I pointed out in my reply to = Andrew, his concern applies only to SIGHASH_NOINPUT, not graftroot) =3D=3D=3D=3D=3D=3D With the example above, I believe there is no reason to make graftroot = optional, at the expense of block space and/or reduced privacy. Any = potential problem (e.g. interaction with blind signature) could be fixed = by a proper rules design.=