Using different sighashes on multisig

[garlonicon]

It is not obvious that different sighashes can be used on multisig addresses. It is a very useful property, but it has one drawback: such signatures cannot be trivially combined, because compressing N signatures into one in N-of-N multisig works only for the same sighashes.

Some sample transaction:

Code:

decoderawtransaction 0200000000010151b78b5ca8149496b69716add0030371c858d7e1be4f8e412b584c0badfe46aa0000000000fdffffff0250c30000000000001600146c650b6526b5966ee8b86fd03668065de0afafd7204e0000000000001600141a92f4979d7337965cbaa10cfbdbf1a40e04b12404004730440220262a0f1a8b52dc0ad5489781c65e9cff49739f54d4b7db6867e31413c7a2974a02203c86ef29c9bd029bcb9ed29948762a6730ceb3bb052a2063f75ce05546bfc5948347304402203b64eaacc1779b01ce12cc0fe5d0efe8d38b645a0bb15580f8354fed2d7fd055022037e8d06c62b96cc494adffa215381a1a2504327eb52008eb0ef1469180cb5ab4814752210368846b19d74a43c3fc45745433d8272488b7e6583e92cea4159cf821403ac3b22103649487a3562069d36e01fe9aef0982eafe232a55d7d42805b0ac351f1de31a3452ae00000000
{
  "txid": "d7f5d5d1954fc3ae400a0f029e41fff8c3552982d5d8cc994893f70c7e041586",
  "hash": "2151082fb5eb42e129b2f747533cbb7c833285aa4369c47b3abe4dbe5f264ffd",
  "version": 2,
  "size": 333,
  "vsize": 168,
  "weight": 672,
  "locktime": 0,
  "vin": [
    {
      "txid": "aa46fead0b4c582b418e4fbee1d758c8710303d0ad1697b6969414a85c8bb751",
      "vout": 0,
      "scriptSig": {
        "asm": "",
        "hex": ""
      },
      "txinwitness": [
        "",
        "30440220262a0f1a8b52dc0ad5489781c65e9cff49739f54d4b7db6867e31413c7a2974a02203c86ef29c9bd029bcb9ed29948762a6730ceb3bb052a2063f75ce05546bfc59483",
        "304402203b64eaacc1779b01ce12cc0fe5d0efe8d38b645a0bb15580f8354fed2d7fd055022037e8d06c62b96cc494adffa215381a1a2504327eb52008eb0ef1469180cb5ab481",
        "52210368846b19d74a43c3fc45745433d8272488b7e6583e92cea4159cf821403ac3b22103649487a3562069d36e01fe9aef0982eafe232a55d7d42805b0ac351f1de31a3452ae"
      ],
      "sequence": 4294967293
    }
  ],
  "vout": [
    {
      "value": 0.00050000,
      "n": 0,
      "scriptPubKey": {
        "asm": "0 6c650b6526b5966ee8b86fd03668065de0afafd7",
        "desc": "addr(tb1qd3jskefxkktxa69cdlgrv6qxths2lt7hw0dy5v)#j09drxz8",
        "hex": "00146c650b6526b5966ee8b86fd03668065de0afafd7",
        "address": "tb1qd3jskefxkktxa69cdlgrv6qxths2lt7hw0dy5v",
        "type": "witness_v0_keyhash"
      }
    },
    {
      "value": 0.00020000,
      "n": 1,
      "scriptPubKey": {
        "asm": "0 1a92f4979d7337965cbaa10cfbdbf1a40e04b124",
        "desc": "addr(tb1qr2f0f9uawvmevh965yx0hkl35s8qfvfy2whegs)#h6snk0pm",
        "hex": "00141a92f4979d7337965cbaa10cfbdbf1a40e04b124",
        "address": "tb1qr2f0f9uawvmevh965yx0hkl35s8qfvfy2whegs",
        "type": "witness_v0_keyhash"
      }
    }
  ]
}

As we can see, we have 0x83 for the first public key, and 0x81 for the second. That means SIGHASH_SINGLE|SIGHASH_ANYONECANPAY in the first case (so only 50k sats are signed), and 0x81 in the second case (so all outputs are signed). New coins can be added to such transaction, but unfortunately, I have no idea how to make a single Schnorr signature to cover that directly in the protocol, and as far as I know, it is not possible to join signatures that use different sighashes, because then they sign different messages. But technically, I believe it could be possible, for example to list all sighashes, and then automatically compute needed parts, based on provided transaction.

[gmaxwell]

Combining them also doesn't work for another reason: The whole point of using different sighashes is so that the txn can be changed by some of the parties without the involvement of the others, yet a combined signature requires all parties to be present.

What could be done (though not with current consensus rules) is non-interactive half-aggregation.   With half-aggregation the S values from the different signatures get combined but the R values are distinct-- so asymptotically the signatures end up half the size.  Unfortunately, this prevents completely concealing the policy as a normal threshold signature would do -- so you don't get the privacy gains, but just a space gain.

The half aggregated signatures are also pretty much as slow to validate as individual signatures (in batch verification).


I think that in general there is pretty little reason though to actually post weird sighashes to the blockchain:  You could compute txn offchain as a backup, but then assuming all parties are available, replace them with a final sighash all version signed with a threshold signature. ... and once you're thinking in terms of only using the masked versions as a backup there isn't really much need to aggregate anything at all since unless something goes wrong only the N of N is ever going to get posted to the blockchain.