<p>Where do you see that multisig addresses need to have the redeemscript in order to spend to them? The redeemscript is only necessary for spending from a multisig address, there is no need for it when spending to one. Multisig addresses (aka P2SH addresses) begin with a 3. Your use case does not seem to require anything special, just a typical m-of-n multisig which many wallets can do.</p>

CC BY-SA 3.0
2017-06-19T20:47:41.650Z
Yes, thx! I had a false assumption in my first bullet point. I need to tell the sender, send me funds to my "3xxx" address (a P2SH address). I don't provide a  redeem script, I provide the hash of a redeem script, which is Base58check encoded with a prefix of '05':
   base58check.Encode("05",  RIPEMD160(SHA256(redeemScript)))
The sender's wallet must know, that it cannot use P2PKH (OP_DUP, OP_HASH, PUBKEYHASH, OP_EQUALVERIFY, OP_CHKSIG), as I assumed in my example above. The wallet must use P2SH logic (OP_HASH160, P2SHAddress, OP_EQUAL) in the pubkey script.
pebwindkraft
CC BY-SA 3.0
2017-06-19T20:57:49.407Z
and what happens on the stack, is well described here: https://bitcoin.stackexchange.com/questions/42521/pay-to-script-hash-execution
pebwindkraft
CC BY-SA 3.0
2017-06-16T20:03:43.973Z
2017-06-16T20:03:43.973Z
Ava Chow
<p>Are you saying it's difficult because the user would have to sign their own transaction manually? P2SH isn't really at a "typical" user level. For multisig to work as it's intended to, it assumes each potential signor knows how to sign a transaction. A website that would require it's users to sign their own P2SH transactions would have a pretty small target audience. Aside from building your own native desktop app that makes multisig signing easy for the average user, I'm not sure what other options you would have. </p>

CC BY-SA 3.0
2017-05-10T05:58:24.097Z
yup, multisig "as is" has a better use case for escrow services, where each party knows each other. On my website model, the users wouldn't go into a contract with my company, they just would like to spend. I was trying to secure the collected funds, so that no single person can run away with it. Maybe an elegant solution appears when lightning comes in (reducing fees).
pebwindkraft
CC BY-SA 3.0
2017-05-10T01:06:22.133Z
2017-05-10T01:06:22.133Z
m1xolyd1an
<p>I think I found a way to do what I need. I offer a QR code qith the address and the redeem script, each in its own line. 
I understand that the wallets might not understand it, and there is no "automatic" creation of the transaction. But it is a step towards the right direction, sufficient for me.  </p>

CC BY-SA 3.0
2017-05-17T18:29:13.173Z
2017-05-17T18:29:13.173Z
pebwindkraft
<p>I am trying to sort out the use case of a published funding address on a web page, to which everyone can spend. Internally in our company, I want to avoid, that a single person can spend these funds. It shall require  more than one signature, to be able to spend the funds. I had the idea to use a multisig address, but this seems to be unsuccessful. The many stackexchange links don't cover this scenario, they all seem to cover how to spend from msig addresses... </p>

<p>When using a multisig adress, it looks like spends to this address requires the redeemscript. All examples I found use the redeemscript. So this is somehow a no-go for a multisig address on a webpage?</p>

<p>What I have done so far:
- I was thinking that "people" could send to the msig adress from a normal wallet (aka P2PKH script). That doesn't work out, as the pubkey script wouldn't find "true" on the stack. Given a standard pubkey script would require s.th. like this:</p>

<pre><code>    DUP     HASH     PKH     EQ_VFY CHK_SIG
     |       |        |        |      |
     |       |        | PKHASH |      |
     |  PK   | PKHASH | PKHASH |      |
PK?  |  PK   |   PK   |  PK    | PK   |
SIG  |  SIG  |   SIG  |  SIG   | SIG  |  TRUE/FALSE
</code></pre>

<p>The first column (SIG and PK?) being the sigscript. For the multisig address there is no public key in the first column. For sure I could play with the redeem script at the very beginning, and hash it, to satisfy the "OP_EQUALVERIFY". But then the script wouldn't terminate "TRUE" at the end, cause it would leave the sig and a "hashed" hash on the stack. </p>

<ul>
<li><p>I could publish the redeemscript. Disadvantage: this makes the user experience difficult</p></li>
<li><p>I could use a std. P2PKH address, and "forward" regularely the funds from the webpage P2PKH address to a multisig in the background. Disadvantage: with current fees, nearly idiotic, when only small amounts are spent. (Yes, I could write code to collect until spent amount >= tx fees ...)</p></li>
</ul>

<p>Is there an easy (more intelligent) way to receive bitcoin payments on a website, that come with a condition to be spent only with multiple signatures? </p>

