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

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.

  • 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 '16 at 19:03
  • 1
    It won't be accepted at all. – Pieter Wuille Oct 24 '16 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

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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