roconnor at theorem.ca [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-12-29 to 2012-01-02
💬 Posted a total of 5 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 02:54:48

- reply

📅 Original date posted:2012-01-02
📝 Original message:Seems ... acceptable from first glance.
Though I propose an ammendent to either
(1)
make the script: OP_NOP1 HASH160 <push-20-byte-hash> 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 immediately know it isn't a special script and can even
disregard the token).
or
(2)
If you are feel like spending another byte make the script:
OP_NOP1 <push-special-script-version-number> <special-script>
and assign 1 to this special script, making this case:
OP_NOP1 OP_1 HASH160 <push-20-byte-hash> EQUAL
On Mon, 2 Jan 2012, Gavin Andresen wrote:
> 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 in a backwards-compatible-in-the-blockchain way.
>
> Proposal:
>
> A new 'standard' transaction type, "pay to Script hash":
>
> scriptPubKey: HASH160 <push-20-byte-hash> EQUAL
>
> Redeemed with the same scriptSig as the OP_EVAL proposal:
> <signatures> <serialized Script>
>
> Old clients/miners will ignore <signatures> and just validate that the
> hash of <serialized Script> matches.
>
> New clients/miners will recognize the new type of transaction and will
> do the following additional validation:
>
> 1. Fail validation if there were any operations other than "push data"
> in the original scriptSig.
> 2. Deserialize the top (last) item on the scriptSig stack (fail
> validation if it fails to deserialize properly).
> 3. Run an additional validation on the deserialized script, using the
> remaining items on the scriptSig stack and the deserialized script as
> the scriptPubKey.
>
>
> ---------------
>
> As Amir said in IRC chat today, "the idea is a hack.... but I like it."
>
> I like it, too-- it is cleaner than OP_EVAL, more straightforward to
> implement, and pretty much exactly matches the feature I care about
> (moving code from the scriptPubKey to the scriptSig). There are no
> special cases like "CODESEPARATORS not allowed in <serialized
> script>".
>
>
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

2023-06-07 02:53:28

- reply

📅 Original date posted:2011-12-29
🗒️ Summary of this message: Gavin Andresen discusses the proposed OP_EVAL feature for Bitcoin and suggests amendments to make it less susceptible to abuse.
📝 Original message: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 sympathetic to the "OP_EVAL starts down
> the code-as-data path, and There Be Dragons" argument.
>
> But:
>
> I don't think the proposed alternative would be, in practice, any
> better. I see two main disadvantages over OP_EVAL:
>
> about 20-bytes larger
>
> it means going back to where we were two months ago, writing more
> code, reviewing it, finding bugs in it, backporting it so miners
> running old software can support it, etc.
Well, given the state that the OP_EVAL proposal was in when I looked at it
this week, all your code reviews you have done so far are not adequate
anyways.
Gavin, push the OP_EVAL date back 2 months. OP_EVAL just is not ready
yet.
> ... and some other minor disadvantages:
>
> 'standard' scripts will need to be slightly different in the
> scriptSig and the scriptPubKey
> (e.g. <signature> CHECKSIG becomes <signature> CHECKSIGVERIFY
> with OP_CODEHASH)
>
> OP_EVALs are not executed, and so the code associated with them does
> not have to be part of the transaction, if they are in the
> non-executed branch of an OP_IF. That could be good for privacy, and
> could be good for reducing block-chain size.
I don't understand the above paragraph.
> ----------------------
>
> In discussions in IRC yesterday, we talked a little about possible
> changes to the OP_EVAL BIP to make it less subject to abuse. In
> particular, the big can of worms is allowing arithmetic or bit
> operations on the serialized script that will be EVAL'ed:
> <serialized script> <other_data> OP_ADD OP_EVAL <-- Look! Dragons!
>
> If <serialized script> is more than 4 bytes, that is actually illegal
> right now (all of the arithmetic operations are limited to operating
> on numbers that are 4 bytes of less, and I believe we could prove that
> no series of operations will ever produce a value more than 5 bytes
> big given the current limitations).
This is not adequate: <data> OP_SHA256 OP_EVAL runs random code that is
more than 5 bytes.
> Which leads me to suggest that BIP 12 be amended to state that:
> OP_EVAL shall cause script validation to fail if the top item on the
> stack is less than 8 bytes long.
>
> I'm tempted to propose a rule:
> OP_EVAL shall fail if the top item on the stack is the result of any
> calculation
>
> ... but I don't think the extra code it would take to implement that
> (keep track of which items on the stack were the results of
> OP_ADD/etc) is worth it.
>
> On the "you can't tell how many CHECKSIG operations will be performed
> before executing the script" issue:
>
> That is already true, because the parameters to CHECKMULTISIG that
> determine how many signatures it checks might be computed.
Yes, but maybe there is other static analysis miners may want to do. I
can't imagine every scenario.
> Finally, I would echo theymos' observation that I think we'll
> eventually do something very much like OP_EVAL in the future-- maybe
> to support (in a backwards-compatible way) a
> quantum-computing-resistant signature algorithm or SHA3. When that is
> done, I think it might make sense to do a bottom-up redesign of Script
> based on what we've learned.
IMHO I think the above observation is not very relevant to the merits of
the existing OP_EVAL proposal on the table.
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

