How to let surplus go to fundraiser in ANYONECANPAY crowdfunding script? ANYONECANPAY can be used for crowdfunding, 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.
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


The participant generates a secret, called it payment_secret, and hash it to produce payment_hash(for instance, using RIPEMD160).
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 &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


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

Stage Two - the fundraiser collects/returns the money


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 &lt;fundraiser_sig&gt; &lt;payment_secret&gt; 1 to unlock them.
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 &lt;participant_sig&gt; 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.