path: root/d9/f5a91e6e087443778232de2c3c177f69787bfe

Return-Path: <david.vorick@gmail.com>
Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org
	[172.17.192.35])
	by mail.linuxfoundation.org (Postfix) with ESMTPS id 1CD94BB3
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Aug 2019 07:09:28 +0000 (UTC)
X-Greylist: whitelisted by SQLgrey-1.7.6
Received: from mail-wm1-f51.google.com (mail-wm1-f51.google.com
	[209.85.128.51])
	by smtp1.linuxfoundation.org (Postfix) with ESMTPS id 2EAB212E
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Aug 2019 07:09:25 +0000 (UTC)
Received: by mail-wm1-f51.google.com with SMTP id v19so1604651wmj.5
	for <bitcoin-dev@lists.linuxfoundation.org>;
	Tue, 20 Aug 2019 00:09:25 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025;
	h=mime-version:references:in-reply-to:from:date:message-id:subject:to; 
	bh=V8jjYrJULke8m3MFabvyVXK+P003JfzD2VusvE1+yf0=;
	b=C54IxMuRH6oYVfZ1Oc/sk/c9Z4WFfhRtlow0kFN2SUSFuGSMk6daU9oj6+cxAPrF0b
	WiAd+FME11bg9m6zxAhzlS9DdTEeViA35BjOG+MopUYZ2yRj8lds2ML++UKa84bimrmU
	siDtdU5mNzFk1o7PqrD771aDmPnfVP8/K4emownLT0DuT6O/b4Q8wEsFOmpdqToXH2ok
	/WF1TISQyQe2z/keROpFgk9Fy1rPfprRvwqV42+dFJxD9NBEXZBqw7Goqc0O9VK0ns7s
	+ct7bUrZ1zOZGLRMSbknSgbFs2tmxQY35NNpsNT5zQ0i1BoNJxxbNYk2qpM/H0WV8JOS
	B/ZQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
	d=1e100.net; s=20161025;
	h=x-gm-message-state:mime-version:references:in-reply-to:from:date
	:message-id:subject:to;
	bh=V8jjYrJULke8m3MFabvyVXK+P003JfzD2VusvE1+yf0=;
	b=HBtoGqBOhaqrIU/hVMNedjlzTINhXwmyhYwimTSI1jyhnmdh5XmmG/Dx+MrfyW/i17
	RXN/QqLepzF2M69ukms4lgmFf6gVGj5E+NunjZwleTppc50I8VX/cAQJRznwS3t/uwFj
	Vt/GPt1GsscAJxTnYMxT3HiQraEgiBZevmn1GYU8VGCOCKs9ijajrC45x/OzovuvVCWh
	hZmiVIo8YmGuu/kA8tJXHlNhTVfGIy4op5qClwSvRvKnTqRVdH1B7hf5MyqTpM+/IRcm
	IctheIsK6JQdkIxT6R0MrPqcHfVrLlyQbid/LxstAcovy5TiBqTfM466cOSQXe2ivIW8
	Xn3g==
X-Gm-Message-State: APjAAAX2OCO8BSfaeqQWpFUtJ3Cc94Y70mNz+YM674UcWqfqEq6piu4N
	cQ12jWgj4NDsYdkfXUBcxq+ubpYoCRwC5Iodq5A=
X-Google-Smtp-Source: APXvYqwLlIz/VXWCcQKk4Vw0QkXU5LEKm8tgoJ9CfNLYyouqKQdRjfKZ8iz6YAE+a7IgfkdGxaRlYR0BfJPjNIPD2+w=
X-Received: by 2002:a1c:2ec6:: with SMTP id u189mr23773425wmu.67.1566284963491;
	Tue, 20 Aug 2019 00:09:23 -0700 (PDT)
MIME-Version: 1.0
References: <CAPg+sBiknRwBc8RV62wtuRVYi6wE1HNw6_ePquYVMWvjwp46bg@mail.gmail.com>
In-Reply-To: <CAPg+sBiknRwBc8RV62wtuRVYi6wE1HNw6_ePquYVMWvjwp46bg@mail.gmail.com>
From: David Vorick <david.vorick@gmail.com>
Date: Tue, 20 Aug 2019 03:15:24 -0400
Message-ID: <CAFVRnyp0Z997-UwJMFn3H7N0ogHTkxc+fDj-yROit3coUk1rxw@mail.gmail.com>
To: Pieter Wuille <pieter.wuille@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: multipart/alternative; boundary="000000000000ddb6cb0590872232"
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, HTML_MESSAGE,
	RCVD_IN_DNSWL_NONE 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] Miniscript
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: Tue, 20 Aug 2019 07:09:28 -0000

--000000000000ddb6cb0590872232
Content-Type: text/plain; charset="UTF-8"

Glad to see this post. I have been following Miniscript for some time, and
the static
analysis that is possible with Miniscript is particularly interesting to me.

