I write a gentle introduction to transaction scripts

malefice

newbie

Activity: 37

Merit: 0

Quote from: danneu on January 07, 2014, 03:58:05 PM

Good stuff.

The reference Bitcoin implementation obfuscates the core simplicity of transaction validation by oddly referring to scripts as "scriptPubKey" and "scriptSig" instead of "inputScript" and "outputScript".

Realizing that "owning bitcoin" just means that you can provide a stack of instructions that evaluates to true when appended to another arbitrary instruction stack is what inspired me to hack on Bitcoin in the first place.

Some feedback:

It's worth pointing out that "true" is really just "any non-zero value" rather than a boolean literal. In other words, a script is logically valid as long as the top stack value is not 0 and as long as the evaluation isn't short-circuited by an instruction like OP_RETURN.
The significance of instructions like OP_RETURN and OP_VERIFY is that they short-circuit the evaluation. Otherwise, the script will evaluate in full and the final top stack value will determine the state of the stack. That's why you can append arbitrary data after OP_RETURN -- it's so that the data won't be evaluated.

Hey thanks, Ive inserted your comments as foodnotes in page 2 and 5. I would like to permalink to the comment as a citation but seems ont te be possible

danneu

newbie

Activity: 32

Merit: 0

Good stuff.

The reference Bitcoin implementation obfuscates the core simplicity of transaction validation by oddly referring to scripts as "scriptPubKey" and "scriptSig" instead of "inputScript" and "outputScript".

Realizing that "owning bitcoin" just means that you can provide a stack of instructions that evaluates to true when appended to another arbitrary instruction stack is what inspired me to hack on Bitcoin in the first place.

Some feedback:

It's worth pointing out that "true" is really just "any non-zero value" rather than a boolean literal. In other words, a script is logically valid as long as the top stack value is not 0 and as long as the evaluation isn't short-circuited by an instruction like OP_RETURN.
The significance of instructions like OP_RETURN and OP_VERIFY is that they short-circuit the evaluation. Otherwise, the script will evaluate in full and the final top stack value will determine the state of the stack. That's why you can append arbitrary data after OP_RETURN -- it's so that the data won't be evaluated.

jtimon

legendary

Activity: 1372

Merit: 1002

Quote from: extro24 on January 06, 2014, 05:40:33 AM

I understand this was the old (non-standard) way of sending a message:

scriptPubKey: OP_DROP OP_CHECKSIG
scriptsig:

What will the new way be with OP_RETURN?
Maybe

scriptPubKey: OP_RETURN OP_DROP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
scriptsig:

?

I think it's just

OP_RETURN

The funds in that output are lost.

I would say you can set an output of 0, but the transaction would be non-standard (due to the anti-dust validations) and it may take too much time until you get it into the chain.

malefice

newbie

Activity: 37

Merit: 0

Quote from: dewdeded on December 28, 2013, 05:34:39 AM

I like. I mirrored it at my website: http://www.bitcoinhistory.net/ under "Technical Papers".

cool, you can always check bitcoining.it for updates.

extro24

sr. member

Activity: 481

Merit: 252

I understand this was the old (non-standard) way of sending a message:

scriptPubKey: OP_DROP OP_CHECKSIG
scriptsig:

What will the new way be with OP_RETURN?
Maybe

scriptPubKey: OP_RETURN OP_DROP OP_DUP OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG
scriptsig:

?

tlewis

newbie

Activity: 19

Merit: 0

Quote from: malefice on December 18, 2013, 02:27:10 AM

I write gentle introduction to transaction scripts, while learning them for myself.
I think this is overdue for the average developer.
Please give feedback (google docs comments) on mistakes and improvements you find useful.

Great job malefice! Congratulations on launching the document. It looks great after your iterations. have you made progress on multi-sig? I would love to help!

dewdeded

legendary

Activity: 1232

Merit: 1011

Monero Evangelist

I like. I mirrored it at my website: http://www.bitcoinhistory.net/ under "Technical Papers".

k99

sr. member

Activity: 346

Merit: 255

Manfred Karrer

Thanks for the great overview! Helps a lot to understand it a bit better....

malefice

newbie

Activity: 37

Merit: 0

i tried it with the following phrase now:

Generally a command executed on the stack takes its parameters from the stack, and puts its result at the stack. So OP_VERIFY behaves normally if its FALSE, because it leaves the result on the stack, but it behaves abnormally when its TRUE. It removes the result TRUE from the stack to continue with the next parameters.
https://docs.google.com/document/d/1D_gi_7Sf9sOyAHG25cMpOO4xtLq3iJUtjRwcZXFLv1E/edit#

what do you think?

btc4ever

sr. member

Activity: 321

Merit: 250

I think you will explain it fine if you just mention it and recall that not everyone has done stack based programming, or at least not recently.

malefice

newbie

Activity: 37

Merit: 0

Quote from: btc4ever on December 18, 2013, 05:01:44 PM

One bit of feedback. It wasn't immediately obvious to me that OP_EQUALVERIFY would cause PubKeyHash and PubKeyHash2 to be removed from the stack. You stated:

Quote

OP_EQUAL and OP_VERIFY are executed. OP_EQUAL puts TRUE on the stack if the two elements are the same. OP_VERIFY marks a transaction valid if the top stack element is true. And removes the top stack element if its TRUE, if its false it leaves it there.

So I thought this meant that OP_EQUAL would simply add TRUE to the stack when they are equal, and that OP_VERIFY would remove the top element ( TRUE ). But this would leave PubKeyHash and PubKeyHash2 still in place.

So I reason that OP_EQUAL must also remove both input elements, and probably most operators do that when they evaluate to TRUE. But I'm not sure that you explicitly state that anywhere.

So logically if we used OP_EQUAL and then OP_VERIFY we would have:

TRUE
PubKey
Signature

after OP_EQUAL and then

PubKey
Signature

after OP_VERIFY.

yes?

Yes! generally the inputs of an operation are removed from the stack, this is very CPU like: they are loaded into the CPU and removed from the data store, the result is then put on the data store. this is like processor chips work at a low level. so its the exception that true will not be shown, how could I explain this best?

btc4ever

sr. member

Activity: 321

Merit: 250

One bit of feedback. It wasn't immediately obvious to me that OP_EQUALVERIFY would cause PubKeyHash and PubKeyHash2 to be removed from the stack. You stated:

Quote

OP_EQUAL and OP_VERIFY are executed. OP_EQUAL puts TRUE on the stack if the two elements are the same. OP_VERIFY marks a transaction valid if the top stack element is true. And removes the top stack element if its TRUE, if its false it leaves it there.

So I thought this meant that OP_EQUAL would simply add TRUE to the stack when they are equal, and that OP_VERIFY would remove the top element ( TRUE ). But this would leave PubKeyHash and PubKeyHash2 still in place.

So I reason that OP_EQUAL must also remove both input elements, and probably most operators do that when they evaluate to TRUE. But I'm not sure that you explicitly state that anywhere.

So logically if we used OP_EQUAL and then OP_VERIFY we would have:

TRUE
PubKey
Signature

after OP_EQUAL and then

PubKey
Signature

after OP_VERIFY.

yes?

btc4ever

sr. member

Activity: 321

Merit: 250

That's a great intro. Looking forward to seeing a gentle intro to multi-sig transactions.

malefice

newbie

Activity: 37

Merit: 0

Quote from: extro24 on December 18, 2013, 04:31:44 PM

I really like your introduction. It is essential that somebody produces some tutorials on general transaction writing.

Thank you!

Thank you for your encouragement, extro24! Learning transaction scripts together is very a fine intellectual pleasure.

extro24

sr. member

Activity: 481

Merit: 252

I really like your introduction. It is essential that somebody produces some tutorials on general transaction writing.

Thank you!

malefice

newbie

Activity: 37

Merit: 0

Quote from: kjj on December 18, 2013, 03:19:24 PM

Ok, what's up with the flood of noobs posting links in here?

If you have something to say, say it here.

Because...? Arrogance wins over arguments?
I will simply ask the moderator if my contribution is welcome or not.

kjj

legendary

Activity: 1302

Merit: 1026

Ok, what's up with the flood of noobs posting links in here?

If you have something to say, say it here.

malefice

newbie

Activity: 37

Merit: 0

I write gentle introduction to transaction scripts, while learning them for myself.
I think this is overdue for the average developer.
Please give feedback (google docs comments) on mistakes and improvements you find useful.

Topic: I write a gentle introduction to transaction scripts (Read 2345 times)