CC BY-SA 3.0
2017-05-17T19:28:47.507Z
There is no way to spend from a multisig without knowing the script, just like there is no way to spend from a public key without knowing the secret key.
Pieter Wuille
<script><multi-signature><website-integration>
Multisig address for website?
pebwindkraft
# Multisig address for website?

(Asked by: username_0 on 2017-05-09)

I am trying to sort out the use case of a published funding address on a web page, to which everyone can spend. Internally in our company, I want to avoid, that a single person can spend these funds. It shall require more than one signature, to be able to spend the funds. I had the idea to use a multisig address, but this seems to be unsuccessful. The many stackexchange links don't cover this scenario, they all seem to cover how to spend from msig addresses...

When using a multisig adress, it looks like spends to this address requires the redeemscript. All examples I found use the redeemscript. So this is somehow a no-go for a multisig address on a webpage?

What I have done so far:
- I was thinking that "people" could send to the msig adress from a normal wallet (aka P2PKH script). That doesn't work out, as the pubkey script wouldn't find "true" on the stack. Given a standard pubkey script would require s.th. like this:

```
    DUP     HASH     PKH     EQ_VFY CHK_SIG
     |       |        |        |      |
     |       |        | PKHASH |      |
     |  PK   | PKHASH | PKHASH |      |
PK?  |  PK   |   PK   |  PK    | PK   |
SIG  |  SIG  |   SIG  |  SIG   | SIG  |  TRUE/FALSE

```

The first column (SIG and PK?) being the sigscript. For the multisig address there is no public key in the first column. For sure I could play with the redeem script at the very beginning, and hash it, to satisfy the "OP\_EQUALVERIFY". But then the script wouldn't terminate "TRUE" at the end, cause it would leave the sig and a "hashed" hash on the stack.

* I could publish the redeemscript. Disadvantage: this makes the user experience difficult
* I could use a std. P2PKH address, and "forward" regularely the funds from the webpage P2PKH address to a multisig in the background. Disadvantage: with current fees, nearly idiotic, when only small amounts are spent. (Yes, I could write code to collect until spent amount >= tx fees ...)

Is there an easy (more intelligent) way to receive bitcoin payments on a website, that come with a condition to be spent only with multiple signatures?

**Tags:** script, multi-signature, website-integration

> **Comments:**
> **username_1**: There is no way to spend from a multisig without knowing the script, just like there is no way to spend from a public key without knowing the secret key.  

---

## 3 answers

### Answer by username_2 on 2017-06-16. Score: 0 | Accepted answer

Where do you see that multisig addresses need to have the redeemscript in order to spend to them? The redeemscript is only necessary for spending from a multisig address, there is no need for it when spending to one. Multisig addresses (aka P2SH addresses) begin with a 3. Your use case does not seem to require anything special, just a typical m-of-n multisig which many wallets can do.

> **Comments:**
> **username_0**: Yes, thx! I had a false assumption in my first bullet point. I need to tell the sender, send me funds to my "3xxx" address (a P2SH address). I don't provide a  redeem script, I provide the hash of a redeem script, which is Base58check encoded with a prefix of '05':    base58check.Encode("05",  RIPEMD160(SHA256(redeemScript))) The sender's wallet must know, that it cannot use P2PKH (OP_DUP, OP_HASH, PUBKEYHASH, OP_EQUALVERIFY, OP_CHKSIG), as I assumed in my example above. The wallet must use P2SH logic (OP_HASH160, P2SHAddress, OP_EQUAL) in the pubkey script.  
> **username_0**: and what happens on the stack, is well described here: https://bitcoin.stackexchange.com/questions/42521/pay-to-script-hash-execution  

---

### Answer by username_3 on 2017-05-10. Score: 0

Are you saying it's difficult because the user would have to sign their own transaction manually? P2SH isn't really at a "typical" user level. For multisig to work as it's intended to, it assumes each potential signor knows how to sign a transaction. A website that would require it's users to sign their own P2SH transactions would have a pretty small target audience. Aside from building your own native desktop app that makes multisig signing easy for the average user, I'm not sure what other options you would have.

> **Comments:**
> **username_0**: yup, multisig "as is" has a better use case for escrow services, where each party knows each other. On my website model, the users wouldn't go into a contract with my company, they just would like to spend. I was trying to secure the collected funds, so that no single person can run away with it. Maybe an elegant solution appears when lightning comes in (reducing fees).  

---

### Answer by username_0 on 2017-05-17. Score: 0

I think I found a way to do what I need. I offer a QR code qith the address and the redeem script, each in its own line.
I understand that the wallets might not understand it, and there is no "automatic" creation of the transaction. But it is a step towards the right direction, sufficient for me.


---