2023-06-07 02:53:15

- reply

📅 Original date posted:2011-12-30
🗒️ Summary of this message: Bitcoin's scripting language has limited ability to manipulate scripts on the stack, but could gain more abilities if certain operations are restored.
📝 Original message:On Sat, 31 Dec 2011, Chris Double wrote:
> On Fri, Dec 30, 2011 at 5:42 AM, <roconnor at theorem.ca> 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 arbitrary depth.
>>
>> OP_EVAL adds dangerously expressive power to the scripting language.
>
> If you look at the archives of the concatenative programming mailing
> list [1] you'll see lots of examples of people creating stack
> languages with minimal operations that exploit similar functionality
> to reduce the required built in operations. The discussion on the list
> is mostly about stack based languages where programs can be pushed on
> the stack and executed (eg. Joy [2]/Factor/Some Forths).
>
> I don't think the scripting engine in bitcoin has the ability to
> concatenate, append or otherwise manipulate scripts on the stack to be
> eval'd though does it?
It will limited ability manipulate scripts on the stack through the use of
arithmetic and hashing operations, and if OP_CAT, OP_SUBSTR and friends
are ever restored, it will have even more abilities.
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

2023-06-07 02:53:09

- reply

📅 Original date posted:2011-12-29
🗒️ Summary of this message: OP_EVAL proposal makes the script language Turing complete, with no limit on recursion depth, allowing arbitrary computation, and looping.
📝 Original message:On Thu, 29 Dec 2011, theymos wrote:
> On Thu, Dec 29, 2011, at 01:55 AM, roconnor at 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, with only an
>> artificial limit on recursion depth preventing arbitrary computation
>> and there is no way to know what code will run without executing it.
>
> Even if OP_EVAL allowed infinite depth, you'd still need to explicitly
> specify all operations performed, since there is no way of looping.
That's not true. Gavin himself showed how to use OP_EVAL to loop:
OP_PUSHDATA {OP_DUP OP_EVAL} OP_DUP OP_EVAL.
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 arbitrary depth.
OP_EVAL adds dangerously expressive power to the scripting language.
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''

2023-06-07 02:53:02

- reply

📅 Original date posted:2011-12-29
🗒️ Summary of this message: The proposal suggests adding a third "codehash" stack to the scripting engine, with a new OP_CODEHASH operator, to enable send-to-script addresses.
📝 Original message:Gavin asked me to come up with an alternative to OP_EVAL, so here is my
proposal.
OP_CODEHASH Initial Proposal
The idea is to add third "codehash" stack to the scripting engine (or
alternatively a codehash state variable) and have OP_CODESEPARATOR in
addition to its current behaviour push the hash of the remaining code in
the script onto the codehash stack (or alternatively set the codehash
state variable).
Then we add a new OP_CODEHASH operator that pops the codehash stack and
pushes it onto the main stack (or alternatively push the value of the
codehash state variable onto the mainstack which is initialized using the
hash of the sigScript).
The new send-to-script transaction would be:
OP_CODEHASH OP_HASH160 {20-byte-hash-value} OP_EQUAL
Which can be redeemed by
{20-byte-code-hash} signatures OP_CODESEPARATOR code
When run the code will consume all the signatures leaving the
20-byte-code-hash on the stack. When OP_CODEHASH is interpreted as a NOP
it is skipped, then the hash is hashed and compared to the
20-byte-hash-value and a match is required to succeed.
When OP_CODEHASH is interpreted by a new client it pops the codehash stack
and pushes the value onto the main stack, which in this standard
transaction pushes a value identical to the existing {20-byte-code-hash}
on the stack. Then again this hash is hashed and compared to to
{20-byte-code-hash}.
This proposal covers all the desired behaviour from OP_EVAL proposal but
with a less radical change:
(1) you get send-to-script addresses
(2) you cannot redeem with the old client without knowing the hash of the script
OP_CODEHASH has no dynamically generated code that is executed. The
language remains a weak stack based language which is clearly terminating.
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, with only an artificial
limit on recursion depth preventing arbitrary computation and there is no
way to know what code will run without executing it. With the OP_EVAL
proposal there is no way to statically analyze the script (say to count
the number of uses of OP_CHECKSIG or OP_MULTICHECKSIG or other analysis)
without actually executing the script.
This is just an initial proposal there are clearly some variations that
could be done that would work just as well.
Thanks goes to luke-jr and others for their thoughts on this proposal.
Good night everyone.
--
Russell O'Connor <http://r6.ca/>
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''