Talk:Script

WikiProject Protocol

	This page is within the scope of WikiProject Protocol, a collaborative effort to improve the coverage of Bitcoin protocol documentation on the Bitcoin Wiki. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.
???	This page has not received a rating on the quality scale.
Top	This page has been rated as top-importance on the importance scale.

xOP_IFDUP 115 0x73 x x / x x If the input is true or false, duplicate it.

Shouldn't it be: "If the input is true, duplicate it."? --ThePiachu 11:37, 20 December 2011 (GMT)

The byte vectors in the stack are specified as being signed integers of variable-length. Then there's an explanation that these integers are considered false if they are either zero or negative zero, which is 0x80. For this to be the case, the elements should be represented in an old binary format called sign-magnitude, which is important to state explicitly, since today virtually all computers use two's complement as representation, and there's no such thing as a negative zero. There's even another representation, one's complement, where negative zero looks like 0xff.

Reading the source code of the application, I see that arithmetic operations expect unsigned integers, for example, operations OP_2MUL and OP_2DIV are implemented as byte-shifting, which wouldn't work with signed representations.

It seems to me that, at best, variable-length sign-magnitued integer format is only used for testing for truth, although I haven't read all the code yet.

--Jean-Pierre Rupp 10:43, 4 March 2012 (GMT)

Provably Unspendable/Prunable Outputs

If im not mistaken this kind of transaction would not result in donating the output to the miner. It would instead make the output unusable by anyone forever. In my opinion the best and easiest way to donate to miner is just transfer BTC between your own addresses and set a high fee. Norill (talk) 22:32, 14 April 2013 (GMT)

norill: Fixed wording for OP_RETURN; it is mining fee in the example because the output value is zero, not 0.125BTC as I think you thought. Sorry about that.

Peter Todd (talk) 02:51, 23 July 2013 (GMT)

Common confusion on Turing-completeness.

Script isn't turing-complete under the precise definition of the term because it executes with bounded time and memory.

But by the precise definition a conventional desktop computer is also not "turing-complete": there are functions a universal turing machine can compute that a desktop cannot because the desktop computer runs out of memory first.

The precise definition isn't terribly useful for most people, since it excludes most things we think of as computers. Many people read the "not Turing-complete" as a statement that Script is only as expressive as a regular language or only capable of expressing monotone functions or something like that. Not so, if you ignore the time/memory bounds script is technically universal for computation. Consider the fragment "2 OP_PICK OP_IF OP_SWAP OP_ENDIF": This implements a fredkin gate which is universal and could just be wired up and repeated up to the operation limit Q.E.D.

It's absolutely important for the Bitcoin system that script's execution has an quickly checkable, bounded, and very short runtime. The relevance of turing completeness to any of that is easily and often overstated. The greater limits of script's expressiveness come from the computation bound, not the computational model. --Gmaxwell (talk) 05:47, 28 March 2015 (UTC)

I think that often when people talk about "Turing completeness", they mean that any program written in a normal programming language can ~always be compiled into any "Turing complete" language, even though this isn't really the definition of Turing completeness. You can write a program in C to calculate pi to the n^th digit, and even if you were using regular C integers n could be pretty large without needing to modify the program. But the equivalent Script program would need to increase in size every time you increase the maximum size of n by 1, and this is what makes Script much weaker than C or any other normal programming language. theymos (talk) 18:32, 28 March 2015 (UTC)

OP_xVERIFY output is Nothing

The commands OP_CHECKSIGVERIFY, OP_CHECKMULTISIGVERIFY, OP_VERIFY, OP_EQUALVERIFY, OP_NUMEQUALVERIFY shows a boolean output on the table of this page, however the output is Nothing. Is that correct? --Thelink2012 (talk) 16:57, 15 November 2015 (UTC)

Order of inputs and outputs is not explained

The way the inputs and outputs are listed isn't intuitive and isn't explained on this page. For example, for OP_SUB, it shows inputs as "x1 x2 x3" and outputs as "x2 x3 x1". I would have expected that x1 would indicate the top of the stack, but instead it seems to indicate the first item pushed onto the stack (and therefore, the bottom of the stack). The outputs are described in the same way, which is even more unintuitive, since the outputs aren't pushed onto the stack individually but are just moved around. So the way to understand the way its written here is that the outputs are as if they were pushed in the order given (or to just understand that the top of the stack is the last item listed).

I think we should reverse this so that the top of the stack is listed first. It would be a lot more intuitive I think. Alternatively, we can change the notation so that "x1" indicates the top of the stack, then writing "x3 x2 x1" would be easier to read intuitively either way - ie you clearly see the order they're pushed, but you can also look at the numbers to check their position on the stack. This could also be reversed so "x3 x2 x1" means that x3 is on the top of the stack (but was pushed third).

Thoughts?

Also it looks like OP_PICK and OP_ROLL are writing these values in a way that's not consistent with the rest of the page. Eg ROLL has inputs "xn ... x2 x1 x0 <n>". It looks like its using 0-based indexes instead of the 1-based indexes the rest of the page uses, and it isn't numbering the xs in order of being pushed. But then again, this is a case where using this notation is useful - and I think it might make sense to change the rest of the page to using this convention.

Fresheneesz (talk) 19:10, 18 April 2021 (UTC)