<p>I don't think that's possible, even if you intentionally construct the transaction to be used as both segwit or non-segwit, and if you assume that there are segwit and non-segwit outputs for the same address.</p>

<p>The first ~36 bytes of a hashed transaction look like this:</p>

<p>non-segwit:</p>

<pre><code>byte
count   field name
4       version
1-3     varint of number of txins
32      sha256d of previous transaction
</code></pre>

<p>segwit:</p>

<pre><code>byte
count   field name
4       version
32      sha256d of concatenated prevout fields
</code></pre>

<p>You would need to find two pieces of data such that <code>hash(x)[1:16] = hash(y)[0:15]</code> or <code>hash(x)[3:16] = hash(y)[0:13]</code>, which I <em>think</em> is about as difficult as a collision attack (to a factor of 2^24 :P).</p>

<p>You can try to get around this by setting SIGHASH_ANYONECANPAY on the segwit side, but that puts a zero where the number of inputs should go on the non-segwit transaction, and that's definitely not valid in any signature mode. I think even if you sign in SIGHASH_NONE, you can't convert a segwit transaction to a non-segwit transaction, or vice versa.</p>

CC BY-SA 3.0
2017-03-04T05:02:01.780Z
2017-03-04T05:02:01.780Z
Nick ODell
<p>No, it cannot. There are several reasons this won't work. For example, the signatures in Bitcoin transactions commit to the complete transaction by means of signing the sighash. However the sighash is formed by a different scheme in SegWit than for legacy transactions. Another is that SegWit transactions contain elements that are not present in regular transactions, namely marker, flag and witness. Thus even if sighashes were using the same scheme, the content that they commit to could never match up. </p>

CC BY-SA 3.0
2017-08-03T07:52:17.440Z
2017-08-03T07:52:17.440Z
Murch
<p>...or is there any way for a SegWit witness to contain a "legacy" signature?</p>

CC BY-SA 3.0
2017-03-03T20:10:34.497Z
Do you mean 'Can a tx spend both segwit and non-segwit outputs?' or 'Can a segwit output be spent using a legacy signature?'
Nick ODell
CC BY-SA 3.0
2017-03-03T20:12:34.730Z
The latter. In theory. Like, if I ripped the signature from a segwit transaction and reformed it to non-segwit, would it be valid? Or vice-versa. If I took a valid pre-segwit signature and reformatted to segwit, would it be valid? Or would it require re-signing following the BIP143 rules?
pinhead
<signature><segregated-witness>
Are SegWit signatures all required to follow BIP143?
pinhead
# Are SegWit signatures all required to follow BIP143?

(Asked by: username_0 on 2017-03-03)

...or is there any way for a SegWit witness to contain a "legacy" signature?

**Tags:** signature, segregated-witness

> **Comments:**
> **username_1**: Do you mean 'Can a tx spend both segwit and non-segwit outputs?' or 'Can a segwit output be spent using a legacy signature?'  
> **username_0**: The latter. In theory. Like, if I ripped the signature from a segwit transaction and reformed it to non-segwit, would it be valid? Or vice-versa. If I took a valid pre-segwit signature and reformatted to segwit, would it be valid? Or would it require re-signing following the BIP143 rules?  

---

## 2 answers

### Answer by username_1 on 2017-03-04. Score: 4

I don't think that's possible, even if you intentionally construct the transaction to be used as both segwit or non-segwit, and if you assume that there are segwit and non-segwit outputs for the same address.

The first ~36 bytes of a hashed transaction look like this:

non-segwit:

```
byte
count   field name
4       version
1-3     varint of number of txins
32      sha256d of previous transaction

```

segwit:

```
byte
count   field name
4       version
32      sha256d of concatenated prevout fields

```

You would need to find two pieces of data such that `hash(x)[1:16] = hash(y)[0:15]` or `hash(x)[3:16] = hash(y)[0:13]`, which I *think* is about as difficult as a collision attack (to a factor of 2^24 :P).

You can try to get around this by setting SIGHASH\_ANYONECANPAY on the segwit side, but that puts a zero where the number of inputs should go on the non-segwit transaction, and that's definitely not valid in any signature mode. I think even if you sign in SIGHASH\_NONE, you can't convert a segwit transaction to a non-segwit transaction, or vice versa.


---

### Answer by username_2 on 2017-08-03. Score: 2

No, it cannot. There are several reasons this won't work. For example, the signatures in Bitcoin transactions commit to the complete transaction by means of signing the sighash. However the sighash is formed by a different scheme in SegWit than for legacy transactions. Another is that SegWit transactions contain elements that are not present in regular transactions, namely marker, flag and witness. Thus even if sighashes were using the same scheme, the content that they commit to could never match up.


---