Today, new Bitcoin applications such as JoinMarket, Wasabi wallet, and
Arwen all
suffer from a problem of having novel bitcoin scripts. Bitcoin script is
not easy to
analyze, and historically it has been difficult for me to get comfortable
using these
applications because I have been unable to convince myself to have complete
confidence in the integrity of the transactions these applications want me
to sign.

Well established applications can eventually overcome this issue for users
by
getting sufficient expert review and commentary, however this proves as a
substantial barrier to entry in an ecosystem that is ideally as open as
possible.

Miniscript can make a huge difference here. With Miniscript, it possible to
create
hardware wallets that can perform static analysis on novel miniscripts and
provide
the user with assurances about the nature of the transactions. A hardware
wallet
with a Miniscript analyzer may not be able to tell you that a transaction
is a
CoinJoin transaction, but it will be able to tell you that under all
possible scenarios,
you end up with just as many coins in your addresses that you started with,
modulo
some transaction fee.

This is a big deal for novel application writers, as it significantly
reduces the barrier
for them to convince both themselves and others that the code they wrote
does not
risk user funds being lost, especially if all transactions are being
externally analyzed
and signed.

Miniscript is not of course a complete solution, for example it cannot
solve all of the
high-risk edge cases that are present in the lightning network, but it is a
big step
forward and I believe that widespread use of Miniscript would be a huge
boon to the
Bitcoin ecosystem.

