Received-SPF: pass (sog-mx-4.v43.ch3.sourceforge.com: domain of gmail.com
	designates 209.85.212.47 as permitted sender)
	client-ip=209.85.212.47; envelope-from=mh.in.england@gmail.com;
	helo=mail-vw0-f47.google.com; 
MIME-Version: 1.0
Sender: mh.in.england@gmail.com
In-Reply-To: <20110825201453.GA28296@ulyssis.org>
References: <20110825201453.GA28296@ulyssis.org>
Date: Fri, 26 Aug 2011 13:09:37 +0200
Message-ID: <CANEZrP0OyKSqEZj3UF0ArKFePuTi_HyM2_OZA8zXO5Uf+bAZwA@mail.gmail.com>
From: Mike Hearn <mike@plan99.net>
To: Pieter Wuille <pieter.wuille@gmail.com>
Content-Type: text/plain; charset=UTF-8
Cc: Bitcoin Dev <bitcoin-development@lists.sourceforge.net>
Subject: Re: [Bitcoin-development] New standard transaction types: time to
 schedule a blockchain split?
Precedence: list

> On the github pull request I posted a general scheme that can convert arbitrary
> expressions over signature-checks (given in RPL notation) to bitcoin scripts.
> Maybe we can define an address type that encodes an expression in RPL form (which
> should be more compact and more easily parseable)?

What are the use cases for this?

From a mobile apps perspective, it doesn't make much sense to have
arbitrary scripts in a user-facing address. The software has to be
able to present some kind of reasonable user interface given an
address, it has to explain what is going to happen to the users money
and so on. From this perspective, doing pattern matching against some
encoded script template is annoying and inefficient. It'd be better to
just define another type of URI for each kind of transaction you wish
to support. This is doubly true because often to do the more
interesting contracts, you need out of band protocols, so the
"address" would probably specify some information that's not in the
final output script, like a rendezvous point.