diff options
| author | Anthony Towns <aj@erisian.com.au> | 2015-11-30 09:41:43 +1000 |
|---|---|---|
| committer | bitcoindev <bitcoindev@gnusha.org> | 2015-11-29 23:41:51 +0000 |
| commit | d09a9b6b1aef2191fbe31ac693b94d5e6b932a9e (patch) | |
| tree | f6826fc6672b3f0002449390541067ae943aa486 | |
| parent | df83c88a2c90931cc8da7b772d29ac9de38b3158 (diff) | |
| download | pi-bitcoindev-d09a9b6b1aef2191fbe31ac693b94d5e6b932a9e.tar.gz pi-bitcoindev-d09a9b6b1aef2191fbe31ac693b94d5e6b932a9e.zip | |
Re: [bitcoin-dev] [BIP] OP_CHECKPRIVPUBPAIR
| -rw-r--r-- | aa/e93821cd98c88a3a8fb1b5c6e595a8bc2db3de | 104 |
1 files changed, 104 insertions, 0 deletions
diff --git a/aa/e93821cd98c88a3a8fb1b5c6e595a8bc2db3de b/aa/e93821cd98c88a3a8fb1b5c6e595a8bc2db3de new file mode 100644 index 000000000..2abd4efb8 --- /dev/null +++ b/aa/e93821cd98c88a3a8fb1b5c6e595a8bc2db3de @@ -0,0 +1,104 @@ +Return-Path: <aj@erisian.com.au> +Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org + [172.17.192.35]) + by mail.linuxfoundation.org (Postfix) with ESMTPS id D867B85 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 29 Nov 2015 23:41:51 +0000 (UTC) +X-Greylist: from auto-whitelisted by SQLgrey-1.7.6 +Received: from azure.erisian.com.au (cerulean.erisian.com.au [106.187.51.212]) + by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E6BF89 + for <bitcoin-dev@lists.linuxfoundation.org>; + Sun, 29 Nov 2015 23:41:51 +0000 (UTC) +Received: from aj@azure.erisian.com.au (helo=sapphire.erisian.com.au) + by azure.erisian.com.au with esmtpsa (Exim 4.84 #2 (Debian)) + id 1a3BbI-0002ac-6U; Mon, 30 Nov 2015 09:41:49 +1000 +Received: by sapphire.erisian.com.au (sSMTP sendmail emulation); + Mon, 30 Nov 2015 09:41:43 +1000 +Date: Mon, 30 Nov 2015 09:41:43 +1000 +From: Anthony Towns <aj@erisian.com.au> +To: bitcoin-dev@lists.linuxfoundation.org +Message-ID: <20151129234143.GA21152@sapphire.erisian.com.au> +References: <CAE8CtVmqT0L74+xyEh-fn9vDcudBuMvgSr39DBVFopXbKyvNcA@mail.gmail.com> +MIME-Version: 1.0 +Content-Type: text/plain; charset=us-ascii +Content-Disposition: inline +In-Reply-To: <CAE8CtVmqT0L74+xyEh-fn9vDcudBuMvgSr39DBVFopXbKyvNcA@mail.gmail.com> +User-Agent: Mutt/1.5.24 (2015-08-30) +X-Spam-Score: -1.9 +X-Spam-Score-int: -18 +X-Spam-Bar: - +X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,T_RP_MATCHES_RCVD, + UNPARSEABLE_RELAY 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: Mon, 30 Nov 2015 01:35:58 +0000 +Subject: Re: [bitcoin-dev] [BIP] OP_CHECKPRIVPUBPAIR +X-BeenThere: bitcoin-dev@lists.linuxfoundation.org +X-Mailman-Version: 2.1.12 +Precedence: list +List-Id: Bitcoin Development Discussion <bitcoin-dev.lists.linuxfoundation.org> +List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe> +List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/> +List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org> +List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help> +List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>, + <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe> +X-List-Received-Date: Sun, 29 Nov 2015 23:41:52 -0000 + +On Fri, Nov 27, 2015 at 09:02:37AM +0100, Mats Jerratsch via bitcoin-dev wrote: +> <private key> <public key> OP_CHECKPRIVPUBPAIR +> As there are requests for all sort of general crypto operations in +> script, we can also introduce a new general OP_CRYPTO and prepend one +> byte for the operation, so +> 0x01 OP_CRYPTO = OP_CHECKPRIVPUBPAIR +> 0x02-0xff OP_CRYPTO = OP_NOP +> to allow for extension at some later point. + +This wouldn't be a softfork -- a single prefixed 0x01 byte would just +push "OP_CRYPTO" onto the stack... If you had OP_CRYPTO look at the top +item on the stack to determine what to do, you could have: + + OP_[0-16] OP_CRYPTO + OP_PUSHDATA1 [0x11-0xFF] OP_CRYPTO + OP_PUSHDATA2 [0x00-0xFF] [0x01-0xFF] OP_CRYPTO + ... + +to get 17 different crypto ops in two bytes, and the next 238 in three, +and be arbitrarily expandable from there with multibyte pushes. + +> Alternatives: +> In the attached discussion there are some constructions that would +> allow breaking the signature scheme, but they are either very large in +> script language or expensive to calculate. + +I think that's good enough to try them out in prototypes though -- and +presumably if they're demonstrably useful in prototypes that's a good +argument for adding a dedicated op code to script? + +Are there any other crypto ops that might be worth adding into a BIP for +a check-verify crypto toolkit op like this? The only ones that come to mind +as having practical uses in the near term are: + + Base-point multiply on secp256k1 (ie, CHECKPUBPRIVPAIR) + Schnorr-signature of transaction with secp256k1 curve (smaller, + faster, more-anonymous N-of-N multisig) + +But perhaps there's also uses for some of: + + General point addition on secp256k1 + General point multiply on secp256k1 + SHA3-256 / SHA2-512 / SHA3-512 + ECDSA/Schnorr signature of value from stack + ...? + +Then again, I gather that if the segregated witness soft-fork turns out +to be plausible, re-enabling/changing/adding *any* sort of opcode could +be done as a soft-fork, not just turning a NOP into CHECK_foo_VERIFY... +So it might be better to wait and see how that goes before putting too +much time into drafting a BIP or similar? + +Cheers, +aj + + |