<p>I believe the behavior you are seeing is actually a bug.</p>

<p>By default, <code>addmultisigaddress</code> uses p2sh-segwit which is the default address type for the wallet. By default <code>createmultisig</code> uses legacy. These are two different address types, and normally, you get two different addresses.</p>

<p>However segwit does not allow uncompressed public keys. So when the redeemScript is being created, if an uncompressed public key is detected, both RPCs will return legacy addresses. This is why you see the same address in the second example.</p>

<p>But I believe there is a bug. Your first example should also give the same legacy addresses, but it does not. I think that this is because the uncompressed pubkey is not part of the wallet, so it does not correctly detect that it is an uncompressed pubkey. Thus <code>addmultisigaddress</code> follows its default to give you the p2sh-segwit address and <code>createmultisig</code> follows its default to give you the legacy address.</p>

<blockquote>
  <p>Reading raw transactions data from the blockchain, how is possible to know whether a script needs to be hashed using legacy or segwit?</p>
</blockquote>

<p>For p2sh-segwit, the redeemScript is not actually the redeemScript you get from the RPCs. Rather it is the script for a P2WSH output. The "redeemScript" is actually the witnessScript for the P2WSH script that is the actual redeemScript. The script type (either in the scriptPubKey or in the redeemScript) determine whether that output is segwit or not. </p>

CC BY-SA 4.0
2019-05-09T17:18:17.287Z
I agree there is a bug, but even if those public keys are not added to the wallet and you shift the uncompressed public key from the first position to last then both of them generate a legacy address. This works only if the uncompressed public key is in the last position. That is the reason why in the second case in the question, both the addresses are the same (uncompressed public key is in the last position in that example).
Ugam Kamat
CC BY-SA 4.0
2019-05-09T17:03:08.957Z
2019-05-09T17:03:08.957Z
Ava Chow
<p>Some time ago I noticed that, given the same inputs, <code>addmultisigaddress</code> and <code>createmultisig</code> Bitcoin core's methods were generating different p2sh (addresses).</p>

<p>I asked around and a user from the bitcoin dev list told me that this was because:</p>

<blockquote>
  <p>"addmultisigaddress uses the default address type of the wallet, which
  is p2sh-segwit and createmultisig uses a default address type of
  legacy"</p>
</blockquote>

<p>An example of this behaviour is:</p>

<pre><code>bitcoin-cli addmultisigaddress 1 '["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
{
  "address": "36ULucjWUTrDvaJzCyhFoVbDoNS6Zum2Du",
  "redeemScript": "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
}

bitcoin-cli createmultisig 1 '["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
{
  "address": "3GiimyxF1R5VixfBFAbQZbuy9EesD2r6n1",
  "redeemScript": "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
}
</code></pre>

<p>The point is that, later, I noticed that with certain public keys the two methods generate the same hash:</p>

<pre><code>bitcoin-cli addmultisigaddress 1 '["03fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d7617631146","02ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd101","04633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac204"]'
{
  "address": "32AVnYUUSvm4bGgEXoQ2zuFAJBPH4P31Gi",
  "redeemScript": "512103fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d76176311462102ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd1014104633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac20453ae"
}

bitcoin-cli createmultisig 1 '["03fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d7617631146","02ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd101","04633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac204"]'
{
  "address": "32AVnYUUSvm4bGgEXoQ2zuFAJBPH4P31Gi",
  "redeemScript": "512103fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d76176311462102ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd1014104633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac20453ae"
}
</code></pre>

<p>I don't get how this can be possible if the inputs and the redeem scripts are the same.</p>

<p>What's the difference between the two cases and in general between a legacy multisig transaction and a segwit one?</p>

<p>Reading raw transactions data from the blockchain, how is possible to know whether a script needs to be hashed using legacy or segwit?</p>

CC BY-SA 4.0
2019-05-08T13:01:46.420Z
I'm unsure why that is happening. If there is at least one uncompressed public key both methods should give legacy p2sh addresses. However, i noticed that in the first case if you push the uncompressed public key from position 1 to position 2 or 3 while passing the RPC call, we get the same p2sh addresses by both methods.
Ugam Kamat
CC BY-SA 4.0
2019-05-08T13:16:39.673Z
This is a good point @UgamKamat, thank you. I didn't though that if one of the pubkeys is uncompressed, the p2sh needs to be legacy because segwit does not support uncompressed keys. However, it's not enough for a general rule because I think that also in the case where all the pubkeys are compressed, the p2sh can still be legacy
Michele
CC BY-SA 4.0
2019-05-08T14:32:25.243Z
that is correct, but what I am perplexed by is why the two RPC calls are giving different addresses in your first case. You can check, if you shift the uncompressed public key in the first case in the last position and run both RPC calls, they will give the same P2SH addresses. What I'm having trouble understanding is why they are different if uncompressed public key is first
Ugam Kamat
CC BY-SA 4.0
2019-05-09T16:56:27.230Z
In both examples, is the uncompressed pubkey part of your wallet? I think there's a bug here.
Ava Chow
<blockchain><segregated-witness><raw-transaction><p2sh><raw-data>
Multisig scripts hashing (p2sh): difference between legacy and segwit
Michele
# Multisig scripts hashing (p2sh): difference between legacy and segwit

(Asked by: username_0 on 2019-05-08)

