MIME-Version: 1.0
References: <CAD438HvzYAMVTU8A0OiNnj2nvYgMApdS8NNfzE86Ae_OsTfuaA@mail.gmail.com>
	<1CCF3C59-64DB-462F-AC62-AEA77FA01571@mattcorallo.com>
In-Reply-To: <1CCF3C59-64DB-462F-AC62-AEA77FA01571@mattcorallo.com>
From: Daniel Robinson <danrobinson010@gmail.com>
Date: Mon, 15 Jan 2018 22:39:05 +0000
Message-ID: <CAD438Ht8x5-v8NsC7O=D7Oo5EZ56q5E3LKuVt033as-8iqtd=Q@mail.gmail.com>
To: Matt Corallo <lf-lists@mattcorallo.com>
Content-Type: multipart/alternative; boundary="001a11495608c3591e0562d848af"
Cc: Daniel Robinson via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ivy: a higher-level language targeting Bitcoin
	Script
Precedence: list

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

Hi Matt,

Thanks for raising this. Since the compiler only produces SegWit addresses,
I hadn't worried at all about malleability, but as you pointed out
out-of-band, malleability in the length of an argument can allow an
attacker to deflate the feerate of a transaction.

There was in fact a minor witness malleability problem with how the
compiler was handling clause selection. It's now been fixed in version
0.0.7 of the compiler.

As far as I can tell (and I haven't looked all that carefully), any
sensible Ivy contract won't have any witness malleability problem. (A funny
exception is the RevealCollision contract, since you can length-extend the
arguments to get another collision. But without a signature check, that one
has a more serious transaction malleability problem anyway.) But the
compiler currently doesn't prevent you from doing dumb unconstrained stuff
like:

```
clause spend(a: Bytes, b: Bytes, sig: Signature) {
  verify a =3D=3D b
  verify checkSig(publicKey, sig)
  unlock val
}
```

Maybe it should, particularly since there's no reason to include a trivial
condition like that anyway. But I think it would probably be about as easy
(and more generally useful) to build a static analyzer that solved this
problem for low-level Bitcoin Script.

On Sun, Jan 14, 2018 at 5:42 PM Matt Corallo <lf-lists@mattcorallo.com>
wrote:

> I'm curious if you've considered adding some form of compiler-time
> enforcement to prevent witness malleability? With that, Ivy could help to
> resolve for it's users one of the things that can make Bitcoin scripts mo=
re
> complicated to write, instead of simply type-checking and providing a
> high-level language mapped 1-to-1 with Bitcoin script.
>
>
> On December 18, 2017 8:32:17 PM UTC, Daniel Robinson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> Today, we=E2=80=99re releasing Ivy, a prototype higher-level language an=
d
>> development environment for creating custom Bitcoin Script programs. You
>> can see the full announcement here
>> <https://blog.chain.com/ivy-for-bitcoin-a-smart-contract-language-that-c=
ompiles-to-bitcoin-script-bec06377141a>,
>> or check out the docs <https://docs.ivy-lang.org/bitcoin/> and source
>> code <https://github.com/ivy-lang/ivy-bitcoin>.
>>
>> Ivy is a simple smart contract language that can compile to Bitcoin
>> Script. It aims to improve on the useability of Bitcoin Script by adding
>> affordances like named variables and clauses, static (and domain-specifi=
c)
>> types, and familiar syntax for function calls.
>>
>> To try out Ivy, you can use the Ivy Playground for Bitcoin
>> <https://ivy-lang.org/bitcoin/>, which allows you to create and test
>> simulated contracts in a sandboxed environment.
>>
>> This is prototype software intended for educational and research purpose=
s
>> only. Please don't try to use Ivy to control real or testnet Bitcoins.
>>
>>

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

<div dir=3D"ltr">Hi Matt,<div><br></div><div>Thanks for raising this. Since=
 the compiler only produces SegWit addresses, I hadn&#39;t worried at all a=
