<p>No, I don’t think it can be achieved using <code>SIGHASH_ALL | SIGHASH_ANYONECANPAY</code>. Because there is always an output with a preset value, as you’ve mentioned, any surplus will be treated as the mining fee in this case.</p>

<p>However, I think it’s still achievable under a more complex design. Let’s take a close look at the problem. Since it’s crowdfunding, we can assume that,</p>

<ul>
<li>The participants are willing to donate the money, and,</li>
<li>They want their money back if the crowdfunding fails, i.e., the cap is not reached.</li>
</ul>

<p>The problem is, if crowdfunding with a cap of 10 BTC is reached, while in the end, it receives a total donation of 11 BTC, how can the fundraiser get the extra 1 BTC as well?</p>

<p>Applying <code>SIGHASH_ALL | SIGHASH_ANYONECANPAY</code> won’t help here, the extra 1 BTC will be treated as the transaction fee. Borrowing some ideas from the lightning network, I think a feasible solution can be achieved using Bitcoin Script. Here’s the draft,</p>

<p><strong>Scenario</strong></p>

<p>Crowdfunding with a cap of 10 BTC is initiated. If the cap is not reached in 60 days, the money is returned to the participants. Otherwise, all the money goes to the fundraiser.</p>

<p><strong>Stage One - the participant sends money</strong></p>

<ol>
<li>The participant generates a secret, called it <code>payment_secret</code>, and hash it to produce <code>payment_hash</code>(for instance, using RIPEMD160).</li>
<li>The participant creates a transaction with an output, its locking script is specified as follows, in which, there are two possible paths to spend it,

<ul>
<li>If the <code>payment_secret</code> is presented, the money goes to the fundraiser.</li>
<li>Else, if 60 days passed, the money goes to the participant.</li>
</ul></li>
</ol>

<p>The script,</p>

<pre><code>OP_IF
    # To the fundraiser if payment secret is supplied
    OP_HASH160 &lt;RIPEMD160(payment_hash)&gt; OP_EQUALVERIFY
    &lt;fundraiser_pubkey&gt; OP_CHECKSIG
OP_ELSE
    # To the participant after 60 days
    &lt;60 days later&gt; OP_CHECKLOCKTIMEVERIFY
    &lt;participant_pubkey&gt; OP_CHECKSIG
OP_ENDIF
</code></pre>

<p>where, the fundraiser can spend it using <code>&lt;fundraiser_sig&gt; &lt;payment_secret&gt; 1</code>, and the participant can spend it using <code>&lt;participant_sig&gt; 0</code>.</p>

<p><strong>Stage Two - the fundraiser collects/returns the money</strong></p>

<ol>
<li>If the cap is reached, the fundraiser will ask all the participants to reveal the <code>payment_secret</code> to him/her. The fundraiser will be able to get all the money, even it’s beyond the cap. To spend the outputs, the fundraiser use <code>&lt;fundraiser_sig&gt; &lt;payment_secret&gt; 1</code> to unlock them.</li>
<li>If the cap is not reached, i.e., the 60-day time limit has reached, all the participants can now take their money back, using <code>&lt;participant_sig&gt; 0</code> to unlock them.</li>
</ol>

<p>So the surplus problem is solved, but this approach has many downsides,</p>

<ul>
<li>There are too many transactions, especially comparing to the <code>SIGHASH_ALL | SIGHASH_ANYONECANPAY</code> approach, although it may be optimized.</li>
<li>The participants need to know how much money has been raised. This requires the fundraiser collecting all the transactions and show them to all the participants, which might require a centralized service, e.g., a website.</li>
</ul>

CC BY-SA 4.0
2019-12-04T15:46:00.083Z
2019-12-04T17:47:32.233Z
2019-12-04T17:47:32.233Z
yyforyongyu
<p>Not by only using <code>SIGHASH_ALL|SIGHASH_ANYONECANPAY</code>. This is because the outputs cannot be modified.</p>

<blockquote>
  <p>SIGHASH_ALL|SIGHASH_ANYONECANPAY signs all of the outputs but only
  this one input, and it also allows anyone to add or remove other
  inputs, so anyone can contribute additional satoshis but they cannot
  change how many satoshis are sent nor where they go. - <a href="https://bitcoin.org/en/developer-guide#signature-hash-types" rel="nofollow noreferrer">https://bitcoin.org/en/developer-guide#signature-hash-types</a>.</p>
</blockquote>

<p>But, the fundraiser does not have to submit the transaction that includes additional funds (because that would not benefit them, only miners). Once the first transaction is complete (minimum has been met), then others can verify that the minimum amount of funds have been raised, and then just create a normal transaction to the fundraiser.</p>

