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 D974A8E2 for ; Thu, 21 Sep 2017 08:02:56 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 Received: from sender-of-o52.zoho.com (sender-of-o52.zoho.com [135.84.80.217]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2DD35163 for ; Thu, 21 Sep 2017 08:02:55 +0000 (UTC) Received: from [10.7.45.226] (ip-123-255-103-86.wlan.cuhk.edu.hk [123.255.103.86]) by mx.zohomail.com with SMTPS id 1505980971508787.250021505688; Thu, 21 Sep 2017 01:02:51 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 10.3 \(3273\)) From: Johnson Lau In-Reply-To: <201709210411.50642.luke@dashjr.org> Date: Thu, 21 Sep 2017 16:02:42 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <21D6060D-97F0-439A-86D3-065C21BACC3F@xbt.hk> References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org> <201709190309.08669.luke@dashjr.org> <201709210411.50642.luke@dashjr.org> To: Luke Dashjr X-Mailer: Apple Mail (2.3273) X-ZohoMailClient: External X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE autolearn=disabled 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] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST) 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: Thu, 21 Sep 2017 08:02:57 -0000 > On 21 Sep 2017, at 12:11 PM, Luke Dashjr wrote: >=20 > On Wednesday 20 September 2017 5:13:04 AM Johnson Lau wrote: >> 2. OP_RETURNTRUE does not work well with signature aggregation. = Signature >> aggregation will collect (pubkey, message) pairs in a tx, combine = them, >> and verify with one signature. However, consider the following case: >>=20 >> OP_RETURNTRUE OP_IF OP_CHECKSIGVERIFY OP_ENDIF OP_TRUE >>=20 >> For old nodes, the script terminates at OP_RETURNTRUE, and it will = not >> collect the (pubkey, message) pair. >>=20 >> If we use a softfork to transform OP_RETURNTRUE into OP_17 (pushing = the >> number 17 to the stack), new nodes will collect the (pubkey, message) = pair >> and try to aggregate with other pairs. This becomes a hardfork. >=20 > This seems like a problem for signature aggregation to address, not a = problem=20 > for OP_RETURNTRUE... In any case, I don't think it's insurmountable. = Signature=20 > aggregation can simply be setup upfront, and have the Script verify = inclusion=20 > of keys in the aggregation? I think it=E2=80=99s possible only if you spend more witness space to = store the (pubkey, message) pairs, so that old clients could understand = the aggregation produced by new clients. But this completely defeats the = purpose of doing aggregation. We use different skills to save space. For example, we use 1-byte = SIGHASH flag to imply the 32-byte message. For maximal space saving, sig = aggregation will also rely on such skills. However, the assumption is = that all signatures aggregated must follow exactly the same set of = rules. >=20 >> Technically, we could create ANY op code with an OP_NOP. For example, = if we >> want OP_MUL, we could have OP_MULVERIFY, which verifies if the 3rd = stack >> item is the product of the top 2 stack items. Therefore, OP_MULVERIFY >> OP_2DROP is functionally same as OP_MUL, which removes the top 2 = items and >> returns the product. The problem is it takes more witness space. >=20 > This is another approach, and one that seems like a good idea in = general. I'm=20 > not sure it actually needs to take more witness space - in theory, = such stack=20 > items could be implied if the Script engine is designed for it = upfront. Then=20 > it would behave as if it were non-verify, while retaining backward=20 > compatibility. Sounds interesting but I don=E2=80=99t get it. For example, how could = you make a OP_MUL out of OP_NOP? >=20 > Luke