From mboxrd@z Thu Jan 1 00:00:00 1970 Delivery-date: Wed, 15 May 2024 09:15:28 -0700 Received: from mail-oa1-f57.google.com ([209.85.160.57]) by mail.fairlystable.org with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from ) id 1s7HHr-0006Dp-Jo for bitcoindev@gnusha.org; Wed, 15 May 2024 09:15:28 -0700 Received: by mail-oa1-f57.google.com with SMTP id 586e51a60fabf-22edee26782sf4852482fac.3 for ; Wed, 15 May 2024 09:15:27 -0700 (PDT) ARC-Seal: i=2; a=rsa-sha256; t=1715789721; cv=pass; d=google.com; s=arc-20160816; b=lAVmYgnARpLWtELRC7azAzircxRjhQ1Z/yVBKvfbduRYlKmdyZzl+7B8Q9DtYuYFQ1 DRXB0EKP7DECRvfRE8GCFrVQNjf6nRzfk/8B9wC3xMPeOPknaLUvvQ96Ejhk2BJ2eS2O i+IqiNxvi9hpRvrXL2CmFf4B+K2voF786ufkDeUciR6KI0wUZ9fsRlkQQYdqh0IX/hMH FS0q3IsP8q+2rqc/mNHqqtcQVX4ieQZ7Dfyq4FR11nPpktpkgxqSjtmr9q0a+H0t/Q5/ /UGH0I6ZUp+12Hm6FNgBaYzsrvOeqNDTlMu8TfxeFeGjg3T4G+0DXoJsOB8HZsFQX3nv jeUg== ARC-Message-Signature: i=2; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:in-reply-to:content-disposition :mime-version:references:message-id:subject:cc:to:from:date:sender :dkim-signature; bh=XJ0qhxQiFGKib2bx2Lnm9svyLvdpWJ+hYjZ89W3EyVo=; fh=vblt4Lf9Q+axacZPiK5gAubOh5DCJ9savIEPff7xyD8=; b=0OLfJESE4peMLsIOJD8ZBa9dEbtRxXavF1E/BX2iwA6X606qX5qMmVoBfMiT2hNf1u uWJGO289MJw44rc0t2BffnSO/7alyCjLgLNWxiAO89VmN/vPpmakIjtRGBX3UDM94dwq EGJ/qU5eJuSe6VdBKpX22V25XnQ03dTCN7fkb0BLdJMUL51nvEEygV3PaHOS+/nE57AH KOSbSpjgHGLeE2nz7Htg83E7DRL4hNARuO82Dtj/OP5zh9WHMufBlUiFBGn/vGt+slzn Akqt0zBAQjx6BE+aU2kklWWN5jEi6es8TsIrwzTAct6Ikl/bxdocl9oedpehUqb/kIJA c+qw==; darn=gnusha.org ARC-Authentication-Results: i=2; gmr-mx.google.com; dkim=pass header.i=@reardencode.com header.s=mail header.b=BNloK1pU; spf=pass (google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1 as permitted sender) smtp.mailfrom=freedom@reardencode.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reardencode.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlegroups.com; s=20230601; t=1715789721; x=1716394521; darn=gnusha.org; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:sender:from:to:cc :subject:date:message-id:reply-to; bh=XJ0qhxQiFGKib2bx2Lnm9svyLvdpWJ+hYjZ89W3EyVo=; b=vJi2c7jCQeBGZWVgnsbkGeTsMwjgkjOSUIAoJLDGjOWFoJQdB9UuKgQT2cOsPBbZgo MuUvY3PZ5YszevQSVxnITz2mIU8xF0iNOtuOIkROZDmnxA21g+5xatQvVOqRgHo31rmt QxFoU1KGApmp1XphDOnrubDc1ErlXjiqN4CePNW5zNbSR5m+SyEgbwflYmFowqZRQFrH y1nkLqDHlApmh8VvQ0eBxQfgtBQQzA+Z8ktLIJzBx1jEyU1WTLPbmgxI2fneBLUKQ9f7 3oitzKMx6W9Q2Sr7Tb4b/+aOhLjKKCasT6semlDe02kB5LlwC0jFxpVs8ofL8ZAt12Jn /R+Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1715789721; x=1716394521; h=list-unsubscribe:list-subscribe:list-archive:list-help:list-post :list-id:mailing-list:precedence:x-original-authentication-results :x-original-sender:in-reply-to:content-disposition:mime-version :references:message-id:subject:cc:to:from:date:x-beenthere :x-gm-message-state:sender:from:to:cc:subject:date:message-id :reply-to; bh=XJ0qhxQiFGKib2bx2Lnm9svyLvdpWJ+hYjZ89W3EyVo=; b=Qo/2IU+X9ZcXPRL5Ngbb2c0Jhi/CsPIM8CZwKxOdxtqxM6nGY3Xwt9UB0VHv1kTrCQ k6vhegNJCoVbGlCJKqk+0CmziBcPZ9FzoPA1f+j3KsnyJ1aE4LIz9Lw3aeh8KCkcgzbC 5bdNhTm50LRKKigMAAbBvXKQ0tXtxvgA8QHqxwDQSVHnRLpeQbwmQ1t5NEYNiCNy7wRC NU3lnFU5T9EFCiAN2/Yyc/EzFh0b65sdAxb+NL5Qlr9b1VY9T6SEIxZalUsSGu+iUAqM fUalDhf6m63OzKvYPVGL0L19Cpwc401hshLxgUclNKZLRVmLFnx1fWnplW5Qp+HWUJag gGOQ== Sender: bitcoindev@googlegroups.com X-Forwarded-Encrypted: i=2; AJvYcCUk3IvnMVO2GXJHgqtiwU8IttHWf2v6FmtNa9yvVWzhzfx5ZOhyxl2RMbmI7dTUtTw5xbOoqVn2pqfjOyp4CtlHntKODoc= X-Gm-Message-State: AOJu0YyDmF1tRG+JIyn7FAhFKBhzvP/uLQgCzo6aZjMGmVCH7wpWHJw/ G12JhFAx4XrbVCj96c+vCMOMfHJE89cBr6hES7DbCwvOWm/h3hlc X-Google-Smtp-Source: AGHT+IH2CEVVgYTDQ9ws7VxnOhcc9XBxVMeXQPInr9UgIZAd43/MXwbqkpUl7DyI3Pr34y6q0T5qCA== X-Received: by 2002:a05:6870:351:b0:23c:1f34:730 with SMTP id 586e51a60fabf-24172f6a29dmr18689883fac.49.1715789720783; Wed, 15 May 2024 09:15:20 -0700 (PDT) X-BeenThere: bitcoindev@googlegroups.com Received: by 2002:a05:6870:b4a2:b0:23f:a7c6:8b with SMTP id 586e51a60fabf-2411690b160ls1756413fac.0.-pod-prod-09-us; Wed, 15 May 2024 09:15:19 -0700 (PDT) X-Received: by 2002:a05:6870:3928:b0:23e:a9ce:d2ba with SMTP id 586e51a60fabf-241728daf5emr127997fac.2.1715789719386; Wed, 15 May 2024 09:15:19 -0700 (PDT) Received: by 2002:a05:6808:178b:b0:3c9:9379:e100 with SMTP id 5614622812f47-3c996f35809msb6e; Tue, 14 May 2024 14:55:57 -0700 (PDT) X-Received: by 2002:a05:6a20:3c87:b0:1ad:7e4e:428d with SMTP id adf61e73a8af0-1afde0cd675mr18748848637.20.1715723756020; Tue, 14 May 2024 14:55:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1715723756; cv=none; d=google.com; s=arc-20160816; b=KoLj2rJfOGaF7iorOKafUlesBYlhydO/bNlVz0S20zNqGlM4qhB/9VFkudNor8eb3o iGTKiqA/pO1xm/Xp61ZuZ/ZB77Rt9NwbjYAG032/aE3jM5T44PnOk513W/BQNqqcsLDy R2lUAFTPNXZt6qXuKBAbjG4jyvakj16kYtMcD9nttlOJSujqCSPdL69U9WhDPv2zRTa4 I8J1rzeJKPHPUc/5HMzg6KoPrvmgrorLkYGjT2pIBJ3hWcufiNuZJ7ArfOASFoon8XLG fNvvvel5aWeP3Uo4xSGjBUUplYEKll3XWsGxvLMVtNdz3Gja0A9YDTP6ja62k9pU2BoN YNUg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:dkim-signature:date; bh=683ovLGBlojqFTov99K2WAjxztTqoW8a6iwLvfyQIwA=; fh=KeArRNdNZ+eyyjenzK10WGIwxM0PtlSJ2crjCld+h2U=; b=WIuvNhuhfzNa+JLE6DAZkFScx58qwW8APi+oghjuv3w0q5mVh8W2swEw5gl3ATFF7c sD2TGlrLuzJLITRlOYYd2b5m5tySpTXO/qHjk/0N1dWgcT/bh0fTmJbTugu4Mbo4Mvow d38pha8BNjLveP52pAEJy6du1wmV8BonJ7wpMGnbkX/lN/WCFK7irambtj8vQkidbr3+ gN7MFUBhP7B1JKa3+OBQxFBx5Hzw4TE2ipJp3MQA4K4ZMr7AeThDxBg/GbWSlydc77rj 7SRNkfHYoEYVLskOAxYgmALVoyBCVv7GfGTNKYcMtqLxYkBo4cePMrUrEbZqdDGqwriJ YwSQ==; dara=google.com ARC-Authentication-Results: i=1; gmr-mx.google.com; dkim=pass header.i=@reardencode.com header.s=mail header.b=BNloK1pU; spf=pass (google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1 as permitted sender) smtp.mailfrom=freedom@reardencode.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reardencode.com Received: from mail.reardencode.com ([2607:f2f8:ad40:ea11::1]) by gmr-mx.google.com with ESMTPS id 41be03b00d2f7-64afe0914f0si178874a12.5.2024.05.14.14.55.55 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 14 May 2024 14:55:55 -0700 (PDT) Received-SPF: pass (google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1 as permitted sender) client-ip=2607:f2f8:ad40:ea11::1; Date: Tue, 14 May 2024 14:55:20 -0700 From: Brandon Black To: bitcoindev@googlegroups.com Cc: j@rubin.io Subject: Re: [bitcoindev] BIP for OP_CHECKSIGFROMSTACK Message-ID: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 6.1.74 x86_64 X-Original-Sender: freedom@reardencode.com X-Original-Authentication-Results: gmr-mx.google.com; dkim=pass header.i=@reardencode.com header.s=mail header.b=BNloK1pU; spf=pass (google.com: domain of freedom@reardencode.com designates 2607:f2f8:ad40:ea11::1 as permitted sender) smtp.mailfrom=freedom@reardencode.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=reardencode.com Precedence: list Mailing-list: list bitcoindev@googlegroups.com; contact bitcoindev+owners@googlegroups.com List-ID: X-Google-Group-Id: 786775582512 List-Post: , List-Help: , List-Archive: , List-Unsubscribe: , X-Spam-Score: -0.8 (/) Hello list, Two considerations for this BIP that I'd love thoughts on: # Should this include an implementation of CHECKSIGFROMSTACKADD? I had been inclined to leave it out since it can be implemented using a few opcodes and the altstack, but upon seeing some of the advanced miniscripting that Rob Hamilton showed in his talk in ATX, I can see that CSFSA would potentially be more commonly used than I had previously realized. I'm inclined to add CSFSA and use another SUCCESS. # Should CHECKSIGFROMSTACKVERIFY be switched to tapscript only? Given that I intended this partly to be used with BIP119 and CTV is a NOP upgrade and available in legacy scripts, I had included CSFSV as a NOP, but I'm curious to hear other opinions on this. Thanks kindly, --Brandon On 2024-04-24 (Wed) at 22:12:52 -0700, Brandon Black wrote: > Hello list, > > Back in 2021, Jeremy wrote[0] about bringing OP_CHECKSIGFROMSTACK (or > OP_CHECKDATASIG) to bitcoin. That email proposed adopting the > specification from Bitcoin Cash for Bitcoin, but it is not directly > suitable, as it verifies DER encoded ECDSA signatures and not R||S > encoded BIP340 Schnorr signatures. The BIP here included, and proposed > for the BIPs repository[2] is a bitcoin-specific design for > OP_CHECKSIGFROMSTACK and OP_CHECKSIGFROMSTACKVERIFY. It further differs > from Jeremy's email by specifying the repurposing of a NOP (NOP5) for > OP_CHECKSIGFROMSTACKVERIFY to bring data signature verification to all > script types, not only tapscript (although this is subject to > change)[1]. > > ----------- > ## Abstract > > This BIP describes two new opcodes for the purpose of checking > cryptographic signatures in bitcoin scripts against data other than > bitcoin transactions. > > ## Summary > > We propose replacing `OP_NOP5` (0xb4) in bitcoin script with > `OP_CHECKSIGFROMSTACKVERIFY`. When verifying taproot script spends > having leaf version 0xc0 (as defined in [BIP 342]), we propose > `OP_CHECKSIGFROMSTACK` to replace `OP_SUCCESS204` (0xcc). > > `OP_CHECKSIGFROMSTACK` and `OP_CHECKSIGFROMSTACKVERIFY` have semantics > similar to `OP_CHECKSIG` and `OP_CHECKSIGVERIFY` respectively, as > specified below. > > Only 32-byte keys are constrained. Similar to [BIP 341] unknown key > types, for other key lengths no signature verification is performed. > > ## Specification > > * If fewer than 3 elements are on the stack, the script MUST fail and > terminate immediately. > * The public key (top element), message (second to top element), and > signature (third from top element) are read from the stack. > * For `OP_CHECKSIGFROMSTACK` the top three elements are popped from the > stack. > * If the public key size is zero, the script MUST fail and terminate > immediately. > * If the public key size is 32 bytes, it is considered to be a public > key as described in [BIP 340]: > * If the signature is not the empty vector, the signature is > validated against the public key and message according to [BIP > 340]. Validation failure in this case immediately terminates > script execution with failure. > * If the public key size is not zero, and it is not a [BIP 340] public > key; the public key is of an unknown public key type, and no actual > signature verification is applied. During script execution of > signature opcodes they behave exactly as known public key types except > that signature validation is considered to be successful. > * If the script did not fail and terminate before this step, regardless > of the public key type: > * If the signature is the empty vector: > * For `OP_CHECKSIGFROMSTACKVERIFY`, the script MUST fail and > terminate immediately. > * For `OP_CHECKSIGFROMSTACK`, an empty vector is pushed onto the > stack, and execution continues with the next opcode. > * If the signature is not the empty vector: > * For tapscript 0xc0, the opcode is counted towards the sigops > budget as described in [BIP 342]. > * For legacy and segwit v0, the opcode is counted towards the > sigops limit, as described in [BIP 141] > * For `OP_CHECKSIGFROMSTACKVERIFY`, execution continues without > any further changes to the stack. > * For `OP_CHECKSIGFROMSTACK`, a 1-byte value 0x01 is pushed onto > the stack. > > ## Design Considerations > > 1. Message hashing: [BIP 340] is compatible with any size of message and > does not require it to be a securely hashed input, so the message is > not hashed prior to [BIP 340] verification. > 2. Verify NOP upgrade: To bring stack signature verification to legacy > and segwitv0 bitcoin script, a NOP upgrade path was chosen for > `OP_CHECKSIGFROMSTACKVERIFY`. This necessarily means leaving the 3 > arguments on the stack when executing `OP_CHECKSIGFROMSTACKVERIFY`. > Scripts will need to drop or otherwise manage these stack elements. > 3. Add/multisig: No concession is made to `OP_CHECKMULTISIG` or > `OP_CHECKSIGADD` semantics with `OP_CHECKSIGFROMSTACK(VERIFY)`. In > Tapscript, add semantics can be implemented with 1 additional vByte > per key (`OP_TOALTSTACK OP_CHECKSIGFROMSTACK OP_FROMALTSTACK > OP_ADD`). > 4. Splitting R/S on the stack: Implementing split/separate signatures is > left as an exercise for other bitcoin upgrades, such as `OP_CAT`. > 5. [BIP 118]-style Taproot internal key: Rather than introducing an > additional key type in this change, we suggest implementing > OP_INTERNALKEY or separately introducing that key type for all > Tapscript signature checking operations in a separate change. > 6. Unknown key lengths: The semantics of other signature checking > opcodes in their respective script types (legacy, segwit-v0, > tapscript-c0) are applied. > > ## Resource Limits > > These opcodes are treated identically to other signature checking > opcodes and count against the various sigops limits and budgets in their > respective script types. > > ## Motivation > > ### LN Symmetry > > When combined with [BIP 119] (`OP_CHECKTEMPLATEVERIFY`/CTV), > `OP_CHECKSIGFROMSTACK` (CSFS) can be used in Lightning Symmetry > channels. The construction `OP_CHECKTEMPLATEVERIFY > OP_CHECKSIGFROMSTACK` with a spend stack containing the CTV hash and a > signature for it is logically equivalent to ` > OP_CHECKSIG` and a signature over > `SIGHASH_ALL|SIGHASH_ANYPREVOUTANYSCRIPT`. The `OP_CHECKSIGFROMSTACK` > construction is 8 vBytes larger. > > ### Delegation > > Using a script like: ` SWAP IF 2 PICK SWAP CSFSV ENDIF CHECKSIG` > either direct verification or delegation can be achieved by the > following unlock stacks: ` 0` or ` 1` > > ## Reference Implementation > > A reference implementation is provided in provided here: > > https://github.com/bitcoin/bitcoin/pull/29270 > > ## Backward Compatibility > > By constraining the behavior of an OP_SUCCESS opcode and an OP_NOP > opcode, deployment of the BIP can be done in a backwards compatible, > soft-fork manner. If anyone were to rely on the OP_SUCCESS behavior of > `OP_SUCCESS204`, `OP_CHECKSIGFROMSTACK` would invalidate their spend. > > ## Deployment > > TBD > > ## Credits > > Reference implementation was made with reference to the implementation > in Elements and started by moonsettler. > > ## Copyright > > This document is licensed under the 3-clause BSD license. > > [BIP 119]: https://github.com/bitcoin/bips/blob/master/bip-0119.mediawiki > > [BIP 118]: https://github.com/bitcoin/bips/blob/master/bip-0118.mediawiki > > [BIP 340]: https://github.com/bitcoin/bips/blob/master/bip-0340.mediawiki > > [BIP 341]: https://github.com/bitcoin/bips/blob/master/bip-0341.mediawiki > > [BIP 342]: https://github.com/bitcoin/bips/blob/master/bip-0342.mediawiki > > [OP_CAT]: https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki > > ----------- > > [0]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-July/019192.html > [1]: https://github.com/bitcoin/bips/pull/1535#discussion_r1578562450 > [2]: https://github.com/bitcoin/bips/pull/1535 > > > -- > --Brandon > > -- > You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. > To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. > To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZinmVPFt9VQn8QLF%40console. -- You received this message because you are subscribed to the Google Groups "Bitcoin Development Mailing List" group. To unsubscribe from this group and stop receiving emails from it, send an email to bitcoindev+unsubscribe@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/bitcoindev/ZkPdyMzR3DKkUlQd%40console.