CC BY-SA 4.0
2018-09-05T07:14:08.023Z
What if when the minimum is first reached, it is exceeded by a large amount? For example, 1st pledge is 50 Bitcoins and 2nd is also 50 while the minimum is 60. Any way to get around this, with or without ANYONECANPAY?
sinoTrinity
CC BY-SA 4.0
2018-09-05T11:58:28.533Z
What do you mean "get around this"?
JBaczuk
CC BY-SA 4.0
2018-09-05T20:23:05.933Z
Getting around this constraint and receive full pledged amount, e.g., 50+50 Bitcoins?
sinoTrinity
CC BY-SA 4.0
2018-09-05T20:43:12.163Z
You can create multiple transactions. If a funder is worried about not meeting a minimum, then they can wait until the first `SIGHASH_ANYONECANPAY` transaction confirms.
JBaczuk
CC BY-SA 4.0
2018-09-10T20:12:49.777Z
> multiple transactions?
What do u mean?
>  first SIGHASH_ANYONECANPAY transaction confirms?
SIGHASH_ANYONECANPAY inputs are merged into a final transaction after minimum is reached and broadcast. What do u mean first tx confirms? There is only 1 tx.
sinoTrinity
CC BY-SA 4.0
2018-09-10T20:42:23.657Z
After the minimum is reached, the transaction is broadcast, mined, and confirmed. Now investors can verify that the minimum was met. There is no need to add surplus to the same transaction, so why not allow investors to just send additional transactions after the first tx is confirmed?
JBaczuk
CC BY-SA 4.0
2018-09-10T21:48:54.453Z
How would it work if 1st pledge is 50 Bitcoins and 2nd is also 50 while the minimum is 60?
sinoTrinity
CC BY-SA 4.0
2018-09-10T22:32:54.887Z
You can warn users if their pledge goes over before they commit. That way, they can create a separate normal transaction for the excess after it's broadcasted.
JBaczuk
CC BY-SA 4.0
2018-09-04T14:01:37.500Z
2018-09-04T14:01:37.500Z
JBaczuk
<p>ANYONECANPAY can be used for <a href="https://curiosity-driven.org/bitcoin-contracts#kickstarter" rel="nofollow noreferrer">crowdfunding</a>, where pledged donations cannot be spent unless funding goal/soft cap is reached. But since output is committed, when soft cap is exceed, all the surplus will go to transaction fee. Any way to make the exceeded part to go to the fundraiser as ICOs typically do?</p>

<blockquote>
  <p>ALL|ANYONECANPAY</p>
  
  <p>This construction can be used to make a "crowdfunding”-style
  transaction. Someone attempting to raise funds can construct a
  transaction with a single output. The single output pays the "goal"
  amount to the fundraiser. Such a transaction is obviously not valid,
  as it has no inputs. However, others can now amend it by adding an
  input of their own, as a donation. They sign their own input with
  ALL|ANYONECANPAY. Unless enough inputs are gathered to reach the value
  of the output, the transaction is invalid. Each donation is a
  "pledge," which cannot be collected by the fundraiser until the entire
  goal amount is raised.</p>
</blockquote>

<script>
How to let surplus go to fundraiser in ANYONECANPAY crowdfunding script?
sinoTrinity
# How to let surplus go to fundraiser in ANYONECANPAY crowdfunding script?

(Asked by: username_0 on 2018-09-03)

