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 CE6F59D for ; Wed, 8 May 2019 03:44:34 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6 Received: from mail-40133.protonmail.ch (mail-40133.protonmail.ch [185.70.40.133]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 1762D196 for ; Wed, 8 May 2019 03:44:33 +0000 (UTC) Date: Wed, 08 May 2019 03:44:29 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=default; t=1557287071; bh=fvb6V0lC1tic5hMqYTjftoZpmH1kmuJiZY90s1K7GKI=; h=Date:To:From:Cc:Reply-To:Subject:In-Reply-To:References: Feedback-ID:From; b=H86M4iVlxrczWjoxTOtR1vkGInS5OHUKN+R2MCn/aWT4/HO6B3jRSX8knlT0nH985 82atgBGskJkp+4QiYAq/5dyYLFahJpQV0SpxVbIFgivIb+peRs1YjXPRnO2x0rzB2y mfuU7lJNBuBXui0dJrZIzi53LxvlFC32EMWgmoCs= To: Luke Dashjr , Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: In-Reply-To: <201905062017.11396.luke@dashjr.org> References: <201905062017.11396.luke@dashjr.org> Feedback-ID: el4j0RWPRERue64lIQeq9Y2FP-mdB86tFqjmrJyEPR9VAtMovPEo9tvgA0CrTsSHJeeyPXqnoAu6DN-R04uJUg==:Ext:ProtonMail MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.2 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, FROM_LOCAL_NOVOWEL, RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Thu, 09 May 2019 14:48:55 +0000 Cc: Pieter Wuille 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: Wed, 08 May 2019 03:44:34 -0000 Good morning Luke, > Is there any way to use the Taproot construct here while retaining extern= al > script limitations that the involved party(ies) cannot agree to override? > For example, it is conceivable that one might wish to have an uncondition= al > CLTV enforced in all circumstances. Perhaps this can be enforced offchain, by participants refusing to sign a t= ransaction unless it has an `nLockTime` of the agreed-upon "unconditional C= LTV". Then the CLTV need only be on branches which have a strict subset of the pa= rticipants as signers. > > It may be useful to have a way to add a salt to tap branches. Would not adding `OP_PUSH() OP_DROP` to the leaves work? If you enforce always salting with a 32-byte salt, that "only" saves 3 byte= s of witness data (for the `OP_PUSHDATA1+size` and `OP_DROP` opcodes). Or do you refer to always salting every node? (I am uncertain, but would not adding a salt to every leaf be sufficient?) (in any case, if you use different pubkeys for each contract, rather than r= eusing keys, is that not enough randomization to prevent creating rainbow t= ables of scripts?) > > Some way to sign an additional script (not committed to by the witness > program) seems like it could be a trivial addition. It seems to me the annex can be used for this, by having it contain both th= e script and the signature somehow concatenated. Regards, ZmnSCPxj