Return-Path: Received: from smtp3.osuosl.org (smtp3.osuosl.org [IPv6:2605:bc80:3010::136]) by lists.linuxfoundation.org (Postfix) with ESMTP id 28216C002D for ; Tue, 3 May 2022 09:35:43 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp3.osuosl.org (Postfix) with ESMTP id 0FF9060EB1 for ; Tue, 3 May 2022 09:35:43 +0000 (UTC) X-Virus-Scanned: amavisd-new at osuosl.org X-Spam-Flag: NO X-Spam-Score: -1.601 X-Spam-Level: X-Spam-Status: No, score=-1.601 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, FROM_LOCAL_NOVOWEL=0.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no Authentication-Results: smtp3.osuosl.org (amavisd-new); dkim=pass (2048-bit key) header.d=protonmail.com Received: from smtp3.osuosl.org ([127.0.0.1]) by localhost (smtp3.osuosl.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id It5djBAaU2ma for ; Tue, 3 May 2022 09:35:41 +0000 (UTC) X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0 Received: from mail-40135.protonmail.ch (mail-40135.protonmail.ch [185.70.40.135]) by smtp3.osuosl.org (Postfix) with ESMTPS id 86D2C60C05 for ; Tue, 3 May 2022 09:35:41 +0000 (UTC) Date: Tue, 03 May 2022 09:35:31 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com; s=protonmail2; t=1651570538; bh=vaqiscGNnST1BTJEOsz6fsK0AIaZkhZ07A9VoOiF10U=; h=Date:To:From:Reply-To:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID; b=gApfqf27lBdveJ8tDMiqRNHMfql/yAW8GZwEw7wnE0czpzL08WcwxskEBjtwykWl+ NDTB4uQu0zPvDR8j4bxeFacHoP4QYE8vFmiWXg4nEkqUdrKNOu7m9hwSrrWmAORbxz p4UanUVnyB5aLn1dKf7SwRCY6IpLCdc8Uxdn7+uej59+Ou54VsCy7DJ8i0/Aqou6ZY 5wOxHRuzCkVl1vGtM30MxDlyJfO/HrxI8MSbqMjqgigSrd+kd2tmuIU5TXRveN6PS5 9f1UkZ5eUCadPKSqmAW6t/PITweBrxmInWThezWL//zcw1QU1PEz5hKOGGSKtAa/C7 d0jpQJ1xwM2rg== To: vjudeu@gazeta.pl, Bitcoin Protocol Discussion From: ZmnSCPxj Reply-To: ZmnSCPxj Message-ID: <9WZCDiqADRzJudttdoDBbzOf65MpFgxUHU-4Qf3b9tJRglu81V-UB4wvvNJntGS-_F3X4mEVJPFqNRAkykn935hVGrnvxeYeX9I2nRClmRI=@protonmail.com> In-Reply-To: <160600410-14147cd52da04b7e94af778dff5502bf@pmq7v.m5r2.onet> References: <160600410-14147cd52da04b7e94af778dff5502bf@pmq7v.m5r2.onet> Feedback-ID: 2872618:user:proton MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [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 09:35:43 -0000 Good morning vjudeu, > Typical P2PK looks like that: " OP_CHECKSIG". In a ty= pical scenario, we have "" in out input and " OP_CHECKSI= G" in our output. I wonder if it is possible to use covenants right here an= d right now, with no consensus changes, just by requiring a specific signat= ure. To start with, I am trying to play with P2PK and legacy signatures, bu= t it may turn out, that doing such things with Schnorr signatures will be m= ore flexible and will allow more use cases. > > > The simplest "pay to signature" script I can think of is: " OP= _SWAP OP_CHECKSIG". Then, any user can provide just a "" in some in= put, as a part of a public key recovery. The problem with such scheme is th= at it is insecure. Another problem is that we should handle it carefully, b= ecause signatures are removed from outputs. However, we could replace it wi= th some signature hash, then it will be untouched, for example: "OP_TOALTST= ACK OP_DUP OP_HASH160 OP_EQUALVERIFY OP_FROMALTSTACK OP_CHE= CKSIG". > > And then, signatures are more flexible than public keys, because we can u= se many different sighashes to decide, what kind of transaction is allowed = and what should be rejected. Then, if we could use the right signature with= correct sighashes, it could be possible to disable key recovery and requir= e some specific public key, then that scheme could be safely used again. I = still have no idea, how to complete that puzzle, but it seems to be possibl= e to use that trick, to restrict destination address. Maybe I should wrap s= uch things in some kind of multisig or somehow combine it with OP_CHECKSIGA= DD, any ideas? You can do the same thing with P2SH, P2WSH, and P2TR (in a Tapscript) as we= ll. Note that it is generally known that you *can* use pre-signed transactions = to implement vaults. Usually what we refer to by "covenant" is something like "this output will = definitely be constructed here" without necessarily requiring a signature. HOWEVER, what you are proposing is not ***quite*** pre-signed transactions! Instead, you are (ab)using signatures in order to commit to particular sigh= ashes. First, let me point out that you do not need to hash the signature and *the= n* use a raw `scriptPubKey`, which I should *also* point it is not going to= pass `IsStandard` checks (and will not propagate on the mainnet network re= liably, only on testnet). Instead, you can use P2WSH and *include* the signature outright in the `red= eemScript`. Since the output `scriptPubKey` is really just the hash of the `redeemScrip= t`, this is automatically a hash of a signature (plus a bunch of other byte= s). So your proposal boils down to using P2WSH and having a `redeemScript`: redeemScript =3D OP_CHECKSIG Why include the `fixPubKey` in the `redeemScript`? In your scheme, you would provide the signature and pubkey in the `scriptSi= g` that spends the `scriptPubKey`. But in a post-P2WSH world, `redeemScript` will also be provided in the `wit= ness`, so you *also* provide both the signature and the pubkey, and both ar= e hashed before appearing on the `scriptPubKey` --- which is exactly what y= ou are proposing anyway. The above pre-commits to a particular transaction, depending on the `SIGHAS= H` flags of the `fixedSignature`. Of note is that the `fixPubKey` can have a throwaway privkey, or even a ***= publicly-shared*** privkey. Even if an alternate signature is created from well-known privkey, the `re= deemScript` will not allow any other signature to be accepted, it will only= use the one that is hardcoded into the script. Using a publicly-shared privkey would allow us to compute just the expected= `sighash`. them derove the `fixedSignature` that should be in the `redeemS= cript`. In particular, this scheme would work just as well for the "congestion cont= rol" application proposed for `OP_CTV`. `OP_CTV` still wins in raw WUs spent (just the 32-WU hash), but in the abse= nce of `OP_CTV` because raisins, this would also work (but you reveal a 33-= WU pubkey, and a 73-WU/64-WU signature, which is much larger). Validation speed is also better for `OP_CTV`, as it is just a hash, while t= his scheme uses signature validation in order to commit to a specific hash = anyway (a waste of CPU time, since you could just check the hash directly i= nstead of going through the rigmarole of a signature, but one which allows = us to make non-recursive covenants with some similarities to `OP_CTV`). A purported `OP_CHECKSIGHASHVERIFY` which accepts a `SIGHASH` flag and a ha= sh, and checks that the sighash of the transaction (as modified by the flag= s) is equal to the hash, would be more efficient, and would also not differ= by much from `OP_CTV`. This can be used in a specific branch of an `OP_IF` to allow, say, a cold p= rivkey to override this branch, to start a vault construction. The same technique should work with Tapscripts inside Taproot (but the `fix= edPubKey` CANNOT be the same as the internal Taproot key!). Regards, ZmnSCPxj