From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp2.osuosl.org (smtp2.osuosl.org [140.211.166.133]) by lists.linuxfoundation.org (Postfix) with ESMTP id 4DF8BC002D for ; Wed, 10 Aug 2022 03:00:01 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp2.osuosl.org (Postfix) with ESMTP id 15CBB402F2 for ; Wed, 10 Aug 2022 03:00:01 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 15CBB402F2 Authentication-Results: smtp2.osuosl.org; dkim=pass (1024-bit key) header.d=gazeta.pl header.i=@gazeta.pl header.a=rsa-sha256 header.s=2013 header.b=fZvxvG5M X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -2.099 X-Spam-Level: X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Received: from smtp2.osuosl.org ([127.0.0.1]) by localhost (smtp2.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fR6O0CJK85qU for ; Wed, 10 Aug 2022 02:59:59 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp2.osuosl.org 2444340195 Received: from o243.poczta.onet.pl (o243.poczta.onet.pl [213.180.142.243]) by smtp2.osuosl.org (Postfix) with ESMTPS id 2444340195 for ; Wed, 10 Aug 2022 02:59:58 +0000 (UTC) Received: from pmq5v.m5r2.onet (pmq5v.m5r2.onet [10.174.35.25]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4M2ZRV0qsBz4Wq0 for ; Wed, 10 Aug 2022 04:59:50 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1660100390; bh=sbAaG6x6BdDkzpMTU2Xtrx+TLiOq2Zf0r5n8oTHXYpw=; h=From:To:In-Reply-To:Date:Subject:From; b=fZvxvG5MXdZM/RFCI/xF9pkaSw5IliHye+Lq9E+/ZsbURbmkm8bQoDX3pPNxvdhKS GGguyogek6A+5UuAs/jWHwCIqodoReCvvZokmCFaztIUXIwL+7fYCREZ0qeWhud+uO hNU5PKFy6ySg8oMo0bMyj0vb3RKY8xx0o1brXzN4= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.240.242] by pmq5v.m5r2.onet via HTTP id ; Wed, 10 Aug 2022 04:59:50 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "Ali Sherief , Bitcoin Protocol Discussion" , bitcoin-dev@lists.linuxfoundation.org In-Reply-To: <20220809130908.yykum37tre7um4j3@artanis> Date: Wed, 10 Aug 2022 04:59:46 +0200 Message-Id: <165836641-bc7ec98411dacebd3de15c1b1f7c5cf4@pmq5v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.240.242;PL;1 X-Mailman-Approved-At: Wed, 10 Aug 2022 08:22:32 +0000 Subject: Re: [bitcoin-dev] Regarding BIP322 edge cases X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Aug 2022 03:00:01 -0000 > I'm not sure what is to be gained from adding an opcode Backward compatibility. If we don't have OP_CHECKDATASIG, then it has to be= somehow introduced to make it compatible with "Bitcoin Message". And we ha= ve opcodes like OP_RESERVED, that can be wrapped in OP_IF, then it is "cond= itionally valid transaction". It is also possible to assign some unused opc= ode, but then it will be more complex, because in Script, those opcodes mak= e transaction invalid, but inside TapScript, those opcodes are defined as O= P_SUCCESS, and make things automatically valid. On 2022-08-09 22:53:34 user Ali Sherief via bitcoin-dev wrote: > Although there is a Github issue/PR at https://github.com/bitcoin/bips/pu= ll/1347 for addressing all the TODO items of BIP322, I decided to throw it = in the mailing list again to see if anyone else has suggestions for dealing= with them. So in an older copy of the draft at https://github.com/bitcoin/bips/blob/b6= b0126e2d04793ba52a40f05d24538fa3f2c9ad/bip-0322.mediawiki , I found the som= e TODO items, and I will copy-paste the ones in the Specification section (= for full proofs) here: > TODO: How does this interact with as-of-yet-unspecified "Silent Transacti= ons"? > TODO: Some invalid opcode to allow only in various proof types? > TODO: A way for the initial signer to delegate to another scriptPubKey; n= eeded for better privacy and CoinJoin/Lightning compatibility So to start with, I believe it will be very helpful to limit what opcodes s= criptPubKeys to be elligible to sign from them. The specification already d= oes so to a point, but in order for these to be recognizable, it's my opini= on that one of the NOPs should be placed at the beginning of the script to = activate proof parsing mode. Of course, an opcode is not necessary at all, if the program is able to inf= er from context where the proof is coming from. After all, since they canno= t be broadcasted, they can't be mined in blocks, so will never be encounter= ed in a full node's usual verifier. I'm not sure what is to be gained from = adding an opcode - the only source for real transactions is from P2P-obtain= ed blocks, so when a human inputs a signature to be verified, it can check = that a real transaction is not being inserted by looking for the invalid in= put. For Silent Transactions, I have already given my suggestion in the PR, that= some subsection can be made saying that it can operate with them by using = its scriptPubKey (and other stuff that may be necessary - I am not excatly = sure what goes inside the Witness stack of message_signature). In the case of the last TODO, related to delegation to another scriptPubKey= , I am not quite sure at the moment what to do about it - perhaps you guys = can place a MAST (two Merkle branches, to be specific) - the first branch h= as the original signer's scriptPubKey, the second branch contains the deleg= ated signer's scriptPubKey. - Ali _______________________________________________ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev