path: root/6d/24159dbd17e38ed5bec24c61afcf3771534b08

Return-Path: <jlrubin@mit.edu>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id B4C975B1
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  7 Nov 2016 19:30:51 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.7.6
Received: from dmz-mailsec-scanner-2.mit.edu (dmz-mailsec-scanner-2.mit.edu
	[18.9.25.13])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 535491CB
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon,  7 Nov 2016 19:30:50 +0000 (UTC)
X-AuditID: 1209190d-833ff70000007d9e-2c-5820d66852b1
Received: from mailhub-auth-3.mit.edu ( [18.9.21.43])
	(using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits))
	(Client did not present a certificate)
	by  (Symantec Messaging Gateway) with SMTP id 3F.CE.32158.866D0285;
	Mon,  7 Nov 2016 14:30:49 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11])
	by mailhub-auth-3.mit.edu (8.13.8/8.9.2) with ESMTP id uA7JUmU5022545
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 7 Nov 2016 14:30:48 -0500
Received: from mail-it0-f47.google.com (mail-it0-f47.google.com
	[209.85.214.47]) (authenticated bits=0)
	(User authenticated as jlrubin@ATHENA.MIT.EDU)
	by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id uA7JUkEd032248
	(version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT)
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 7 Nov 2016 14:30:47 -0500
Received: by mail-it0-f47.google.com with SMTP id u205so150013778itc.0
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Mon, 07 Nov 2016 11:30:47 -0800 (PST)
X-Gm-Message-State: ABUngvfMZYxlxzUpHkUeqFIH9/J8x9pxmtos3Uf9xPsSjLp+1RLvr6u/4Z8WmZOCw+lF0PNQe+BNlucqqCN2TQ==
X-Received: by 10.36.28.204 with SMTP id c195mr2290708itc.81.1478547046799;
	Mon, 07 Nov 2016 11:30:46 -0800 (PST)
MIME-Version: 1.0
Received: by 10.36.129.132 with HTTP; Mon, 7 Nov 2016 11:30:26 -0800 (PST)
In-Reply-To: <1478270151.1662.6.camel@mmci.uni-saarland.de>
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>
	<1478270151.1662.6.camel@mmci.uni-saarland.de>
From: Jeremy <jlrubin@mit.edu>
Date: Mon, 7 Nov 2016 11:30:26 -0800
X-Gmail-Original-Message-ID: <CAD5xwhhstv4w+81FrQ+W7W9gCTpN92vhSL95QNCHkHNFwJ7DQQ@mail.gmail.com>
Message-ID: <CAD5xwhhstv4w+81FrQ+W7W9gCTpN92vhSL95QNCHkHNFwJ7DQQ@mail.gmail.com>
To: Tim Ruffing <tim.ruffing@mmci.uni-saarland.de>,
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary=001a113bc72a82297a0540bb0fd6
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNKsWRmVeSWpSXmKPExsUixCmqrZt5TSHC4H4Lj0XTa1sHRo/fPyYz
	BjBGcdmkpOZklqUW6dslcGU87rrNWtAwgbFi/YebLA2Mr6u7GDk4JARMJP7OyOxi5OIQEmhj
	klj77DszhHOHUWL+hf9sEM4HJonFex+wQDiLGCWm975l72LkBGrPkZj+dTMLhF0s8ff4K1YQ
	m1dAUOLkzCdgcSEBL4m3DR1gcU4Ba4kPx+4yQQzazSTxbds8dpA72ATkJD78MgWpYRFQkViy
	9j0jxMxEifaPL9khZgZIfLjVwgJSLiwQKHHukzdIWESggVHi/6x8EJsZaNWxhdMYJzAKzUJy
	xSwkqVlA3cwC6hLr5wlBhLUlli18zQxhq0nc3naVHVl8ASPbKkbZlNwq3dzEzJzi1GTd4uTE
	vLzUIl0jvdzMEr3UlNJNjOBYkOTdwfjvrtchRgEORiUe3gm9ChFCrIllxZW5hxglOZiURHlT
	NgGF+JLyUyozEosz4otKc1KLDzFKcDArifDaXQXK8aYkVlalFuXDpKQ5WJTEef+7fQ0XEkhP
	LEnNTk0tSC2CycpwcChJ8GqANAoWpaanVqRl5pQgpJk4OEGG8wANv3gFZHhxQWJucWY6RP4U
	oz3Hg5PPHzBxvPrwAkjumfUKSHZ8+PCASYglLz8vVUqcdxpImwBIW0ZpHtxkUJq7GHpN/xWj
	ONCjwrwNIAfwAFMk3OxXQGuZgNZWxYCtLUlESEk1MOqtfDZzybXYCwdPfTklvcWtlWH7kx/P
	P99O/Ne32KW+8zybjZjQjU0PthfbyMwqmr8zsPDFoezX7sFTAgvV81vltkix9L0I/WZ9/9rW
	WdWSx/VX7ZJKTIpu+OFusXClxK0fTV4rRN88654f4++1vqzuSHjkyS8ef2Jbm8Pu5qzk3Hx1
	qrrPF2MlluKMREMt5qLiRAD8O3SLTgMAAA==
X-Spam-Status: No, score=-6.6 required=5.0 tests=BAYES_00,HTML_MESSAGE,
	RCVD_IN_DNSWL_MED,RCVD_IN_SORBS_SPAM,RP_MATCHES_RCVD autolearn=ham
	version=3.3.1
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on
	smtp1.linux-foundation.org
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: Mon, 07 Nov 2016 19:30:51 -0000

--001a113bc72a82297a0540bb0fd6
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

I think
=E2=80=8Bthe following implementation may be advantageous. It uses the same=
 number
of opcodes, without OP_CAT.

Avoiding use of OP_CAT is still desirable as I think it will be difficult
to agree on semantics for OP_CAT (given necessary measures to prevent
memory abuse) than for OP_LEFT. Another option I would be in support of
would be to have signature flags apply to OP_CHECKSIGFROMSTACK and all
OP_CHECKSIG flags be ignored if they aren't meaningful...

=E2=80=8B


























*<signature; SIGHASH_ALL><signatureTxnData>1. <pubkey>
OP_DUP3<pubkey><signature;
SIGHASH_ALL><signatureTxnData><pubkey><signature;
SIGHASH_ALL><signatureTxnData>2.
OP_CHECKSIGVERIFY<signatureTxnData><pubkey><signature;
SIGHASH_ALL><signatureTxnData>3. OP_SHA256 OP_ROT OP_SIZE OP_SUB1
OP_LEFT<signature><sha256(signatureTxnData)><pubkey><signatureTxnData>4.
OP_SWAP OP_ROT OP_CHECKSIGFROMSTACK=E2=80=8BVERIFY=E2=80=8B (with same =E2=
=80=8Bargument order=E2=80=8B)=E2=80=8B*



--
@JeremyRubin <https://twitter.com/JeremyRubin>
<https://twitter.com/JeremyRubin>

On Fri, Nov 4, 2016 at 7:35 AM, Tim Ruffing via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 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=3Dx_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=C3=B6ser, 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"=E2=80=94should this say "to the end of the signat=
ure"?
> >
> > 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
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--001a113bc72a82297a0540bb0fd6
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_default" style=3D"font-family:arial,he=
lvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I think=C2=A0<div clas=
s=3D"gmail_default" style=3D"display:inline">=E2=80=8Bthe following impleme=
ntation may be advantageous. It uses the same number of opcodes, without OP=
_CAT.</div><div><div class=3D"gmail_default" style=3D"display:inline"><br><=
/div></div><div><div class=3D"gmail_default" style=3D"display:inline">Avoid=
ing use of OP_CAT is still desirable as I think it will be difficult to agr=
ee on semantics for OP_CAT (given necessary measures to prevent memory abus=
e) than for OP_LEFT. Another option I would be in support of would be to ha=
ve signature flags apply to OP_CHECKSIGFROMSTACK and all OP_CHECKSIG flags =
be ignored if they aren&#39;t meaningful...</div><div style=3D"color:rgb(34=
,34,34);font-family:arial,sans-serif;font-size:13px"><br></div><div style=
=3D"color:rgb(34,34,34);font-family:arial,sans-serif;font-size:13px"><div c=
lass=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-serif;font=
-size:small;color:rgb(0,0,0)">=E2=80=8B</div><br><i>&lt;signature; SIGHASH_=
ALL&gt;<br>&lt;signatureTxnData&gt;<br><br>1. &lt;pubkey&gt; OP_DUP3<br>&lt=
;pubkey&gt;<br>&lt;signature; SIGHASH_ALL&gt;<br>&lt;signatureTxnData&gt;<b=
r>&lt;pubkey&gt;<br>&lt;signature; SIGHASH_ALL&gt;<br>&lt;signatureTxnData&=
gt;<br><br>2. OP_CHECKSIGVERIFY<br><br>&lt;signatureTxnData&gt;<br>&lt;pubk=
ey&gt;<br>&lt;signature; SIGHASH_ALL&gt;<br>&lt;signatureTxnData&gt;<br><br=
>3. OP_SHA256 OP_ROT OP_SIZE OP_SUB1 OP_LEFT<br><br>&lt;signature&gt;<br>&l=
t;sha256(signatureTxnData)&gt;<br>&lt;pubkey&gt;<br>&lt;signatureTxnData&gt=
;<br><br>4. OP_SWAP OP_ROT OP_CHECKSIGFROMSTACK<div class=3D"gmail_default"=
 style=3D"font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(=
0,0,0);display:inline">=E2=80=8BVERIFY=E2=80=8B</div>=C2=A0(with same=C2=A0=
<div class=3D"gmail_default" style=3D"font-family:arial,helvetica,sans-seri=
f;font-size:small;color:rgb(0,0,0);display:inline">=E2=80=8Bargument</div>=
=C2=A0order<div class=3D"gmail_default" style=3D"font-family:arial,helvetic=
a,sans-serif;font-size:small;color:rgb(0,0,0);display:inline">=E2=80=8B)=E2=
=80=8B</div></i></div><div><i><div class=3D"gmail_default" style=3D"font-fa=
mily:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0);display:in=
line"><br></div></i></div><div class=3D"gmail_extra" style=3D"color:rgb(34,=
34,34);font-family:arial,sans-serif;font-size:13px"><div class=3D"gmail-m_-=
6598423716298820742gmail_signature"></div></div></div></div></div><div clas=
s=3D"gmail_extra"><br clear=3D"all"><div><br clear=3D"all"><div><div class=
=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr">--=
<br><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank">@JeremyRu=
bin</a><a href=3D"https://twitter.com/JeremyRubin" target=3D"_blank"></a></=
div></div></div>
</div>
<br><div class=3D"gmail_quote">On Fri, Nov 4, 2016 at 7:35 AM, Tim Ruffing =
via bitcoin-dev <span dir=3D"ltr">&lt;<a href=3D"mailto:bitcoin-dev@lists.l=
inuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.org=
</a>&gt;</span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margin=
:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Not a covenant but=
 interesting nevertheless: _One_ of OP_CAT and<br>
OP_CHECKSIGFROMSTACKVERIFY alone is enough to implement &quot;opt-in miner<=
br>
takes double-spend&quot; [1]:<br>
<br>
You can create an output, which is spendable by everybody if you ever<br>
double-spend the output with two different transactions. Then the next<br>
miner will probably take your money (double-spending against your two<br>
or more contradicting transactions again).<br>
<br>
If you spend such an output, then the recipient may be willing to<br>
accept a zero-conf transaction, because he knows that you&#39;ll lose the<b=
r>
money when you attempt double-spending (unless you are the lucky<br>
miner). See the discussion in [1] for details.<br>
<br>
The implementation using OP_CHECKSIGFROMSTACKVERIFY is straight-<br>
forward. You add a case to the script which allows spending if two<br>
valid signatures on different message under the public key of the<br>
output are given.<br>
<br>
What is less known I think:<br>
The same functionality can be achieved in a simpler way just using<br>
OP_CAT, because it&#39;s possible to turn Bitcoin&#39;s ECDSA to an &quot;o=
pt-in<br>
one-time signature scheme&quot;. With OP_CAT, you can create an output that=
<br>
is only spendable using a signature (r,s) with a specific already fixed<br>
first part r=3Dx_coord(kG). Basically, the creator of this output commits<b=
r>
on r (and k) already when creating the output. Now, signing two<br>
different transaction with the same r allows everybody to extract the<br>
secret key from the two signatures.<br>
<br>
The drawbacks of the implementation with OP_CAT is that=C2=A0it&#39;s not<b=
r>
possible to make a distinction between legitimate or illegitimate<br>
double-spends (yet to be defined) but just every double-spend is<br>
penalized. Also, it&#39;s somewhat hackish and the signer must store k (or<=
br>
create it deterministically but that&#39;s a good idea anyway).<br>
<br>
[1] <a href=3D"https://www.mail-archive.com/bitcoin-development@lists.sourc=
eforge.net/msg07122.html" rel=3D"noreferrer" target=3D"_blank">https://www.=
mail-archive.com/<wbr>bitcoin-development@lists.<wbr>sourceforge.net/msg071=
22.html</a><br>
<br>
Best,<br>
Tim<br>
<br>
On Thu, 2016-11-03 at 07:37 +0000, Daniel Robinson via bitcoin-dev<br>
wrote:<br>
<div class=3D"HOEnZb"><div class=3D"h5">&gt; Really cool!<br>
&gt;<br>
&gt; How about &quot;poison transactions,&quot; the other covenants use cas=
e<br>
&gt; proposed by M=C3=B6ser, Eyal, and Sirer? (I think<br>
&gt; OP_CHECKSIGFROMSTACKVERIFY will also make it easier to check fraud<br>
&gt; proofs, the other prerequisite for poison transactions.)<br>
&gt;<br>
&gt; Seems a little wasteful to do those two &quot;unnecessary&quot; signat=
ure<br>
&gt; checks, and to have to construct the entire transaction data<br>
&gt; structure, just to verify a single output in the transaction. Any<br>
&gt; plans to add more flexible introspection opcodes to Elements, such as<=
br>
&gt; OP_CHECKOUTPUTVERIFY?<br>
&gt;<br>
&gt; Really minor nit: &quot;Notice that we have appended 0x83 to the end o=
f<br>
&gt; the transaction data&quot;=E2=80=94should this say &quot;to the end of=
 the signature&quot;?<br>
&gt;<br>
&gt; On Thu, Nov 3, 2016 at 12:28 AM Russell O&#39;Connor via bitcoin-dev &=
lt;bit<br>
&gt; <a href=3D"mailto:coin-dev@lists.linuxfoundation.org">coin-dev@lists.<=
wbr>linuxfoundation.org</a>&gt; wrote:<br>
&gt; &gt; Right.=C2=A0 There are minor trade-offs to be made with regards t=
o that<br>
&gt; &gt; design point of OP_CHECKSIGFROMSTACKVERIFY.=C2=A0 Fortunately thi=
s<br>
&gt; &gt; covenant construction isn&#39;t sensitive to that choice and can =
be<br>
&gt; &gt; made to work with either implementation of<br>
&gt; &gt; OP_CHECKSIGFROMSTACKVERIFY.<br>
&gt; &gt;<br>
&gt; &gt; On Wed, Nov 2, 2016 at 11:35 PM, Johnson Lau &lt;<a href=3D"mailt=
o:jl2012@xbt.hk">jl2012@xbt.hk</a>&gt; wrote:<br>
&gt; &gt; &gt; Interesting. I have implemented=C2=A0OP_<wbr>CHECKSIGFROMSTA=
CKVERIFY in a<br>
&gt; &gt; &gt; different way from the Elements. Instead of hashing the data=
 on<br>