bout malleability, but as you pointed out out-of-band, malleability in the =
length of an argument can allow an attacker to deflate the feerate of a tra=
nsaction.=C2=A0</div><div><br></div><div>There was in fact a minor witness =
malleability problem with how the compiler was handling clause selection. I=
t&#39;s now been fixed in version 0.0.7 of the compiler.</div><div><br></di=
v><div>As far as I can tell (and I haven&#39;t looked all that carefully), =
any sensible Ivy contract won&#39;t have any witness malleability problem. =
(A funny exception is the RevealCollision contract, since you can length-ex=
tend the arguments to get another collision. But without a signature check,=
 that one has a more serious transaction malleability problem anyway.) But =
the compiler currently doesn&#39;t prevent you from doing dumb unconstraine=
d stuff like:</div><div><br></div><div>```</div><div>clause spend(a: Bytes,=
 b: Bytes, sig: Signature) {</div><div>=C2=A0 verify a =3D=3D b</div><div>=
=C2=A0 verify checkSig(publicKey, sig)</div><div>=C2=A0 unlock val</div><di=
v>}</div><div>```</div><div><br></div><div>Maybe it should, particularly si=
nce there&#39;s no reason to include a trivial condition like that anyway. =
But I think it would probably be about as easy (and more generally useful) =
to build a static analyzer that solved this problem for low-level Bitcoin S=
cript.</div></div><br><div class=3D"gmail_quote"><div dir=3D"ltr">On Sun, J=
an 14, 2018 at 5:42 PM Matt Corallo &lt;<a href=3D"mailto:lf-lists@mattcora=
llo.com">lf-lists@mattcorallo.com</a>&gt; wrote:<br></div><blockquote class=
=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padd=
ing-left:1ex"><div>I&#39;m curious if you&#39;ve considered adding some for=
m of compiler-time enforcement to prevent witness malleability? With that, =
Ivy could help to resolve for it&#39;s users one of the things that can mak=
e Bitcoin scripts more complicated to write, instead of simply type-checkin=
g and providing a high-level language mapped 1-to-1 with Bitcoin script.</d=
iv><div><br><br><div class=3D"gmail_quote">On December 18, 2017 8:32:17 PM =
UTC, Daniel Robinson via bitcoin-dev &lt;<a href=3D"mailto:bitcoin-dev@list=
s.linuxfoundation.org" target=3D"_blank">bitcoin-dev@lists.linuxfoundation.=
org</a>&gt; wrote:<blockquote class=3D"gmail_quote" style=3D"margin:0pt 0pt=
 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir=3D"ltr"><div dir=3D"auto">Today, we=E2=80=99re releasing Ivy, a pr=
ototype higher-level language and development environment for creating cust=
om Bitcoin Script programs. You can see the full announcement <a href=3D"ht=
tps://blog.chain.com/ivy-for-bitcoin-a-smart-contract-language-that-compile=
s-to-bitcoin-script-bec06377141a" target=3D"_blank">here</a>, or check out =
the <a href=3D"https://docs.ivy-lang.org/bitcoin/" target=3D"_blank">docs</=
a>=C2=A0and=C2=A0<a href=3D"https://github.com/ivy-lang/ivy-bitcoin" target=
=3D"_blank">source code</a>.</div><div dir=3D"auto"><br></div><div dir=3D"a=
uto">Ivy is a simple smart contract language that can compile to Bitcoin Sc=
ript. It aims to improve on the useability of Bitcoin Script by adding affo=
rdances like named variables and clauses, static (and domain-specific) type=
s, and familiar syntax for function calls.</div><div dir=3D"auto"><br></div=
><div dir=3D"auto">To try out Ivy, you can use the <a href=3D"https://ivy-l=
ang.org/bitcoin/" target=3D"_blank">Ivy Playground for Bitcoin</a>, which a=
llows you to create and test simulated contracts in a sandboxed environment=
.</div><div dir=3D"auto"><br></div><div dir=3D"auto">This is prototype soft=
ware intended for educational and research purposes only. Please don&#39;t =
try to use Ivy to control real or testnet Bitcoins.</div><div dir=3D"auto">=
<br></div></div>
</blockquote></div></div></blockquote></div>

--001a11495608c3591e0562d848af--