ANYONECANPAY can be used for [crowdfunding](https://curiosity-driven.org/bitcoin-contracts#kickstarter), where pledged donations cannot be spent unless funding goal/soft cap is reached. But since output is committed, when soft cap is exceed, all the surplus will go to transaction fee. Any way to make the exceeded part to go to the fundraiser as ICOs typically do?

> ALL|ANYONECANPAY
>
> This construction can be used to make a "crowdfunding”-style
> transaction. Someone attempting to raise funds can construct a
> transaction with a single output. The single output pays the "goal"
> amount to the fundraiser. Such a transaction is obviously not valid,
> as it has no inputs. However, others can now amend it by adding an
> input of their own, as a donation. They sign their own input with
> ALL|ANYONECANPAY. Unless enough inputs are gathered to reach the value
> of the output, the transaction is invalid. Each donation is a
> "pledge," which cannot be collected by the fundraiser until the entire
> goal amount is raised.

**Tags:** script


---

## 2 answers

### Answer by username_1 on 2019-12-04. Score: 2

No, I don’t think it can be achieved using `SIGHASH_ALL | SIGHASH_ANYONECANPAY`. Because there is always an output with a preset value, as you’ve mentioned, any surplus will be treated as the mining fee in this case.

However, I think it’s still achievable under a more complex design. Let’s take a close look at the problem. Since it’s crowdfunding, we can assume that,

* The participants are willing to donate the money, and,
* They want their money back if the crowdfunding fails, i.e., the cap is not reached.

The problem is, if crowdfunding with a cap of 10 BTC is reached, while in the end, it receives a total donation of 11 BTC, how can the fundraiser get the extra 1 BTC as well?

Applying `SIGHASH_ALL | SIGHASH_ANYONECANPAY` won’t help here, the extra 1 BTC will be treated as the transaction fee. Borrowing some ideas from the lightning network, I think a feasible solution can be achieved using Bitcoin Script. Here’s the draft,

**Scenario**

Crowdfunding with a cap of 10 BTC is initiated. If the cap is not reached in 60 days, the money is returned to the participants. Otherwise, all the money goes to the fundraiser.

**Stage One - the participant sends money**

1. The participant generates a secret, called it `payment_secret`, and hash it to produce `payment_hash`(for instance, using RIPEMD160).
2. The participant creates a transaction with an output, its locking script is specified as follows, in which, there are two possible paths to spend it,
   * If the `payment_secret` is presented, the money goes to the fundraiser.
   * Else, if 60 days passed, the money goes to the participant.

The script,

```
OP_IF
    # To the fundraiser if payment secret is supplied
    OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
    <fundraiser_pubkey> OP_CHECKSIG
OP_ELSE
    # To the participant after 60 days
    <60 days later> OP_CHECKLOCKTIMEVERIFY
    <participant_pubkey> OP_CHECKSIG
OP_ENDIF

```

where, the fundraiser can spend it using `<fundraiser_sig> <payment_secret> 1`, and the participant can spend it using `<participant_sig> 0`.

**Stage Two - the fundraiser collects/returns the money**

1. If the cap is reached, the fundraiser will ask all the participants to reveal the `payment_secret` to him/her. The fundraiser will be able to get all the money, even it’s beyond the cap. To spend the outputs, the fundraiser use `<fundraiser_sig> <payment_secret> 1` to unlock them.
2. If the cap is not reached, i.e., the 60-day time limit has reached, all the participants can now take their money back, using `<participant_sig> 0` to unlock them.

So the surplus problem is solved, but this approach has many downsides,

* There are too many transactions, especially comparing to the `SIGHASH_ALL | SIGHASH_ANYONECANPAY` approach, although it may be optimized.
* The participants need to know how much money has been raised. This requires the fundraiser collecting all the transactions and show them to all the participants, which might require a centralized service, e.g., a website.


---

### Answer by username_2 on 2018-09-04. Score: 1

Not by only using `SIGHASH_ALL|SIGHASH_ANYONECANPAY`. This is because the outputs cannot be modified.

> SIGHASH\_ALL|SIGHASH\_ANYONECANPAY signs all of the outputs but only
> this one input, and it also allows anyone to add or remove other
> inputs, so anyone can contribute additional satoshis but they cannot
> change how many satoshis are sent nor where they go. - <https://bitcoin.org/en/developer-guide#signature-hash-types>.

But, the fundraiser does not have to submit the transaction that includes additional funds (because that would not benefit them, only miners). Once the first transaction is complete (minimum has been met), then others can verify that the minimum amount of funds have been raised, and then just create a normal transaction to the fundraiser.

> **Comments:**
> **username_0**: What if when the minimum is first reached, it is exceeded by a large amount? For example, 1st pledge is 50 Bitcoins and 2nd is also 50 while the minimum is 60. Any way to get around this, with or without ANYONECANPAY?  
> **username_2**: What do you mean "get around this"?  
> **username_0**: Getting around this constraint and receive full pledged amount, e.g., 50+50 Bitcoins?  
> **username_2**: You can create multiple transactions. If a funder is worried about not meeting a minimum, then they can wait until the first `SIGHASH_ANYONECANPAY` transaction confirms.  
> **username_0**: > multiple transactions? What do u mean? >  first SIGHASH_ANYONECANPAY transaction confirms? SIGHASH_ANYONECANPAY inputs are merged into a final transaction after minimum is reached and broadcast. What do u mean first tx confirms? There is only 1 tx.  
> **username_2**: After the minimum is reached, the transaction is broadcast, mined, and confirmed. Now investors can verify that the minimum was met. There is no need to add surplus to the same transaction, so why not allow investors to just send additional transactions after the first tx is confirmed?  
> **username_0**: How would it work if 1st pledge is 50 Bitcoins and 2nd is also 50 while the minimum is 60?  
> **username_2**: You can warn users if their pledge goes over before they commit. That way, they can create a separate normal transaction for the excess after it's broadcasted.  

---

