+1. I love this proposal.
It's two less bytes than OP_EVAL even.
It allows static analysis.
It doesn't require any change to the script interpreter. (You can do a
static replacement step between parsing and execution.)
It allows all urgent use cases.
It doesn't consume a NOP. If we ever want recu
Seems ... acceptable from first glance.
Though I propose an ammendent to either
(1)
make the script: OP_NOP1 HASH160 EQUAL to make it
extremely easy to see from the first byte that this is verly likely to be
a special transaction (or more accurately if the first byte isn't
OP_NOP1 then you i
Here are my latest thoughts on a safer OP_EVAL alternative, inspired
by all the ideas and agitated IRC and email
discussions of the last week or so:
Goal: Let users publish a short "funding address" that is the hash of
an arbitrary redemption Script revealed when they spend the funds,
implemented
The OP_EVAL discussion went into some private discussion for a bit, so
here is a summary of what we talked about.
Roconnor pointed out that the currently proposed OP_EVAL removes the
ability to statically reason about scripts. Justmoon pointed out that
this is evidenced by the changes to GetSi
[Bitcoin-development] Alternative to OP_EVAL
> To: rocon...@theorem.ca
> Cc: bitcoin-development@lists.sourceforge.net
> Date: Saturday, December 31, 2011, 4:54 AM
> Wouldn't it work to restrict the
> number of executions of OP_EVAL allowed
> per transaction? That way i
Wouldn't it work to restrict the number of executions of OP_EVAL allowed
per transaction? That way it wouldn't allow for unlimited looping. If
there's too many OP_EVAL executions during the transaction evaluation,
just consider the transaction illegal. 3 would be enough for the
purposes people have
On Sat, 31 Dec 2011, Chris Double wrote:
On Fri, Dec 30, 2011 at 5:42 AM, wrote:
Basically OP_DUP lets you duplicate the code on the stack and that is the
key to looping. I'm pretty sure from here we get get Turing completeness.
Using the stack operations I expect you can implement the SK-ca
On Fri, Dec 30, 2011 at 5:42 AM, wrote:
> Basically OP_DUP lets you duplicate the code on the stack and that is the
> key to looping. I'm pretty sure from here we get get Turing completeness.
> Using the stack operations I expect you can implement the SK-calculus
> given an OP_EVAL that allows a
I haven't been much a part of these brainstorming discussions, and so I'm
really looking at this from a bird's eye view, without any bias towards any
particular idea.
I do see what appears to be relevant concerns, brought up just before new,
powerful functionality is injected into 50%+ of the node
On Thu, Dec 29, 2011 at 08:08:38PM +0100, Pieter Wuille wrote:
> On Thu, Dec 29, 2011 at 01:55:03AM -0500, rocon...@theorem.ca wrote:
> > Gavin asked me to come up with an alternative to OP_EVAL, so here is my
> > proposal.
> >
> > OP_CODEHASH Initial Proposal
>
> If we're again brainstorming ab
RE: delaying EVAL rollout: I could live with rolling out just BIP 11
(up-to-3-signature-CHECKMULTISIG as 'standard' transactions) and
delaying EVAL rollout on the main network, but I worry that will just
encourage people to delay thoroughly reviewing/testing for a couple of
months, and we'll be r
On Thu, Dec 29, 2011 at 01:55:03AM -0500, rocon...@theorem.ca wrote:
> Gavin asked me to come up with an alternative to OP_EVAL, so here is my
> proposal.
>
> OP_CODEHASH Initial Proposal
If we're again brainstorming about alternatives for OP_EVAL, I'll do my own.
It is called OP_CHECKEDEVAL, a
RE: preventing OP_EVAL from executing the result of calculations:
> This is not adequate: OP_SHA256 OP_EVAL runs random code that is more>
> than 5 bytes.
Good point, the rule should be "OP_EVAL shall fail if asked to execute
8 or fewer bytes."
RE: this minor disadvantage:
>> OP_EVALs are not
On Thursday, December 29, 2011 12:01:20 PM rocon...@theorem.ca wrote:
> This is not adequate: OP_SHA256 OP_EVAL runs random code that is
> more than 5 bytes.
So what? Why shouldn't I be able to run random code? I could always put that
random code in the script verbatim, after all.
-
Good morning everyone.
On Thu, 29 Dec 2011, Gavin Andresen wrote:
> First, thanks very much to Russell for looking more closely at both
> BIP 12 and the patch than anybody else-- he's found two bugs and two
> things the BIP isn't clear enough on (so far).
>
> And I've got to say, I'm very sympath
On Thu, 29 Dec 2011, theymos wrote:
> On Thu, Dec 29, 2011, at 01:55 AM, rocon...@theorem.ca wrote:
>> The number of operations executed is still bounded by the number of
>> operations occurring in the script. With the OP_EVAL proposal the
>> script language becomes essentially Turing complete, w
First, thanks very much to Russell for looking more closely at both
BIP 12 and the patch than anybody else-- he's found two bugs and two
things the BIP isn't clear enough on (so far).
And I've got to say, I'm very sympathetic to the "OP_EVAL starts down
the code-as-data path, and There Be Dragons"
17 matches
Mail list logo
