Can unupgraded nodes that accept zero confirmation be fooled after SegWit?

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)?

segregated-witness

Murch

Posted 2016-01-28T20:21:06.823

Reputation: 41 609

Answers

(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.

Pieter Wuille

Posted 2016-01-28T20:21:06.823

Reputation: 54 032

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 – 2016-10-24T19:03:41.950

1It won't be accepted at all. – Pieter Wuille – 2016-10-24T19:09:09.377

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

Pieter Wuille

Posted 2016-01-28T20:21:06.823

Reputation: 54 032

I meant that A uses a SegWit Output in its Txin. Does that make more sense? – Murch – 2016-01-29T06:56:19.957

I've tried to clarify my scenario, could you please have another look? – Murch – 2016-01-29T10:54:05.490

@Murch I've added another answer, as both are potentially interesting I believe. – Pieter Wuille – 2016-07-03T10:21:26.537