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
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
|
Return-Path: <tim.ruffing@mmci.uni-saarland.de>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
[172.17.192.35])
by mail.linuxfoundation.org (Postfix) with ESMTPS id 4320B907
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Nov 2016 14:45:37 +0000 (UTC)
X-Greylist: delayed 00:09:37 by SQLgrey-1.7.6
Received: from hera.mpi-klsb.mpg.de (hera.mpi-klsb.mpg.de [139.19.1.49])
by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 6E484136
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 4 Nov 2016 14:45:35 +0000 (UTC)
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed;
d=mmci.uni-saarland.de; s=mail200803;
h=Content-Transfer-Encoding:Mime-Version:Content-Type:References:In-Reply-To:Date:To:From:Subject:Message-ID;
bh=EevN4zwv4vXXx7tWDTR6a+R+xE+YB3tiLXixzGSafaM=;
b=MDwqaVm8YiClaRWdwAH7cuNzyS3NMjs19uj79o4eqYM2HS3G0znDb/7gSGuJFPo5tWCXQD6YFb525DdSYHNK4kbufwI3pCgGy46X9rcoLNQXfXmG7vN43fkNjdIm5fn6TWvWfPw0//1YdZRXqhnznWFyvmOl/MbpL7ssjSwukvM=;
Received: from vrt-00-414.mpi-klsb.mpg.de ([139.19.1.27]:51906
helo=tentacle.mpi-klsb.mpg.de) by hera.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtps (TLS1.2:DHE_RSA_AES_128_CBC_SHA1:128)
(Exim 4.80) id 1c2fay-0000rr-7v
for bitcoin-dev@lists.linuxfoundation.org;
Fri, 04 Nov 2016 15:35:55 +0100
Received: from mbpc39.cs.uni-saarland.de ([134.96.225.150]:34820)
by tentacle.mpi-klsb.mpg.de (envelope-from
<tim.ruffing@mmci.uni-saarland.de>)
with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256)
(Exim 4.80) id 1c2fay-0005Wv-08
for bitcoin-dev@lists.linuxfoundation.org;
Fri, 04 Nov 2016 15:35:52 +0100
Message-ID: <1478270151.1662.6.camel@mmci.uni-saarland.de>
From: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>
To: bitcoin-dev@lists.linuxfoundation.org
Date: Fri, 04 Nov 2016 15:35:51 +0100
In-Reply-To: <CAD438HsZRZcRWu=++3kuvyA5Ns9cU360utJMCyc6bROT-fdcHg@mail.gmail.com>
References: <CAMZUoKkG0AqwsTE=opTcsD=xqWsoVxqPVCzFbcSz8zJT1wiFPg@mail.gmail.com>
<E8BB95A5-09B3-443C-B197-29DA3C4767D8@xbt.hk>
<CAMZUoKmnkk=q7GkkvA+Q4-r64JCQ+kPRPdoEN8bnAwd2YGMH+Q@mail.gmail.com>
<CAD438HsZRZcRWu=++3kuvyA5Ns9cU360utJMCyc6bROT-fdcHg@mail.gmail.com>
Content-Type: text/plain; charset="UTF-8"
X-Mailer: Evolution 3.22.2
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
X-MPI-Local-Sender: true
X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,DKIM_SIGNED,
DKIM_VALID, DKIM_VALID_AU, RCVD_IN_DNSWL_MED 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: Fri, 04 Nov 2016 14:48:28 +0000
Subject: Re: [bitcoin-dev] Implementing Covenants with
OP_CHECKSIGFROMSTACKVERIFY
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Bitcoin Protocol 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: Fri, 04 Nov 2016 14:45:37 -0000
Not a covenant but interesting nevertheless: _One_ of OP_CAT and
OP_CHECKSIGFROMSTACKVERIFY alone is enough to implement "opt-in miner
takes double-spend" [1]:
You can create an output, which is spendable by everybody if you ever
double-spend the output with two different transactions. Then the next
miner will probably take your money (double-spending against your two
or more contradicting transactions again).
If you spend such an output, then the recipient may be willing to
accept a zero-conf transaction, because he knows that you'll lose the
money when you attempt double-spending (unless you are the lucky
miner). See the discussion in [1] for details.
The implementation using OP_CHECKSIGFROMSTACKVERIFY is straight-
forward. You add a case to the script which allows spending if two
valid signatures on different message under the public key of the
output are given.
What is less known I think:
The same functionality can be achieved in a simpler way just using
OP_CAT, because it's possible to turn Bitcoin's ECDSA to an "opt-in
one-time signature scheme". With OP_CAT, you can create an output that
is only spendable using a signature (r,s) with a specific already fixed
first part r=x_coord(kG). Basically, the creator of this output commits
on r (and k) already when creating the output. Now, signing two
different transaction with the same r allows everybody to extract the
secret key from the two signatures.
The drawbacks of the implementation with OP_CAT is that it's not
possible to make a distinction between legitimate or illegitimate
double-spends (yet to be defined) but just every double-spend is
penalized. Also, it's somewhat hackish and the signer must store k (or
create it deterministically but that's a good idea anyway).
[1] https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg07122.html
Best,
Tim
On Thu, 2016-11-03 at 07:37 +0000, Daniel Robinson via bitcoin-dev
wrote:
> Really cool!
>
> How about "poison transactions," the other covenants use case
> proposed by Möser, Eyal, and Sirer? (I think
> OP_CHECKSIGFROMSTACKVERIFY will also make it easier to check fraud
> proofs, the other prerequisite for poison transactions.)
>
> Seems a little wasteful to do those two "unnecessary" signature
> checks, and to have to construct the entire transaction data
> structure, just to verify a single output in the transaction. Any
> plans to add more flexible introspection opcodes to Elements, such as
> OP_CHECKOUTPUTVERIFY?
>
> Really minor nit: "Notice that we have appended 0x83 to the end of
> the transaction data"—should this say "to the end of the signature"?
>
> On Thu, Nov 3, 2016 at 12:28 AM Russell O'Connor via bitcoin-dev <bit
> coin-dev@lists.linuxfoundation.org> wrote:
> > Right. There are minor trade-offs to be made with regards to that
> > design point of OP_CHECKSIGFROMSTACKVERIFY. Fortunately this
> > covenant construction isn't sensitive to that choice and can be
> > made to work with either implementation of
> > OP_CHECKSIGFROMSTACKVERIFY.
> >
> > On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau <jl2012@xbt.hk> wrote:
> > > Interesting. I have implemented OP_CHECKSIGFROMSTACKVERIFY in a
> > > different way from the Elements. Instead of hashing the data on
> > > stack, I directly put the 32 byte hash to the stack. This should
> > > be more flexible as not every system are using double-SHA256
> > >
> > > https://github.com/jl2012/bitcoin/commits/mast_v3_master
> > >
> > >
> > >
> > > > On 3 Nov 2016, at 01:30, Russell O'Connor via bitcoin-dev <bitc
> > > > oin-dev@lists.linuxfoundation.org> wrote:
> > > >
> > > > Hi all,
> > > >
> > > > It is possible to implement covenants using two script
> > > > extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY. Both of
> > > > these op codes are already available in the Elements Alpha
> > > > sidechain, so it is possible to construct covenants in Elements
> > > > Alpha today. I have detailed how the construction works in a
> > > > blog post at <https://blockstream.com/2016/11/02/covenants-in-e
> > > > lements-alpha.html>. As an example, I've constructed scripts
> > > > for the Moeser-Eyal-Sirer vault.
> > > >
> > > > I'm interested in collecting and implementing other useful
> > > > covenants, so if people have ideas, please post them.
> > > >
> > > > If there are any questions, I'd be happy to answer.
> > > >
> > > > --
> > > > Russell O'Connor
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
|
