<blockquote>
  <p>0 and ab68025513c3dbd2f7b92a94e0581f5d50f654e7 in stack-based bitcoin
  script does not return true</p>
</blockquote>

<p>They <strong>do</strong> return true. Here is some pseudocode:</p>

<pre><code>push ( 0 );
push ( ab68025513c3dbd2f7b92a94e0581f5d50f654e7 )
return ( pop ( ) != 0 ); // evaluates to true
</code></pre>

CC BY-SA 4.0
2018-06-02T14:04:45.907Z
2018-06-02T14:04:45.907Z
amaclin
<p>Just a partial reply, on question 1: 
I had a similar question on bitcoin forum.
Scroll a bit down to my user name, and follow the <a href="https://bitcointalk.org/index.php?topic=1682183.msg21389041#msg21389041" rel="nofollow noreferrer">discussion with achow101</a>. 
The point is, that nodes talk to each other before exchanging transactions. Older nodes get then a different layout of the transaction like newer nodes, which makes them parse the transaction successfully.</p>

CC BY-SA 4.0
2018-06-02T13:59:26.090Z
2018-06-02T13:59:26.090Z
pebwindkraft
<p>From segwit part of reading <a href="https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc" rel="nofollow noreferrer">bitcoinbook</a>, there is an example for upgrading P2PKH to P2WPKH:  </p>

<blockquote>
  <p>Alice created a transaction to pay Bob for a cup of coffee. That
  transaction created a P2PKH output with a value of 0.015 BTC that was
  spendable by Bob. The output’s script looks like this:
  Example P2PKH output script  </p>

<pre><code>DUP HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 EQUALVERIFY CHECKSIG
</code></pre>
  
  <p>With Segregated Witness, Alice would create a
  Pay-to-Witness-Public-Key-Hash (P2WPKH) script, which looks like this:
  Example P2WPKH output script</p>

<pre><code>0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7
</code></pre>
</blockquote>

<p>Inputs for them are like below:<br>
For traditional P2PKH:</p>

<pre><code>[...]
“Vin” : [
"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
"vout": 0,
         "scriptSig": “&lt;Bob’s scriptSig&gt;”,
]
[...]
</code></pre>

<p>For P2WPKH:</p>

<pre><code>[...]
“Vin” : [
"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
"vout": 0,
         "scriptSig": “”,
]
[...]
“witness”: “&lt;Bob’s witness data&gt;”
[...]
</code></pre>

<p>So what if a full-node has not upgraded to new version with support to segwit? It seems that client without support for segwit will always validate the second input as true. Because in the book, it is said:</p>

<blockquote>
  <p>As you can see, a Segregated Witness output’s locking script is much
  simpler than a traditional output. It consists of two values that are
  pushed on to the script evaluation stack. To an old (nonsegwit-aware)
  bitcoin client, the two pushes would look like an output that anyone
  can spend and does not require a signature (or rather, can be spent
  with an empty signature).</p>
</blockquote>

<p>Question 1:<br>
<code>0</code> and <code>ab68025513c3dbd2f7b92a94e0581f5d50f654e7</code> in stack-based bitcoin script does not return true. 
Why the the "two pushes in segwit output looks like anyone can spend and does not require a signature" to old client?</p>

<p>Question 2:<br>
What is the <code>&lt;Bob's witness data&gt;</code>? It looks like that <code>&lt;Bob's witness data&gt;</code> is different from <code>&lt;Bob's scriptSig&gt;</code>. Can anyone provides an example?</p>

<segregated-witness>
How does a non-segwit full-node validate a SegWit input
Frank Kong
# How does a non-segwit full-node validate a SegWit input

(Asked by: username_0 on 2018-06-02)

From segwit part of reading [bitcoinbook](https://github.com/bitcoinbook/bitcoinbook/blob/develop/ch07.asciidoc), there is an example for upgrading P2PKH to P2WPKH:

> Alice created a transaction to pay Bob for a cup of coffee. That
> transaction created a P2PKH output with a value of 0.015 BTC that was
> spendable by Bob. The output’s script looks like this:
> Example P2PKH output script
>
> ```
> DUP HASH160 ab68025513c3dbd2f7b92a94e0581f5d50f654e7 EQUALVERIFY CHECKSIG
>
> ```
>
> With Segregated Witness, Alice would create a
> Pay-to-Witness-Public-Key-Hash (P2WPKH) script, which looks like this:
> Example P2WPKH output script
>
> ```
> 0 ab68025513c3dbd2f7b92a94e0581f5d50f654e7
>
> ```

Inputs for them are like below:  
For traditional P2PKH:

```
[...]
“Vin” : [
"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
"vout": 0,
         "scriptSig": “<Bob’s scriptSig>”,
]
[...]

```

For P2WPKH:

```
[...]
“Vin” : [
"txid": "0627052b6f28912f2703066a912ea577f2ce4da4caa5a5fbd8a57286c345c2f2",
"vout": 0,
         "scriptSig": “”,
]
[...]
“witness”: “<Bob’s witness data>”
[...]

```

So what if a full-node has not upgraded to new version with support to segwit? It seems that client without support for segwit will always validate the second input as true. Because in the book, it is said:

> As you can see, a Segregated Witness output’s locking script is much
> simpler than a traditional output. It consists of two values that are
> pushed on to the script evaluation stack. To an old (nonsegwit-aware)
> bitcoin client, the two pushes would look like an output that anyone
> can spend and does not require a signature (or rather, can be spent
> with an empty signature).

Question 1:  
`0` and `ab68025513c3dbd2f7b92a94e0581f5d50f654e7` in stack-based bitcoin script does not return true.
Why the the "two pushes in segwit output looks like anyone can spend and does not require a signature" to old client?

Question 2:  
What is the `<Bob's witness data>`? It looks like that `<Bob's witness data>` is different from `<Bob's scriptSig>`. Can anyone provides an example?

**Tags:** segregated-witness


---

## 2 answers

### Answer by username_1 on 2018-06-02. Score: 1 | Accepted answer

> 0 and ab68025513c3dbd2f7b92a94e0581f5d50f654e7 in stack-based bitcoin
> script does not return true

They **do** return true. Here is some pseudocode:

```
push ( 0 );
push ( ab68025513c3dbd2f7b92a94e0581f5d50f654e7 )
return ( pop ( ) != 0 ); // evaluates to true

```


---

### Answer by username_2 on 2018-06-02. Score: 0

Just a partial reply, on question 1:
I had a similar question on bitcoin forum.
Scroll a bit down to my user name, and follow the [discussion with achow101](https://bitcointalk.org/index.php?topic=1682183.msg21389041#msg21389041).
The point is, that nodes talk to each other before exchanging transactions. Older nodes get then a different layout of the transaction like newer nodes, which makes them parse the transaction successfully.


---

