Topic: Can non-segwit nodes verify txs with outputs from segwit txs? (Read 602 times)

Thank you Danny, that's exactly how I had interpreted it. So segwit although a softfork, did introduce trust into legacy nodes. Only new segwit nodes are fully validating transactions.

Please learn how bitcoin actually works before trying to answer questions in the technical sub-forums.  Your nonsense is not appreciated.


The scriptPubKey of the transaction that received the SegWit output contains the Witness Commitment.  This commitment looks like an "anyone can pay" script to non-SegWit nodes. So it doesn't matter what is in the scriptSig of the transaction that spends the SegWit output. The non-SegWit node will accept it even if the scriptSig contains an invalid signature.

So, the transaction looks "valid", but to a non-SegWit node the output doesn't look like it is restricted to being spent only by the intended recipient.  Then later when it is spent, a SegWit node can look at the witness data and verify that it the spending was properly authorized.  Meanwhile, a non-SegWit node believes that the transaction is valid even if it is not properly authorized.

If you are running a SegWit node then you are not trusting anybody, and you are verifying that the transaction is correct (and as such you are verifying that the block containing the transaction is correct).  If you are running a non-SegWit node, then you are effectively trusting that the longest chain that you've heard about has been verified by a SegWit node somewhere, since your node won't be able to tell the difference between a valid transaction spending a SegWit output and an invalid transaction spending a SegWit output.

A SegWit node will accept the longest VALID chain.  If it hears about a longer chain, but that chain contains an invalid transaction, then the SegWit node will reject that longer chain.

You don't really have to trust anyone when using a non-segwit node, I would disagree with that. As a soft fork, segwit doesn't break backwards compatibility. The fact that your node doesn't understand Segwit means that it can't use it, it won't show you the balance of your segwit addresses and it won't be able to send to them. It will just ignore it. Only way you need to trust a Segwit node is if you want to use a segwit address yourself or send to one while running a non-segwit node. It is pretty simple, it is almost like another layer to it from the clear user perspective. What really is happening there is that miners just agreed that they won't confirm certain types of transactions (non-valid segwit transactions), other then that it all seems normal to the old node.

not sure if the derivation is correct. From my discussion with achow (https://bitcointalksearch.org/topic/m.21389041) I seem to understand, that segwit nodes send data in legacy format to "old" (non-segwit) nodes. This doesn't mean, the old client "get's nothing, and must trust". It still get's the data in old "legacy" format, and as such can decompose the tx inside, and verify the contents.
Further achow101 says: "all witness data stripped out" - I am not yet sure how to interpret this, does it mean that script sig(s) in the legacy format remain empty? That would mean, the legacy client is still able to verify tx contents, but spending is the difference.

Yes that's what I thought.

This seems to mean that once segwit transactions propagate through the network enough so that the majority of tx chains contain a segwit transactions somewhere in their history, a non-segwit node would effectively have reduced security and would not itself be able to verify any transaction it receives (unless it receives a tx from an output that pre-dated segwit). This would put non-segwit nodes closer to a level of SPV node security wouldn't it?


Yeah, that's what I was thinking. Trustlessness will over time be broken for any full node that is not segwit capable.

I guess that's not a problem in itself because you can just update to segwit, but it does mean that the ability to have a lower HDD requirement by being a non-segwit node is going to fast become an impossibility.

In that case, since you haven't upgraded to SegWit, you are effectively trusting that the longest chain that you know about has been verified by a SegWit node somewhere.  The following transaction:

ADDRESS 2 > traditional tx output > ADDRESS 3

will look valid to you because a SegWit output will look like an output that anybody can spend.  When your node tries to validate that transaction, it will look valid because you can't see the SegWit portion.  As long as there are some reliable nodes you can trust that are feeding you the blockchain, the fact that the transaction made it into a block will mean that it must have been valid, but that breaks the trustless nature of Bitcoin.

For example, if I run an old pre-segwit node, can I verify a traditional non-segwit tx I receive if it's outputs come from segwit txs?

My understanding is that if a non-segwit node looks at a block with segwit txs, it cannot verify those segwit txs because the witness data is not recognised by the non-segwit node. So when it moves down the chain, how does it verify a new tx that is reliant on past segwit txs?

In a quick mock up:


* ADDRESS 0 > traditional tx output > ADDRESS 1

* ADDRESS 1 > segwit tx output > ADDRESS 2

* ADDRESS 2 > traditional tx output > ADDRESS 3

* ADDRESS 3 > traditional tx output > ADDRESS 4

A segwit node can verify all of the above txs. What happens to a old pre-segwit node if it controls ADDRESS 4? Can it verify that the coins are truly valid? Or does it just assume they are?