On Mon, Aug 19, 2019 at 7:18 PM Pieter Wuille via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Miniscript is a project we've been working on for the past year or so,
> and is now at a stage where I'd like to get it some more attention. It is
> joint
> work with Andrew Poelstra and Sanket Sanjalkar.
>
> It's a language for writing (a subset of) Bitcoin Scripts in a structured
> way,
> enabling analysis, composition, generic signing and more.
>
> For example the script
>
>   <A> OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160 <hash160(B)>
>   OP_EQUALVERIFY OP_CHECKSIGVERIFY <144> OP_CSV OP_ENDIF
>
> in Miniscript notation would be
>
>   or_d(c:pk(A),and_v(vc:pk_h(B),older(144)))
>
> making it human (engineer?) readable that this is a script that permits A
> to
> take the coins at any time, and B after 1 day. A full description of the
> language can be found on the project website
> http://bitcoin.sipa.be/miniscript
>
> Using Miniscript it's possible to:
> * Write descriptors for addresses for scripts that implement things more
>   complicated than multisig.
> * Make software that can deal with composition of policies (e.g. have funds
>   in a 2-of-3 setup where one of the 3 "keys" is itself a policy that
> involves
>   perhaps multiple devices and timeouts).
> * Compile complex spending policies to efficient scripts.
> * Figure out under what necessary and/or sufficient conditions a script
> can be
>   satisfied.
> * Given signatures for a sufficient set of keys (and hash preimages, if
> needed),
>   generically construct a witness for arbitrary scripts, without metadata
>   apart from the script itself and public keys appearing in it. This means
>   generic PSBT signers are possible for this class of scripts.
> * Compute the bounds on the size of a witness for arbitrary scripts.
> * Perform static analysis to see if any of Script's resource limitations
>   (ops limit, stack size, ...) might interfere with the ability to spend.
> * Who knows what else...
>
> We have two implementations:
> * a C++ one (https://github.com/sipa/miniscript)
> * a Rust library (https://github.com/apoelstra/rust-miniscript).
>
> The implementations are a work in progress, but through large scale
> randomized
> tests we have confidence that the language design and associated witnesses
> are
> compatible with the existing consensus and standardness rules.
>
> To be clear: Miniscript is designed for Bitcoin as it exists today
> (primarily
> P2WSH), and does not need any consensus changes. That said, we plan to
> extend
> the design to support future script changes Bitcoin may include.
>
> Cheers,
>
> --
> Pieter
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--000000000000ddb6cb0590872232
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div>Glad to see this post. I have been following Miniscri=
pt for some time, and the static</div><div>analysis that is possible with M=
iniscript is particularly interesting to me.</div><div><br></div><div>Today=
, new Bitcoin applications such as JoinMarket, Wasabi wallet, and Arwen all=
</div><div>suffer from a problem of having novel bitcoin scripts. Bitcoin s=
cript is not easy to</div><div>analyze, and historically it has been diffic=
ult for me to get comfortable using these</div><div>applications because I =
have been unable to convince myself to have complete</div><div>confidence i=
n the integrity of the transactions these applications want me to sign.</di=
v><div><br></div><div>Well established applications can eventually overcome=
 this issue for users by</div><div>getting sufficient expert review and com=
mentary, however this proves as a</div><div>substantial barrier to entry in=
 an ecosystem that is ideally as open as possible.</div><div><br></div><div=
>Miniscript can make a huge difference here. With Miniscript, it possible t=
o create</div><div>hardware wallets that can perform static analysis on nov=
el miniscripts and provide</div><div>the user with assurances about the nat=
ure of the transactions. A hardware wallet</div><div>with a Miniscript anal=
yzer may not be able to tell you that a transaction is a</div><div>CoinJoin=
 transaction, but it will be able to tell you that under all possible scena=
rios,</div><div>you end up with just as many coins in your addresses that y=
ou started with, modulo</div><div>some transaction fee.</div><div><br></div=
><div>This is a big deal for novel application writers, as it significantly=
 reduces the barrier</div><div>for them to convince both themselves and oth=
ers that the code they wrote does not</div><div>risk user funds being lost,=
 especially if all transactions are being externally analyzed</div><div>and=
 signed.</div><div><br></div><div>Miniscript is not of course a complete so=
lution, for example it cannot solve all of the</div><div>high-risk edge cas=
es that are present in the lightning network, but it is a big step</div><di=
v>forward and I believe that widespread use of Miniscript would be a huge b=
oon to the</div><div>Bitcoin ecosystem.<br></div></div><br><div class=3D"gm=
ail_quote"><div dir=3D"ltr" class=3D"gmail_attr">On Mon, Aug 19, 2019 at 7:=
18 PM Pieter Wuille via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@lists=
.linuxfoundation.org">bitcoin-dev@lists.linuxfoundation.org</a>&gt; wrote:<=
br></div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8e=
x;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
Miniscript is a project we&#39;ve been working on for the past year or so,<=
br>
and is now at a stage where I&#39;d like to get it some more attention. It =
is joint<br>
work with Andrew Poelstra and Sanket Sanjalkar.<br>
<br>
It&#39;s a language for writing (a subset of) Bitcoin Scripts in a structur=
ed way,<br>
enabling analysis, composition, generic signing and more.<br>
<br>
For example the script<br>
<br>
=C2=A0 &lt;A&gt; OP_CHECKSIG OP_IFDUP OP_NOTIF OP_DUP OP_HASH160 &lt;hash16=
0(B)&gt;<br>
=C2=A0 OP_EQUALVERIFY OP_CHECKSIGVERIFY &lt;144&gt; OP_CSV OP_ENDIF<br>
<br>
in Miniscript notation would be<br>
<br>
=C2=A0 or_d(c:pk(A),and_v(vc:pk_h(B),older(144)))<br>
<br>
making it human (engineer?) readable that this is a script that permits A t=
o<br>
take the coins at any time, and B after 1 day. A full description of the<br=
>
language can be found on the project website <a href=3D"http://bitcoin.sipa=
.be/miniscript" rel=3D"noreferrer" target=3D"_blank">http://bitcoin.sipa.be=
/miniscript</a><br>
<br>
Using Miniscript it&#39;s possible to:<br>
* Write descriptors for addresses for scripts that implement things more<br=
>
=C2=A0 complicated than multisig.<br>
* Make software that can deal with composition of policies (e.g. have funds=
<br>
=C2=A0 in a 2-of-3 setup where one of the 3 &quot;keys&quot; is itself a po=
licy that involves<br>
=C2=A0 perhaps multiple devices and timeouts).<br>
* Compile complex spending policies to efficient scripts.<br>
* Figure out under what necessary and/or sufficient conditions a script can=
 be<br>
=C2=A0 satisfied.<br>
* Given signatures for a sufficient set of keys (and hash preimages, if nee=
ded),<br>
=C2=A0 generically construct a witness for arbitrary scripts, without metad=
ata<br>
=C2=A0 apart from the script itself and public keys appearing in it. This m=
eans<br>
=C2=A0 generic PSBT signers are possible for this class of scripts.<br>
* Compute the bounds on the size of a witness for arbitrary scripts.<br>
* Perform static analysis to see if any of Script&#39;s resource limitation=
s<br>
=C2=A0 (ops limit, stack size, ...) might interfere with the ability to spe=
nd.<br>
* Who knows what else...<br>
<br>
We have two implementations:<br>
* a C++ one (<a href=3D"https://github.com/sipa/miniscript" rel=3D"noreferr=
er" target=3D"_blank">https://github.com/sipa/miniscript</a>)<br>
* a Rust library (<a href=3D"https://github.com/apoelstra/rust-miniscript" =
rel=3D"noreferrer" target=3D"_blank">https://github.com/apoelstra/rust-mini=
script</a>).<br>
<br>
The implementations are a work in progress, but through large scale randomi=
zed<br>
tests we have confidence that the language design and associated witnesses =
are<br>
compatible with the existing consensus and standardness rules.<br>
<br>
To be clear: Miniscript is designed for Bitcoin as it exists today (primari=
ly<br>
P2WSH), and does not need any consensus changes. That said, we plan to exte=
nd<br>
the design to support future script changes Bitcoin may include.<br>
<br>
Cheers,<br>
<br>
-- <br>
Pieter<br>
_______________________________________________<br>
bitcoin-dev mailing list<br>
<a href=3D"mailto:bitcoin-dev@lists.linuxfoundation.org" target=3D"_blank">=
bitcoin-dev@lists.linuxfoundation.org</a><br>
<a href=3D"https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev" =
rel=3D"noreferrer" target=3D"_blank">https://lists.linuxfoundation.org/mail=
man/listinfo/bitcoin-dev</a><br>
</blockquote></div>

--000000000000ddb6cb0590872232--