From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.osuosl.org (smtp1.osuosl.org [IPv6:2605:bc80:3010::138]) by lists.linuxfoundation.org (Postfix) with ESMTP id B4742C002D for ; Tue, 3 May 2022 07:37:29 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp1.osuosl.org (Postfix) with ESMTP id 8F10681B23 for ; Tue, 3 May 2022 07:37:29 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[BAYES_05=-0.5, 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 Authentication-Results: smtp1.osuosl.org (amavisd-new); dkim=pass (1024-bit key) header.d=gazeta.pl Received: from smtp1.osuosl.org ([127.0.0.1]) by localhost (smtp1.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id raSaZ0xzwbJP for ; Tue, 3 May 2022 07:37:28 +0000 (UTC) X-Greylist: from auto-whitelisted by SQLgrey-1.8.0 Received: from smtpo105.poczta.onet.pl (smtpo105.poczta.onet.pl [213.180.149.158]) by smtp1.osuosl.org (Postfix) with ESMTPS id 9510D81AD1 for ; Tue, 3 May 2022 07:37:28 +0000 (UTC) Received: from pmq7v.m5r2.onet (pmq7v.m5r2.onet [10.174.35.192]) by smtp.poczta.onet.pl (Onet) with ESMTP id 4KssHN548Pzgly for ; Tue, 3 May 2022 09:37:20 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gazeta.pl; s=2013; t=1651563440; bh=LUj5Eskb6rwpleQLbqXw/fFRZ8o69kyj4a1ovZYWyG4=; h=From:To:Date:Subject:From; b=gGUXmmsPPQUtcby1ptfzqQXjZdDtL00YmciRoWUSvtm0OrogGSr2pFwbMJOtvyMLj jTc07nql5H1ImMk1u9oWuQ4acvWI5EPgOAArukNBcBqjxNvG7CdwESxSmUtNU/rdb2 M180R/ABWNQp4e4llG5taL8nRgMsVoI4Z6efuEGU= Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Received: from [5.173.224.171] by pmq7v.m5r2.onet via HTTP id ; Tue, 03 May 2022 09:37:20 +0200 From: vjudeu@gazeta.pl X-Priority: 3 To: "bitcoin-dev@lists.linuxfoundation.org" Date: Tue, 03 May 2022 09:37:20 +0200 Message-Id: <160600410-14147cd52da04b7e94af778dff5502bf@pmq7v.m5r2.onet> X-Mailer: onet.poczta X-Onet-PMQ: ;5.173.224.171;PL;1 X-Mailman-Approved-At: Tue, 03 May 2022 08:33:09 +0000 Subject: [bitcoin-dev] Pay to signature hash as a covenant 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: Tue, 03 May 2022 07:37:29 -0000 Typical P2PK looks like that: " OP_CHECKSIG". In a typi= cal scenario, we have "" in out input and " OP_CHECKSIG"= in our output. I wonder if it is possible to use covenants right here and = right now, with no consensus changes, just by requiring a specific signatur= e. To start with, I am trying to play with P2PK and legacy signatures, but = it may turn out, that doing such things with Schnorr signatures will be mor= e flexible and will allow more use cases. The simplest "pay to signature" script I can think of is: " OP_S= WAP OP_CHECKSIG". Then, any user can provide just a "" in some inpu= t, as a part of a public key recovery. The problem with such scheme is that= it is insecure. Another problem is that we should handle it carefully, bec= ause signatures are removed from outputs. However, we could replace it with= some signature hash, then it will be untouched, for example: "OP_TOALTSTAC= K OP_DUP OP_HASH160 OP_EQUALVERIFY OP_FROMALTSTACK OP_CHECK= SIG". And then, signatures are more flexible than public keys, because we can use= many different sighashes to decide, what kind of transaction is allowed an= d what should be rejected. Then, if we could use the right signature with c= orrect sighashes, it could be possible to disable key recovery and require = some specific public key, then that scheme could be safely used again. I st= ill have no idea, how to complete that puzzle, but it seems to be possible = to use that trick, to restrict destination address. Maybe I should wrap suc= h things in some kind of multisig or somehow combine it with OP_CHECKSIGADD= , any ideas?