Some time ago I noticed that, given the same inputs, `addmultisigaddress` and `createmultisig` Bitcoin core's methods were generating different p2sh (addresses).

I asked around and a user from the bitcoin dev list told me that this was because:

> "addmultisigaddress uses the default address type of the wallet, which
> is p2sh-segwit and createmultisig uses a default address type of
> legacy"

An example of this behaviour is:

```
bitcoin-cli addmultisigaddress 1 '["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
{
  "address": "36ULucjWUTrDvaJzCyhFoVbDoNS6Zum2Du",
  "redeemScript": "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
}

bitcoin-cli createmultisig 1 '["045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d","02ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831","0224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e07"]'
{
  "address": "3GiimyxF1R5VixfBFAbQZbuy9EesD2r6n1",
  "redeemScript": "5141045897fee25bd7c5692510b2f50fcae9aa20fbc4d49d59814f4c7fdb5c4bc6eb1c0ce382458f9588e922e0d509ed8d34856787380075b00418b02e0bf7c652ef9d2102ac46c6d74d15e60f4f1035ff07ef740aca1d68d55ba0b8d336a73d7a35858831210224a4dc5620714a9ecf67a09583d1e4c04f5bedb8ecea99028da05bb15a2a7e0753ae"
}

```

The point is that, later, I noticed that with certain public keys the two methods generate the same hash:

```
bitcoin-cli addmultisigaddress 1 '["03fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d7617631146","02ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd101","04633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac204"]'
{
  "address": "32AVnYUUSvm4bGgEXoQ2zuFAJBPH4P31Gi",
  "redeemScript": "512103fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d76176311462102ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd1014104633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac20453ae"
}

bitcoin-cli createmultisig 1 '["03fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d7617631146","02ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd101","04633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac204"]'
{
  "address": "32AVnYUUSvm4bGgEXoQ2zuFAJBPH4P31Gi",
  "redeemScript": "512103fc5e16d0ece343a94735ca467d5812922fcc30e3ce43ceaf3cff7d76176311462102ea92a0cd1738cef7502e42fe119a322845f8f1a2dd9b7216635e17dd2fffd1014104633794a75bfbd9fb2bc6bd54836831c0916dc27f9ac528045cc9352bb2cc97a003b3a6ae397101d801f3d95e6a153368b939aaf7b27bd3a5bb8a30ed92aac20453ae"
}

```

I don't get how this can be possible if the inputs and the redeem scripts are the same.

What's the difference between the two cases and in general between a legacy multisig transaction and a segwit one?

Reading raw transactions data from the blockchain, how is possible to know whether a script needs to be hashed using legacy or segwit?

**Tags:** blockchain, segregated-witness, raw-transaction, p2sh, raw-data

> **Comments:**
> **username_1**: I'm unsure why that is happening. If there is at least one uncompressed public key both methods should give legacy p2sh addresses. However, i noticed that in the first case if you push the uncompressed public key from position 1 to position 2 or 3 while passing the RPC call, we get the same p2sh addresses by both methods.  
> **username_0**: This is a good point @username_1, thank you. I didn't though that if one of the pubkeys is uncompressed, the p2sh needs to be legacy because segwit does not support uncompressed keys. However, it's not enough for a general rule because I think that also in the case where all the pubkeys are compressed, the p2sh can still be legacy  
> **username_1**: that is correct, but what I am perplexed by is why the two RPC calls are giving different addresses in your first case. You can check, if you shift the uncompressed public key in the first case in the last position and run both RPC calls, they will give the same P2SH addresses. What I'm having trouble understanding is why they are different if uncompressed public key is first  
> **username_2**: In both examples, is the uncompressed pubkey part of your wallet? I think there's a bug here.  

---

## 1 answers

### Answer by username_2 on 2019-05-09. Score: 0 | Accepted answer

I believe the behavior you are seeing is actually a bug.

By default, `addmultisigaddress` uses p2sh-segwit which is the default address type for the wallet. By default `createmultisig` uses legacy. These are two different address types, and normally, you get two different addresses.

However segwit does not allow uncompressed public keys. So when the redeemScript is being created, if an uncompressed public key is detected, both RPCs will return legacy addresses. This is why you see the same address in the second example.

But I believe there is a bug. Your first example should also give the same legacy addresses, but it does not. I think that this is because the uncompressed pubkey is not part of the wallet, so it does not correctly detect that it is an uncompressed pubkey. Thus `addmultisigaddress` follows its default to give you the p2sh-segwit address and `createmultisig` follows its default to give you the legacy address.

> Reading raw transactions data from the blockchain, how is possible to know whether a script needs to be hashed using legacy or segwit?

For p2sh-segwit, the redeemScript is not actually the redeemScript you get from the RPCs. Rather it is the script for a P2WSH output. The "redeemScript" is actually the witnessScript for the P2WSH script that is the actual redeemScript. The script type (either in the scriptPubKey or in the redeemScript) determine whether that output is segwit or not.

> **Comments:**
> **username_1**: I agree there is a bug, but even if those public keys are not added to the wallet and you shift the uncompressed public key from the first position to last then both of them generate a legacy address. This works only if the uncompressed public key is in the last position. That is the reason why in the second case in the question, both the addresses are the same (uncompressed public key is in the last position in that example).  

---

