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 995A2BDF for ; Thu, 21 Sep 2017 17:38:11 +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 C6F81421 for ; Thu, 21 Sep 2017 17:38:10 +0000 (UTC) Received: from [10.8.0.102] (119246244201.ctinets.com [119.246.244.201]) by mx.zohomail.com with SMTPS id 150601548627574.65223904552363; Thu, 21 Sep 2017 10:38:06 -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: <201709211633.17714.luke@dashjr.org> Date: Fri, 22 Sep 2017 01:38:01 +0800 Content-Transfer-Encoding: quoted-printable Message-Id: <7BF7D0B8-A38C-44B9-B6E9-44A74782CC81@xbt.hk> References: <5B6756D0-6BEF-4A01-BDB8-52C646916E29@friedenbach.org> <201709210411.50642.luke@dashjr.org> <21D6060D-97F0-439A-86D3-065C21BACC3F@xbt.hk> <201709211633.17714.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 17:38:11 -0000 > On 22 Sep 2017, at 12:33 AM, Luke Dashjr wrote: >=20 > On Thursday 21 September 2017 8:02:42 AM Johnson Lau wrote: >> 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. >=20 > SigAgg is a softfork, so old clients *won't* understand it... am I = missing=20 > something? >=20 > For example, perhaps the lookup opcode could have a data payload = itself (eg,=20 > like pushdata opcodes do), and the script can be parsed independently = from=20 > execution to collect the applicable ones. I think the current idea of sigagg is something like this: the new = OP_CHECKSIG still has 2 arguments: top stack must be a 33-byte public = key, and the 2nd top stack item is signature. Depends on the sig size, = it returns different value: If sig size is 0, it returns a 0 to the top stack If sig size is 1, it is treated as a SIGHASH flag, and the = SignatureHash() =E2=80=9Cmessage=E2=80=9D is calculated. It sends the = (pubkey, message) pair to the aggregator, and always returns a 1 to the = top stack If sig size is >1, it is treated as the aggregated signature. The last = byte is SIGHASH flag. It sends the (pubkey, message) pair and the = aggregated signature to the aggregator, and always returns a 1 to the = top stack. If all scripts pass, the aggregator will combine all pairs to obtain the = aggkey and aggmsg, and verify against aggsig. A tx may have at most 1 = aggsig. (The version I presented above is somewhat simplified but should be = enough to illustrate my point) So if we have this script: OP_1 OP_RETURNTRUE OP_CHECKSIG Old clients would stop at the OP_RETURNTRUE, and will not send the = pubkey to the aggregator If we softfork OP_RETURNTRUE to something else, even as OP_NOP11, new = clients will send the (key, msg) pair to the aggregator. Therefore, the = aggregator of old and new clients will see different data, leading to a = hardfork. OTOH, OP_NOP based softfork would not have this problem because it = won=E2=80=99t terminate script and return true. >=20 >>> This is another approach, and one that seems like a good idea in = general. >>> I'm not sure it actually needs to take more witness space - in = theory, >>> such stack items could be implied if the Script engine is designed = for >>> it upfront. Then it would behave as if it were non-verify, while >>> retaining backward compatibility. >>=20 >> Sounds interesting but I don=E2=80=99t get it. For example, how could = you make a >> OP_MUL out of OP_NOP? >=20 > The same as your OP_MULVERIFY at the consensus level, except new = clients would=20 > execute it as an OP_MUL, and inject pops/pushes when sending such a=20 > transaction to older clients. The hash committed to for the script = would=20 > include the inferred values, but not the actual on-chain data. This = would=20 > probably need to be part of some kind of MAST-like softfork to be = viable, and=20 > maybe not even then. >=20 > Luke I don=E2=80=99t think it=E2=80=99s worth the code complexity, just to = save a few bytes of data sent over wire; and to be a soft fork, it still = takes the block space. Maybe we could create many OP_DROPs and OP_2DROPs, so new VERIFY = operations could pop the stack. This saves 1 byte and also looks = cleaner. Another approach is to use a new script version for every new non-verify = type operation. Problem is we will end up with many versions. Also, = signatures from different versions can=E2=80=99t be aggregated. (We may = have multiple aggregators in a transaction)