1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
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
|
