<blockquote>
<p>My assumption is, since one of the public keys of the multisig script is managed by the wallet, I should be able to &quot;sign by wallet&quot;.</p>
</blockquote>
<p>That is not how descriptor wallets work.</p>
<p>If you want them to be able to sign for something, there needs to be a descriptor in the wallet for it. Without that, the wallet won't consider that output to be something that even belongs to it, much less know how to sign for it, as the ways all its keys can be combined in multisigs is not practically enumerable.</p>
<p>To do so, use <code>importdescriptors</code> with a descriptor that describes your multisig policy exactly. For example <code>wsh(multi(2,KEY1,KEY2,KEY3))</code> is a descriptor for P2WSH addresses for 2-of-3 multisig scripts using the 3 key expressions provided. These key expressions can be xpubs or xprvs, and include derivation paths.</p>
<p>Further, you really want to use the PSBT-based RPCs for this, rather than the raw transaction based RPCs. PSBT carries far more information about the to be signed transaction, which may be relevant if some signers don't have access to the full script or UTXOs.</p>

CC BY-SA 4.0
2023-03-29T04:24:19.617Z
Do I importdescriptors into the original wallet that generated the addres whose public key is one of the three of the multisig address? Also, regarding KEY1, KEY2, KEY3, can I use the actual public keys taken from addresses instead of xpubs?
Meglio
CC BY-SA 4.0
2023-03-29T06:36:21.573Z
It doesn't matter which wallet you import the descriptor; it is self-sufficient in any case. The KEYn expressions can be xpubs, xprvs (with derivation paths), hex public keys, or WIF private keys. Note that you'll need at least one privkey or xprv, or you won't have any ability to sign. Of course, if they're just individual keys and not derivation paths, you'll only get a single address, and they can't be made active.
Pieter Wuille
CC BY-SA 4.0
2023-03-29T07:26:41.997Z
"you'll need at least one privkey or xprv, or you won't have any ability to sign" - this is what is the most confusing to me. If I created the address through bitcoin core, in a descriptor wallet, I don't get any private keys nor can I export them. They're handled by the core and are stored somewhere in the wallet. So at the end of the day, I don't have a way to sign the transaction? -- because I cannot export the key, nor I can import a descriptor that has at least one privkey or xprv etc.
Meglio
CC BY-SA 4.0
2023-03-29T08:10:51.563Z
You can pass a parameter to the `listdescriptors` RPC to get the private keys too.
Pieter Wuille
CC BY-SA 4.0
2023-03-29T09:12:00.050Z
Hm, so what you're saying is that, I can first retrieve the private key with using `listdescriptors`, then import it again as part of the multisig-address descriptor, then sign the transaction. At the end of the day, this is no better than `dumpprivkey` and then signing with a legacy wallet. One way or the other, it cancels the whole idea of what I'm trying to do - i.e. to sign a transaction without extracting the keys and moving them to the API caller and then back to the bitcoin core.
Meglio
CC BY-SA 4.0
2023-03-29T01:25:29.843Z
2023-03-29T01:31:36.167Z
2023-03-29T01:31:36.167Z
Pieter Wuille
<p>I created a descriptor wallet in bitcoin core 24.</p>
<p>Next, I created a new address with using <code>getnewaddress</code>.</p>
<p>I took pubkey of that address, and used it as one of the three pubkeys when generating a typical 2-of-3 multisig address.</p>
<p>After funding the multisig address, I am trying to sign a raw transaction that spends UTXOs from the multisig address.</p>
<p>I am trying <code>signrawtransactionwithwallet</code>, but I'm getting the following error:</p>
<pre><code>&quot;errors&quot;: [
      {
        &quot;txid&quot;: &quot;...&quot;,
        &quot;vout&quot;: 0,
        &quot;witness&quot;: [],
        &quot;scriptSig&quot;: &quot;&quot;,
        &quot;sequence&quot;: ...,
        &quot;error&quot;: &quot;Unable to sign input, invalid stack size (possibly missing key)&quot;
      }
    ]
