On Tue, Jun 21, 2016 at 01:28:48AM +0300, Alex Mizrahi wrote:
> > All practical single-use seals will be associated with some kind of
> > condition,
> > such as a pubkey, or deterministic expression, that needs to be satisfied
> > for
> > the seal to be closed.
> 
> 
> I think it would be useful to classify systems w.r.t. what data is
> available to condition.
> I imagine it might be useful if status of other seals is available.

Useful yes, but actually implementing that often results in systems that are
too tightly coupled to scale well.

> > Secondly, the contents of the proof will be able to
> > commit to new data, such as the transaction spending the output associated
> > with
> > the seal.
> >
> 
> So basically a "condition" returns that "new data", right?
> If it commits to a data in a recognizable way, then it's practically a
> function which yields a tuple (valid, new_data).
> If an oracle doesn't care about data then you can convert it to a predicate
> using a simple projection.
> But from point of view of a client, it is a function which returns a tuple.

What do you mean by "new data"?

The point I'm making is simply that to be useful, when you close a seal you
have to be able to close it over some data, in particular, another seal. That's
the key thing that makes the idea a useful construct for smart contacts, value
transfer/currency systems, etc.

> It might help if you describe a type of the condition function.

I did describe some seal authorization condition functions in my more recent
post; the key thing is you'd have some kind of "checksig" operator that checks
a cryptographic signature.

> Some related work on UTXO-based smart contracts:

<snip>

Thanks for the links! Not at all surprising to me that there's a whole bunch of
projects working along those same lines; it's the obvious way to build this
kind of stuff once you realise that the imperative, stateful, model isn't
viable.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org