Multisig scripts hashing (p2sh): difference between legacy and segwit

1

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?

Michele

Posted 2019-05-08T11:34:17.053

Reputation: 113

1I'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 – 2019-05-08T13:01:46.420

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 – 2019-05-08T13:16:39.673

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 – 2019-05-08T14:32:25.243

In both examples, is the uncompressed pubkey part of your wallet? I think there's a bug here. – Andrew Chow – 2019-05-09T16:56:27.230

Answers

0

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.

Andrew Chow

Posted 2019-05-08T11:34:17.053

Reputation: 40 910

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 – 2019-05-09T17:18:17.287

Asked: 2019-05-08T11:34:17.053

Viewed: 162 times

Active: 2019-05-09T17:03:08.957