From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id A7138E8E for ; Mon, 15 Jan 2018 22:39:18 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-ua0-f179.google.com (mail-ua0-f179.google.com [209.85.217.179]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id D729B5AA for ; Mon, 15 Jan 2018 22:39:17 +0000 (UTC) Received: by mail-ua0-f179.google.com with SMTP id j23so4153596uak.13 for ; Mon, 15 Jan 2018 14:39:17 -0800 (PST) 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 :cc; bh=unPV/fbsGqPnav6uRlaVgTxWt9zSGrW2H/vXGEQR3WM=; b=ElAdagI93TQu5ZHw52PzAU1evYOm7nQ/SGcFbSOWMF9PO2wNIdeqPnrvXw4jzww3DV HUuUYyQdtWcOq5AUk5AVWkrKSKqmS4NPmC27uIShNJcmo5ZtNpHXKPJxfjgGs0wJZsWP oRtq6cIqC22YhHKI1/4dzvjp+VQeTDJkwIhNat5v26o8f9QV2+XK+butNYpxtedDZD+t PFKkD23JC89CMzTNKTkdQwiusfbkif6Pnw0Mzfdi+VsjACeXqfPYQnlDJ0GaSyuAAm/s PCzVOYvgbLhrFhx+NGaefWqhtNGRK2AuCt376z2nfMrkV0HC86n5d/Dzfm8Yi9XkL8Ev U+Zg== 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:cc; bh=unPV/fbsGqPnav6uRlaVgTxWt9zSGrW2H/vXGEQR3WM=; b=GTsm/m5BVdn4nUokl4tl7jrmgQKufjoi+SknhzX/6lfkYCMQr3/UMVn8fO5/49eION y39Vo/bA+d1wHr5sepISIfn+o5L49lOxKXx7HF1B8BgtGM6qeMjXMC88TpIvtBHleL9F iONeOOI74HwwzGYPiHCLTj6FdxrTtpaXvhgV0dc5nZZf3UXstIE/ZWwFxn3/QyxD5gAr pGKTSsD4bivSe1vWPlEckcf79a4FTUD5Yb7Cs3mWjmkM5e2vMQE9NHPlwjLOKYJTnAAz 4Br8rl6wjV9ipStAvNkKAscZa5QV5OBXIxezWFS0EkwRWSOJNPLXRm2skvR0fKCVxbFO z9Hw== X-Gm-Message-State: AKwxyteJ447KdC9tDd9I4Iu47Oq55iWXnqDZQFUpyPpkKWEuQnL5T9Sh fokTDXyeKd11YofA+BmjEuolaqYBK51pqF2sV2l/8Q== X-Google-Smtp-Source: ACJfBotum2rhoDAizptWpfNkQ+n8828Ty7sBHFfWl5zManVhaeT/L1hdnA/+YUZCJuhlyOJ6PwgFBdcTrRvl8QLaUIs= X-Received: by 10.176.19.107 with SMTP id h40mr33845189uae.173.1516055956771; Mon, 15 Jan 2018 14:39:16 -0800 (PST) MIME-Version: 1.0 References: <1CCF3C59-64DB-462F-AC62-AEA77FA01571@mattcorallo.com> In-Reply-To: <1CCF3C59-64DB-462F-AC62-AEA77FA01571@mattcorallo.com> From: Daniel Robinson Date: Mon, 15 Jan 2018 22:39:05 +0000 Message-ID: To: Matt Corallo Content-Type: multipart/alternative; boundary="001a11495608c3591e0562d848af" X-Spam-Status: No, score=-1.7 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM, HTML_MESSAGE,RCVD_IN_DNSWL_NONE autolearn=no 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, 15 Jan 2018 22:42:12 +0000 Cc: Daniel Robinson via bitcoin-dev Subject: Re: [bitcoin-dev] Ivy: a higher-level language targeting Bitcoin Script X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Jan 2018 22:39:18 -0000 --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 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 >> , >> or check out the docs and source >> code . >> >> 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 >> , 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
Hi Matt,

Thanks for raising this. Since= the compiler only produces SegWit addresses, I hadn'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

There was in fact a minor witness = malleability problem with how the compiler was handling clause selection. I= t'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-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't prevent you from doing dumb unconstraine= d stuff like:

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

Maybe it should, particularly si= nce 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 S= cript.

On Sun, J= an 14, 2018 at 5:42 PM Matt Corallo <lf-lists@mattcorallo.com> wrote:
I'm curious if you've considered adding some for= m 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 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.


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 pr= ototype higher-level language and development environment for creating cust= om Bitcoin Script programs. You can see the full announcement here, or check out = the docs=C2=A0and=C2=A0source code.

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.

To try out Ivy, you can use the Ivy Playground for Bitcoin, which a= llows you to create and test simulated contracts in a sandboxed environment= .

This is prototype soft= ware intended for educational and research purposes only. Please don't = try to use Ivy to control real or testnet Bitcoins.
=
--001a11495608c3591e0562d848af--