Bitcoin Forum

Example...

SegWit Address: 3Pih1gsGEufDcE3rnCvH7tSGxYCfAumr7N
Private Key: L31MGtLmx3RVomrNYkNzJqrd5h788GDkJpT6sTRhSu1rd2ZwWimr

Non-SegWit Address: 3FcdxBkv4Va8YLfyCe11pRsZ2uTki7DWvH
Private Key 1: L1QZg6Lqc8pH2RqWuEKzqv3rwjumQ2oMUyp4S8WPnZgWCnXPL4mu
Private Key 2: L3Qh439DtmJS1xKEe2tL7KG2niM4FWE6UvdJzs5DwdBqPZc8rrBe
Private Key 3: L5dhbsNKyzqPPgTFGe6kUVHibFv5QhoAhLJSVAqgTnyDXVimtm1E

Just looking at these addresses, how do we determine that 3Pih1gsGEufDcE3rnCvH7tSGxYCfAumr7N is SegWit and 3FcdxBkv4Va8YLfyCe11pRsZ2uTki7DWvH is not? And, if we can't determine, how do we decide whether to send SegWit Tx to these addresses or not?

All Bitcoin address that start with 3 are nested segwit addresses. All Bitcoin addresses that start with bc1 are the native segwit which is the real addresses regarded as segwit addresses. While in addition, addresses that tarts with 1 are the ledacy addresses.

If you use noncustodial wallet, you can send bitcoin transaction to any of the addresses, the transaction will be successful and confirmed, but sending using native segwit has low fee payment while legacy in addition will have high fee if compared to the other two.

Completely wrong.

You can't. P2SH addresses are identical to each other and there isn't a way to tell if they're a musig (except taproot but that isn't the point of the question) or a P2WPKH nested in P2SH (for simplicity I refer to this as P2SH-P2PWKH) address/other locking conditions. The only time you can differentiate the kind of address is when they sign and spend any UTXOs, the redeem script will reveal what kind of locking script it has.

You don't have to care if the address that you're sending to is a segwit address or not. It doesn't make a difference. As long as the inputs are segwit, the size discount applies.

---

I've sent two transactions, one to a P2SH-P2PWKH (non-bech32) address and one to a multisig address.
To a P2SH (with multisig) address: efbc21dd2e2a1dc3ff67f853b550b5bab26f3f1a7f7960b0949bd0133f5d9e03
To a P2SH-P2PWKH address: 4a32b0eafad34f5c51c31cde881ecccd5d8a596400abd8b6269608492c6af719

For both, the size is the same at 142vbyte as the conditions are the same except that they're spending to P2SH addresses with different unlocking requirements.
For both, the output script is similar: OP_HASH160 [RIPEMD160(SHA256) hash here]OP_EQUAL

However, when I spend them:
From a P2SH (with multisig) address: 015739847a882dd1d3fb6c1792682cedb0d4155c4f508909cc280d3edf9bfad0
From a P2SH-P2PWKH address: 9dbf5fa4b8b8ffcedceb10ea59be46bb6aeec2b50f817a02a565ed314ea866e2

You can observe that the redeem script contains the requirements to unlock that script and/or the HASH160 of the original address and it's witness.

There are of course a myriad of conditions to be used in a P2SH address but I chose Multisig as the simplest and most common form of it as a demonstration.

How is it wrong, are multisig addresses not nested segwit? Or, why?

Doesn't have to be.

P2SH addresses (AKA those starting with 3) are defined in BIP16. It defines addresses which has a specific condition within the redeem script that has to be fulfilled for the transaction to be vallid. Multisig addresses do not necessarily have to be a Segwit; there are also bech32 script addresses (P2WSH) which allows you to have scripts in bech32 or P2SH-P2WSH which would yield a P2SH address but those are for a different topic. OP is specifically asking about P2SH addresses and they are versatile in the sense that you can put complicated scripts and conditions for the UTXOs to be spent. Most of the multisig that most services uses are not P2SH-P2WSH but are actually just a P2SH by itself without any witness scripts.

