public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Daniel Robinson <danrobinson010@gmail•com>
To: Matt Corallo <lf-lists@mattcorallo•com>
Cc: Daniel Robinson via bitcoin-dev <bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Ivy: a higher-level language targeting Bitcoin Script
Date: Mon, 15 Jan 2018 22:39:05 +0000	[thread overview]
Message-ID: <CAD438Ht8x5-v8NsC7O=D7Oo5EZ56q5E3LKuVt033as-8iqtd=Q@mail.gmail.com> (raw)
In-Reply-To: <1CCF3C59-64DB-462F-AC62-AEA77FA01571@mattcorallo.com>

[-- Attachment #1: Type: text/plain, Size: 2943 bytes --]

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 == 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 more
> 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’re releasing Ivy, a prototype higher-level language and
>> 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-compiles-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-specific)
>> 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 purposes
>> only. Please don't try to use Ivy to control real or testnet Bitcoins.
>>
>>

[-- Attachment #2: Type: text/html, Size: 3868 bytes --]

      reply	other threads:[~2018-01-15 22:39 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-18 20:32 Daniel Robinson
2018-01-14 22:41 ` Matt Corallo
2018-01-15 22:39   ` Daniel Robinson [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAD438Ht8x5-v8NsC7O=D7Oo5EZ56q5E3LKuVt033as-8iqtd=Q@mail.gmail.com' \
    --to=danrobinson010@gmail$(echo .)com \
    --cc=bitcoin-dev@lists$(echo .)linuxfoundation.org \
    --cc=lf-lists@mattcorallo$(echo .)com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox