Quote from: achow101 on November 24, 2016, 07:46:42 PM

Quote from: Quickseller on November 24, 2016, 07:17:19 PM

Wallet software is being changed to implement SegWit because the creators of such software believe that SegWit will likely be implemented, not necessarily because they believe SegWit is what is best for Bitcoin. If it was apparent that Bitcoin was about to HF to have a maximum block size of 2 MB, then wallet providers would likely also be in the process of upgrading their software to support this.

While that is true, there are also many wallet vendors who do also believe that segwit is the way to go. In fact, those that don't think segwit is best don't need to implement segwit (and probably aren't going to).

If SegWit is implemented into Bitcoin, then anyone who does not use SegWit is going to have to pay a premium in TX fees when compared to users who do use SegWit, so to the extent that SegWit is implemented into Bitcoin, using SegWit is beneficial to the user of Bitcoin (this is not the same as saying that SegWit is what is best for Bitcoin).

You are correct to say that some wallet providers (and other bitcoin services as well) might think that SegWit is what is best for Bitcoin. My question is, has anyone attempted to ask the "official" opinion of major bitcoin services regarding their stance of SegWit? The success of most major bitcoin related services is generally aligned with the success of Bitcoin.

Quote from: achow101 on November 24, 2016, 07:46:42 PM

Quote from: Quickseller on November 24, 2016, 07:17:19 PM

My understanding is that if a node does not upgrade, then it does not have a way to validate that a transaction is valid (due to being unable to validate the transactions signature), and does not have any way to validate that a block that contains one or more SegWit transactions is valid. Am I right about this, or is this not accurate?

If the above is accurate, then I think you are using a very specific definition of "backwards compatible" to make your statement.

No, you are incorrect. Non-upgraded nodes do not suddenly just stop validating transactions and are suddenly unable to validate transactions. They still fully validate all transactions and blocks to the best of their ability. This means that transaction hashes are still checked, the merkle root is still checked, signatures of legacy transactions are checked, inputs and referenced outpoints are checked, etc. Non-upgraded nodes still check and validate nearly everything in a segwit transaction. The only thing that they are unable to do is to check the signatures for segwit transactions. In that case, the wallet relies on miners on having done so and it waits for confirmations for segwit transactions before accepting them. This is no different from other soft forks.

While I do concede that after a soft fork, a node may not know that a particular transaction is invalid, I think that this is not quite the same with SegWit. For example, if a soft fork that invalidated any transaction after block n that is signed with (/contains?) a "high" s-value, then a node that has not upgraded might receive a transaction with a high s-value and not reject said transaction -- however said transaction would be a valid transaction prior to block n, and the soft fork. I would think that much of the time, a sender of these kinds of invalid transactions would have made an honest mistake (although there are some exceptions to this), and the receiver could ask the sender to resend the transaction after sufficient time has passed and has not confirmed. What I believe the difference is that someone could send a SegWit transaction to a non-SegWit node that was never valid, but the node would treat said transaction as if it were valid.

I do have another SegWit related question:

If someone who has not upgraded to SegWit receives a SegWit transaction, are they able to spend outputs from said transaction?