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?


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.

2 Answers 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,


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,

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

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.

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.

  • 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? Commented Sep 5, 2018 at 7:14
  • What do you mean "get around this"?
    – JBaczuk
    Commented Sep 5, 2018 at 11:58
  • Getting around this constraint and receive full pledged amount, e.g., 50+50 Bitcoins? Commented Sep 5, 2018 at 20:23
  • 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
    Commented Sep 5, 2018 at 20:43
  • > 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. Commented Sep 10, 2018 at 20:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.