&gt; &gt; &gt; stack, I directly put the 32 byte hash to the stack. This sh=
ould<br>
&gt; &gt; &gt; be more flexible as not every system are using double-SHA256=
<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; <a href=3D"https://github.com/jl2012/bitcoin/commits/mast_v3=
_master" rel=3D"noreferrer" target=3D"_blank">https://github.com/jl2012/<wb=
r>bitcoin/commits/mast_v3_master</a><br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; On 3 Nov 2016, at 01:30, Russell O&#39;Connor via bitco=
in-dev &lt;bitc<br>
&gt; &gt; &gt; &gt; <a href=3D"mailto:oin-dev@lists.linuxfoundation.org">oi=
n-dev@lists.linuxfoundation.<wbr>org</a>&gt; wrote:<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; Hi all,<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; It is possible to implement covenants using two script<=
br>
&gt; &gt; &gt; &gt; extensions: OP_CAT and OP_CHECKSIGFROMSTACKVERIFY.=C2=
=A0 Both of<br>
&gt; &gt; &gt; &gt; these op codes are already available in the Elements Al=
pha<br>
&gt; &gt; &gt; &gt; sidechain, so it is possible to construct covenants in =
Elements<br>
&gt; &gt; &gt; &gt; Alpha today.=C2=A0 I have detailed how the construction=
 works in a<br>
&gt; &gt; &gt; &gt; blog post at &lt;<a href=3D"https://blockstream.com/201=
6/11/02/covenants-in-e" rel=3D"noreferrer" target=3D"_blank">https://blocks=
tream.com/2016/<wbr>11/02/covenants-in-e</a><br>
&gt; &gt; &gt; &gt; lements-alpha.html&gt;.=C2=A0 As an example, I&#39;ve c=
onstructed scripts<br>
&gt; &gt; &gt; &gt; for the Moeser-Eyal-Sirer vault.<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; I&#39;m interested in collecting and implementing other=
 useful<br>
&gt; &gt; &gt; &gt; covenants, so if people have ideas, please post them.<b=
r>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; If there are any questions, I&#39;d be happy to answer.=
=C2=A0=C2=A0<br>
&gt; &gt; &gt; &gt;<br>
&gt; &gt; &gt; &gt; --=C2=A0<br>
&gt; &gt; &gt; &gt; Russell O&#39;Connor<br>
&gt; &gt; &gt; &gt; ______________________________<wbr>_________________<br=
>
&gt; &gt; &gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; &gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org=
">bitcoin-dev@lists.<wbr>linuxfoundation.org</a><br>
&gt; &gt; &gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/li=
stinfo/bitcoin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linu=
xfoundation.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt; &gt;<br>
&gt; &gt; ______________________________<wbr>_________________<br>
&gt; &gt; bitcoin-dev mailing list<br>
&gt; &gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-=
dev@lists.<wbr>linuxfoundation.org</a><br>
&gt; &gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bit=
coin-dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundatio=
n.<wbr>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
&gt; &gt;<br>
&gt;<br>
&gt; ______________________________<wbr>_________________<br>
&gt; bitcoin-dev mailing list<br>
&gt; <a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@l=
ists.<wbr>linuxfoundation.org</a><br>
&gt; <a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-=
dev" rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wb=
r>org/mailman/listinfo/bitcoin-<wbr>dev</a><br>
______________________________<wbr>_________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org">bitcoin-dev@lists.=
<wbr>linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.<wbr>org=
/mailman/listinfo/bitcoin-<wbr>dev</a><br>
</div></div></blockquote></div><br></div>

--001a113bc72a82297a0540bb0fd6--