5

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

Improve this question

2 Answers 2

Reset to default
4

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

Improve this answer
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?
    – Chris Moore
    Oct 24, 2016 at 19:03
  • 1
    It won't be accepted at all.
    – Pieter Wuille
    Oct 24, 2016 at 19:09
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

Improve this answer
3
  • I meant that A uses a SegWit Output in its Txin. Does that make more sense?
    – Murch ♦
    Jan 29, 2016 at 6:56
  • I've tried to clarify my scenario, could you please have another look?
    – Murch ♦
    Jan 29, 2016 at 10:54
  • @Murch I've added another answer, as both are potentially interesting I believe.
    – Pieter Wuille
    Jul 3, 2016 at 10:21

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.