</code></pre>
<p>My assumption is, since one of the public keys of the multisig script is managed by the wallet, I should be able to &quot;sign by wallet&quot;. What am I doing wrong.</p>

<bitcoin-core><multi-signature><signrawtransaction><output-script-descriptors>
signrawtransactionwithwallet for a multisig-transaction, after getnewaddress
Meglio
# signrawtransactionwithwallet for a multisig-transaction, after getnewaddress

(Asked by: username_0 on 2023-03-27)

I created a descriptor wallet in bitcoin core 24.

Next, I created a new address with using `getnewaddress`.

I took pubkey of that address, and used it as one of the three pubkeys when generating a typical 2-of-3 multisig address.

After funding the multisig address, I am trying to sign a raw transaction that spends UTXOs from the multisig address.

I am trying `signrawtransactionwithwallet`, but I'm getting the following error:

```
"errors": [
      {
        "txid": "...",
        "vout": 0,
        "witness": [],
        "scriptSig": "",
        "sequence": ...,
        "error": "Unable to sign input, invalid stack size (possibly missing key)"
      }
    ]

```

My assumption is, since one of the public keys of the multisig script is managed by the wallet, I should be able to "sign by wallet". What am I doing wrong.

**Tags:** bitcoin-core, multi-signature, signrawtransaction, output-script-descriptors


---

## 1 answers

### Answer by username_1 on 2023-03-29. Score: 1

> My assumption is, since one of the public keys of the multisig script is managed by the wallet, I should be able to "sign by wallet".

That is not how descriptor wallets work.

If you want them to be able to sign for something, there needs to be a descriptor in the wallet for it. Without that, the wallet won't consider that output to be something that even belongs to it, much less know how to sign for it, as the ways all its keys can be combined in multisigs is not practically enumerable.

To do so, use `importdescriptors` with a descriptor that describes your multisig policy exactly. For example `wsh(multi(2,KEY1,KEY2,KEY3))` is a descriptor for P2WSH addresses for 2-of-3 multisig scripts using the 3 key expressions provided. These key expressions can be xpubs or xprvs, and include derivation paths.

Further, you really want to use the PSBT-based RPCs for this, rather than the raw transaction based RPCs. PSBT carries far more information about the to be signed transaction, which may be relevant if some signers don't have access to the full script or UTXOs.

> **Comments:**
> **username_0**: Do I importdescriptors into the original wallet that generated the addres whose public key is one of the three of the multisig address? Also, regarding KEY1, KEY2, KEY3, can I use the actual public keys taken from addresses instead of xpubs?  
> **username_1**: It doesn't matter which wallet you import the descriptor; it is self-sufficient in any case. The KEYn expressions can be xpubs, xprvs (with derivation paths), hex public keys, or WIF private keys. Note that you'll need at least one privkey or xprv, or you won't have any ability to sign. Of course, if they're just individual keys and not derivation paths, you'll only get a single address, and they can't be made active.  
> **username_0**: "you'll need at least one privkey or xprv, or you won't have any ability to sign" - this is what is the most confusing to me. If I created the address through bitcoin core, in a descriptor wallet, I don't get any private keys nor can I export them. They're handled by the core and are stored somewhere in the wallet. So at the end of the day, I don't have a way to sign the transaction? -- because I cannot export the key, nor I can import a descriptor that has at least one privkey or xprv etc.  
> **username_1**: You can pass a parameter to the `listdescriptors` RPC to get the private keys too.  
> **username_0**: Hm, so what you're saying is that, I can first retrieve the private key with using `listdescriptors`, then import it again as part of the multisig-address descriptor, then sign the transaction. At the end of the day, this is no better than `dumpprivkey` and then signing with a legacy wallet. One way or the other, it cancels the whole idea of what I'm trying to do - i.e. to sign a transaction without extracting the keys and moving them to the API caller and then back to the bitcoin core.  

---

