On Thu, Jun 23, 2016 at 03:58:29PM +0300, Alex Mizrahi wrote:
> >
> > 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
>
> 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.
>
OK, your
On Mon, Jun 20, 2016 at 01:26:22PM +, Police Terror via bitcoin-dev wrote:
> Bitcoin could embed a lisp interpreter such as Scheme, reverse engineer
> the current protocol into lisp (inside C++), run this alternative engine
> alongside the current one as an option for some years (only for fine
On Mon, Jun 20, 2016 at 04:21:39PM +, zaki--- via bitcoin-dev wrote:
> Hi Peter,
>
> I didn't entirely understand the process of transaction linearization.
>
> What I see is a potential process where when the miner assembles the block,
> he strips all but one sigscript per tx. The selection
> 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
Hi Peter,
I didn't entirely understand the process of transaction linearization.
What I see is a potential process where when the miner assembles the block,
he strips all but one sigscript per tx. The selection of which sigscript
is retained is determined by the random oracle. Is this is
Bitcoin could embed a lisp interpreter such as Scheme, reverse engineer
the current protocol into lisp (inside C++), run this alternative engine
alongside the current one as an option for some years (only for fine
tuning) then eventually fade this lisp written validation code instead
of the
In light of Ethereum's recent problems with its imperative, account-based,
programming model, I thought I'd do a quick writeup outlining the building
blocks of the state-machine approach to so-called "smart contract" systems, an
extension of Bitcoin's own design that I personally have been
