Thoughts on the SIGHASH_ANYONECANPAY protocol and a proposed alternative BIP70 protocol

[aspe...@gmail.com]

I'm not sure I see the point of making lighthouse "trustless" using smart contracts. Here's why:

1. Pledgers can retract their pledges by spending their inputs before the pledges are claimed
2. Project owners can claim partially-completed projects by filling the remainder of their transaction with their own funds (or borrow some from a lending club if they need to)
3. Even when completed normally, project owners can ultimately just do whatever they want with the outputs once the campaign is completed

It seems to me if you want to contribute money towards a project, you must completely trust the project owner straight away. Someone who feels fine about keeping your money for a purpose not related to their campaign isn't going to turn into a saint because they have the exact amount they need for their project.

With that in mind here's what I suggest towards project crowdfunding with Bitcoin:

1. Pledges are simply Bitcoin transactions. They can be sent off-chain and bundled or just published as normal. This prevents double spending either on accident or on purpose.
2. Pledges include a change address refund_to
3. ^ BIP 70 can handle the above two cases (especially: "If the sum of outputs.amount is zero, the customer will be asked how much to pay" -- BIP70)

If the campaign is a success:

1. The funds were collected during campaigning
2. Partial refunds are now possible (for my crowdfunding project this was important since I didn't know exactly how much I needed and wanted to be able to return extras) 
3. The campaign can continue accepting contributions (Kickstarter allows this and it helps many projects) or reject BIP70 requests to prevent this if they want.

If the campaign is a failure (either manually because of not enough interest or a deadline is reached):

1. The owner can refund all contributions publicly with one or more transactions

---

If you want to limit trust, you can use a intermediary (Kickstarter, essentially) to automatically refund failing campaigns, dox project owners in the case of misuse, or take charge of pushing legal action against any rouge project owners. But ultimately, in general, contributors need to trust the project owners and there's no real way around this.

I think Bitcoin is cool that you can start a Kickstarter-like service anywhere in any country and accept money over the internet without having to go through Visa/Mastercard and risking censorship. I'm not convinced that the current model removes any sort of trust and the current implementation, while not complex, does seem to have some important limitations:

1. Can't "refund" with any sort of automated confirmation back to the pledgers
2. Campaigns can't "expire" or be "cancelled" (in my model BIP70 could be set up to reject payments if the campaign was cancelled)
3. Required limits on amount and number of contributors
1. Crowdfunding seems to have a sort of log graph where plenty of people like to donate small amounts and a few people like donating large amounts -- 
2. People are very specific on the amount they want to contribute. If they can't, they won't
3. Larger projects are hurt the most by the large caps ($10,000 caps people at $20 (based on Hive Wallet Lighthouse data), so anything over that cuts off the most popular crowdfunding amounts)
4. https://prohatch.com/uploads/blog/tier_blog.png
   

My model:

1. Supports timeouts and canceling projects
2. Prevents double spending
3. Supports partial refunds
4. Supports any number of contributors
5. Has no minimum amount requirement
6. Allows contributions past campaign goal
7. Enables donations to be made from any BIP70 wallet

---

One possible modification to my approach that might be worth exploring is using a static output (i.e. using one donation address) for all contributors. This has the advantage that the amount contributed total is public, but the possible downside is there in regards to privacy.

I would suggest that if a contributor wants to disguise their sending address, it should be up to them to tumble it beforehand. At least with the BIP70 approach using mixed addresses is possible where in the current model it is not.

[Mike Hearn]

This conversation moved here:

https://github.com/vinumeris/lighthouse/issues/196