Subject: Re: [Bitcoin-development] New standard transaction types: time to schedule a blockchain split?

From: Pieter Wuille <[email-masked]>
Date: Fri, 26 Aug 2011 23:30:11 +0200

On Fri, Aug 26, 2011 at 01:09:37PM +0200, Mike Hearn wrote:
> > 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.

You're quite right - currently addresses encode a particular output script,
and the client pattern matches to know how to deal with the incoming funds.
It's far from sure this will remain the case in the future. Maybe we'll have
an out of band protocol over which a request "i want to pay you for item X"
is sent, with the required transaction output as answer.

A generic way for encoding complex transaction scripts in a compact form may
be useful for "manual" playing with them - but I agree that we should
probably wait for a use case for this.

Independent from the question of complex-script-addresses are useful, I do
think it is useful (and possible, see pull req) to allow a class of scripts
that represent boolean expressions over signature checks to pass the
IsStandard() test - that way we make sure that whenever in the future we
want to support creating such an expression, there will at least be a to
encode it in a way that the network will accept it. The only question is
what possible problems there are with accepting them.

-- 
Pieter