So, it'll be incorrect to say that all P2SH addresses are nested Segwit. Nested segwit is just a very small subset of P2SH scripting.

Multisig addresses existed long before Segwit was implemented.

You can not tell if it will be Multisig or Segwit unless you hold the private key(s) and thus know the type.

No.

Have a read about the "3" type (aka "Pay to Script Hash" aka P2SH) addresses here: https://en.bitcoin.it/wiki/Pay_to_script_hash

- All multisig addresses are P2SH, but not all P2SH addresses are multisig.
- Likewise, all "Nested SegWit" (aka P2SH-P2WPKH) addresses are P2SH, but not all P2SH addresses are Nested SegWit


And as rightly explained by ranochigo... unless you are the "owner" of the address, which access to the private keys and wallet etc... you cannot determine if the address is MultiSig or NestedSegwit or something else until a UTXO has been spent from that address in a transaction and you can see the transaction details and redeem script.

Well, that's not quite accurate either. To throw even more confusion in to the mix, you can have multi-sig addresses using P2WSH.

If you are making a legacy multi-sig or nested segwit multi-sig, they will both start with "3", but "3" can also be used to create other scripts which have nothing to do with segwit or multi-sig.
If you are making a native segwit multi-sig, then it will start with "bc1", but "bc1" can also be used to create regular segwit address which have nothing to do with multi-sig.

Electrum. Their 2FA TrustedCoin as well as their multisig wallet supports P2WSH but you can choose P2SH as well.

P2SH-P2WSH is quite rare I think, I haven't found a wallet that supports that as of yet. Its like a P2SH-P2WPKH but with P2WSH instead.

electrum devs have always kept the scripts used very simple so i don't think it can even support some of the OP codes let alone custom witness scripts nested in a script hash.
there has been requests to add advanced scripts but hasn't happened
https://github.com/spesmilo/electrum/issues/5949

there is also support for different hardware wallets that some of which i think support nested SegWit addresses. from the source code of electrum it seems like bitbox has such option calling it p2wsh-p2sh (reverse of what it should be called). the script that is used is a simple multisig though.

You don't need to know the private key.
When the output is being spend, the unlocking script has to be revealed. And once you observe this, you can tell whether it is P2WPKH nested into P2SH or a multisig P2SH. Or even something completely different.

However, if the UTXO is not spent yet, there is no way of knowing this other than having the unlocking script created by yourself (i.e. you are the recipient).

Okay so tell me what type this address is then: 38AruHmY94Yih9cvc8d144Z8BHZnUDSH35

You can't. None of the UTXOs in the address has been spent and thus the redeem script is not revealed. You should pick an address with at least one of the UTXOs spent so we can see the redeem script.

If you would refer to my transactions, you'll notice that it's easy to get the redeem script from the second set of TXes and thus the kind of P2SH scripts it contains.

As i have mentioned.. since none of these 4 UTXO's has been spend, no script has been revealed.
And therefore only the person who created that unlocking script knows whether it is a multisig P2SH or P2WPKH nested into P2SH or any other P2SH.

The 4 UTXO contain:

Therefore, all we know is that the unlock script's hash will be 4714deea7bae98a2ae990bd1ff059911529eddff.
But we don't know what kind of script this is.

So i was right and you can not know it unless you have the private key and made that transaction. ;)

FTFY  ;)
Also, you could just wait until the bitcoins which were received with that address are spent.

No, you were not right.
It seems you misunderstand something.

Read my response again:


So, to summarize and to reference your statement:

1) You don't necessarily need the private key. Observing the unlocking script being published (a.k.a. the output is being spend) is enough.

2) Even if you made the transaction creating the UTXO, you don't know anything about the unlocking script.
As a sender, you just use the address provided by the recipient to to create that new UTXO. You, as a sender, don't know wheter this is multisig or P2WPKH nested into P2SH. It is irrelevant whether you or someone else created the transaction/UTXO.