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 --]
prev parent 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 [bitcoin-dev] Ivy: a higher-level language targeting Bitcoin Script 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.com \
--cc=bitcoin-dev@lists.linuxfoundation.org \
--cc=lf-lists@mattcorallo.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
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