Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 0838DE04 for ; Fri, 9 Aug 2019 18:30:09 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ot1-f54.google.com (mail-ot1-f54.google.com [209.85.210.54]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 9148382F for ; Fri, 9 Aug 2019 18:30:08 +0000 (UTC) Received: by mail-ot1-f54.google.com with SMTP id l15so136217135otn.9 for ; Fri, 09 Aug 2019 11:30:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to; bh=u4h2lffoLHiq7mhvHBTIYTCvQ6Czky3Wfa+FEk0mIlo=; b=oDf4t2dnshhHg1qcTljKWZR9azRsGQwK7wsCcMzeQT7gmEjv8nHshwlAwnlNP1MR0S O+/wgKHPTGajINw/VZW6Q5MJGAumZjKnXajmbOqgYl38fbRUsjgGHIg2TzW35jkOobXq GZs6EjWd7IAfCt5Xn+dJ1tybT2TEq0+z8M4XLq8OBWJVmA7GsN8rMK9hhlv1cBlgqQuo A/vEwf61VxLzOrTfNEL9CAlLafUmHeWmz5z0duUUZrqo19V+M+I3QdAl2y2LoeNO1hf8 p9XqXXnYAnFpKFtYEJZkianllK9uE/moVYXb2K8MQ+BK2chpR/nkORpvTExQGsdVVypD 0oIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to; bh=u4h2lffoLHiq7mhvHBTIYTCvQ6Czky3Wfa+FEk0mIlo=; b=DzNrwXxvMbEVQBsRAaaJ6jDQaJrMQAxY2sXVpywevWa6sT3Vuu/LHS0wrmREUePgdJ dA5Q8jBfB6UH+GcB4NJmhukjtsw0b5K7dilIPcyBdsUD5Me+1s5uOiTKXgc/rkVpysKi H6IqNH8Im9x6pAMjb4w94j+h4QkUoWg/IHOK4yy+10c09DDQYpw7cGNffIz1W4be6WS5 l572FhEqFK72y91h/ClJ2ojRMvpKTPqjvuR+M2cYr+eBxrp3toHTluytQeTRJlrnkKgG Bu6Kualk6NAN6E++HgiLUcqptWEG1i0zwNbgxi3Hm2naoxejk5vmpI5ZN2Q6ZujJxST/ a4ow== X-Gm-Message-State: APjAAAUaOnELlp/tu3cOCP2ZW/NV78ydf4JnqLTKEggjSRkhFKx+a55H PaEBRJmGDm2MvoLRF85qx6zFtCFzU9f5iXW4+RKmzK2E X-Google-Smtp-Source: APXvYqy8Jj6Ci4NPaDpdqz5eEctdeOJ2RhvksW+Hrzk/SCdt1AsAClpvhJJ/jqWn4qpBZXxJh3pP+iwJcVSL/muD6p0= X-Received: by 2002:a05:6830:144e:: with SMTP id w14mr17694730otp.10.1565375407781; Fri, 09 Aug 2019 11:30:07 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pieter Wuille Date: Fri, 9 Aug 2019 11:29:55 -0700 Message-ID: To: Elichai Turkel , Bitcoin Protocol Discussion Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, 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] Taproot proposal 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, 09 Aug 2019 18:30:09 -0000 On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev wrote: > > Hi, Since the idea of implicitly even pubkeys has potentially more general implications, I've started a separate thread [1] about that idea. > I want to add to John Newbery's suggestion of using implicit even/odd only public keys and tweaked public keys in taproot and suggest the following: > If everything is implicit then the only reason for the first byte of the control block(`c[0]`) is the tapscript leaf version. That's unfortunately not correct. If we want to maintain batch-verifiability of the taproot tweaking (the Q = P + H(P,m)G relation), we still need a bit in the control block to convey whether a negation was necessary to make P+H(P,m)G even, even if P and Q both have implied-even Y coordinates. Not doing that would require exploring 2^n combinations to batch verify n relations, obviously destroying any performance savings the batch verification had in the first place. > I suggest that this is moved to be the first OP_CODE of the tapscript itself (i.e. OP_0/OP_1 etc.) > That way having the script *tells* you what does it mean without needing to check the control block. > That way there's a separation between the tapscript+leaf version and the control block being the merkle path to the script. If we keep the leaf version idea (it's possible to instead just rely entirely on OP_SUCCESSx, and drop leaf versions), my preference is to still keep it separate from script, though just for a fairly banal reason: that way the script consists entirely of opcodes and can be treated uniformly by debug tools, rather than needing to treat the first byte special. I do understand your preference too, but I don't know how it weighs up. [1] https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017247.html Cheers, -- Pieter