I write a gentle introduction to transaction scripts

[malefice]

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.

[1714725149]

1714725149

[1714725149]

1714725149

[1714725149]

1714725149

[kjj]

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

If you have something to say, say it here.

[malefice]

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.

[extro24]

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

Thank you!

[malefice]

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.

[btc4ever]

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

[btc4ever]

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:

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?

[malefice]

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:

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]

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]

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?

[k99]

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

[dewdeded]

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

[tlewis]

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!

[extro24]

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

scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG
scriptsig: <sig>


What will the new way be with OP_RETURN?
Maybe

scriptPubKey:  OP_RETURN <data> OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptsig: <sig> <pubKey>

? 

[malefice]

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

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

[jtimon]

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

scriptPubKey: <message> OP_DROP <pubKey> OP_CHECKSIG
scriptsig: <sig>


What will the new way be with OP_RETURN?
Maybe

scriptPubKey:  OP_RETURN <data> OP_DROP OP_DUP OP_HASH160 <pubKeyHash> OP_EQUALVERIFY OP_CHECKSIG
scriptsig: <sig> <pubKey>

?  

I think it's just

OP_RETURN <data>

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.

[danneu]

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.

[malefice]

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