<p>If it is a transaction that pays B, that means that B chose that address. If B doesn't support SegWit, it won't ask for a SegWit output, so this cannot happen.</p>

<p>In practice, SegWit wallets will likely use P2SH initially; the SegWit output will be embedded in a pay-to-scripthash, and the address a SegWit wallets gives to sender will be the P2SH hash of the SegWit output script. However, in our scenario, B doesn't know anything about all that, and will just give out a normal old-style pay-to-pubkey-hash address, and A will pay to that.</p>

<p>More information about failure scenarios around softforks that introduce new transaction types: <a href="https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html">https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html</a></p>

CC BY-SA 3.0
2016-01-29T06:56:19.957Z
I meant that A uses a SegWit Output in its Txin. Does that make more sense?
Murch
CC BY-SA 3.0
2016-01-29T10:54:05.490Z
I've tried to clarify my scenario, could you please have another look?
Murch
CC BY-SA 3.0
2016-07-03T10:21:26.537Z
@Murch I've added another answer, as both are potentially interesting I believe.
Pieter Wuille
CC BY-SA 3.0
2016-01-29T01:03:29.910Z
2016-01-29T01:03:29.910Z
Pieter Wuille
<p>(Other answer, after clarification of the question)</p>

<p>Among old nodes, the transaction is not propagated because it is non-standard. Whenever a softfork for new features is designed, its encoding is chosen in a way that makes it incompatible with old nodes' standardness rules.</p>

<p>In the case of segwit, a witness program is encoded as two pushes in the scriptPubKey (or redeemscript), one an OP_n (with n between 0 and 16) and one a data push of up to 40 bytes. Spending such an output will always violate the CLEANSTACK rule that was added as standardness in Bitcoin Core 0.10.</p>

<p>Similarly, CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY used redefined OP_NOPn opcodes, which violate the DISCOURAGE_UPGRADABLE_NOPS rule that was added as standardness in Bitcoin Core 0.10 as well.</p>

CC BY-SA 3.0
2016-10-24T19:03:41.950Z
So the transaction is not propagated, but what if A connects directly to B's node and feeds him the transaction. Will B's node still ignore it because it is non-standard? Or will the transaction be displayed, tricking B into thinking he has been paid?
Chris Moore
CC BY-SA 3.0
2016-10-24T19:09:09.377Z
It won't be accepted at all.
Pieter Wuille
CC BY-SA 3.0
2016-07-03T10:17:27.377Z
2016-07-03T10:27:22.690Z
2016-07-03T10:27:22.690Z
Pieter Wuille
<h2>Considering the following scenario:</h2>

<blockquote>
  <p>After deployment of SegWit, there remain two <strong>old</strong> clients (with software that is unaware of SegWit) <strong>A</strong> &amp; <strong>B</strong>.<br>
  <strong>A</strong> funds a transaction to pay <strong>B</strong> using a SegWit output which appears to both as <code>ANYONE_CAN_SPEND</code>.<br>
  Upgraded nodes ignore this transaction, as it obviously isn't signed correctly under the rules of SegWit. (Perhaps even ban old nodes that relay this "invalid transaction" to them?) However, among old nodes the transaction gets propagated as valid. </p>
</blockquote>

<p>In the case that <strong>B</strong> gets notice of the transaction, would it display an "incoming unconfirmed transaction"?<br>
Could people get fooled that way if they accept Zero Confirmation (which I'm aware isn't safe)?</p>

<segregated-witness>
Can unupgraded nodes that accept zero confirmation be fooled after SegWit?
Murch
# Can unupgraded nodes that accept zero confirmation be fooled after SegWit?

(Asked by: username_0 on 2016-01-28)

## Considering the following scenario:

> After deployment of SegWit, there remain two **old** clients (with software that is unaware of SegWit) **A** & **B**.  
> **A** funds a transaction to pay **B** using a SegWit output which appears to both as `ANYONE_CAN_SPEND`.  
> Upgraded nodes ignore this transaction, as it obviously isn't signed correctly under the rules of SegWit. (Perhaps even ban old nodes that relay this "invalid transaction" to them?) However, among old nodes the transaction gets propagated as valid.

In the case that **B** gets notice of the transaction, would it display an "incoming unconfirmed transaction"?  
Could people get fooled that way if they accept Zero Confirmation (which I'm aware isn't safe)?

**Tags:** segregated-witness


---

## 2 answers

### Answer by username_1 on 2016-07-03. Score: 4 | Accepted answer

(Other answer, after clarification of the question)

Among old nodes, the transaction is not propagated because it is non-standard. Whenever a softfork for new features is designed, its encoding is chosen in a way that makes it incompatible with old nodes' standardness rules.

In the case of segwit, a witness program is encoded as two pushes in the scriptPubKey (or redeemscript), one an OP\_n (with n between 0 and 16) and one a data push of up to 40 bytes. Spending such an output will always violate the CLEANSTACK rule that was added as standardness in Bitcoin Core 0.10.

Similarly, CHECKLOCKTIMEVERIFY and CHECKSEQUENCEVERIFY used redefined OP\_NOPn opcodes, which violate the DISCOURAGE\_UPGRADABLE\_NOPS rule that was added as standardness in Bitcoin Core 0.10 as well.

> **Comments:**
> **username_2**: So the transaction is not propagated, but what if A connects directly to B's node and feeds him the transaction. Will B's node still ignore it because it is non-standard? Or will the transaction be displayed, tricking B into thinking he has been paid?  
> **username_1**: It won't be accepted at all.  

---

### Answer by username_1 on 2016-01-29. Score: 5

If it is a transaction that pays B, that means that B chose that address. If B doesn't support SegWit, it won't ask for a SegWit output, so this cannot happen.

In practice, SegWit wallets will likely use P2SH initially; the SegWit output will be embedded in a pay-to-scripthash, and the address a SegWit wallets gives to sender will be the P2SH hash of the SegWit output script. However, in our scenario, B doesn't know anything about all that, and will just give out a normal old-style pay-to-pubkey-hash address, and A will pay to that.

More information about failure scenarios around softforks that introduce new transaction types: <https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012014.html>

> **Comments:**
> **username_0**: I meant that A uses a SegWit Output in its Txin. Does that make more sense?  
> **username_0**: I've tried to clarify my scenario, could you please have another look?  
> **username_1**: @username_0 I've added another answer, as both are potentially interesting I believe.  

---

