中文

English

Español

Português

There are some big questions in the air right now in the Bitcoin Cash space. One of them is about voluntary funding of the Bitcoin Cash commons.

Can it work at the large scale we need?

Can it be reliable enough to make long term plans based on it?

Is it possible to have meaningful accountability with a distributed group of supporters?

A group of volunteers came together to create Flipstarter and move us one step closer to "yes" on all of those questions. We plan to test and then release everything described below in the next few weeks.

We have partnered with EatBCH and will publish a small scale proposal with them. You will see the proposal with:

Their method of accountability

How much they need

Then you can decide for yourself whether you want to support it. The key difference from typical donations here is that you will experience a trustless and non-custodial assurance contract. Borrowing from wikipedia:

An assurance contract [...] is a game theoretic mechanism and a financial technology that facilitates the voluntary creation of public goods and club goods in the face of collective action problems such as the free rider problem. In a binding way, members of a group pledge to contribute to action A if a total contribution level is reached [ ...]. If the threshold level is met (perhaps by a certain expiration date), the action is taken and the public good is provided; otherwise, the parties are not bound to carry through the action and any monetary contributions are refunded.

Bitcoin Cash has several ways to achieve an assurance contract and we will cover them below.

As part of an overall effort to increase communication between mostly isolated communities, everything in the project will be published in at least English and Chinese. If you would like to contribute high quality technical translations in languages other than English or Chinese, please contact us.

Some people may remember Lighthouse. This first step of Flipstarter is basically Lighthouse but boiled down to the main feature. That is an old feature of Bitcoin transactions called "AnyoneCanPay".

The idea is that in a standard transaction, you sign it to approve:

All outputs

All inputs

With AnyoneCanPay, you sign a partial transaction to approve:

All outputs

Only your inputs

In other words, as long as everyone agrees on the total output, anyone can help pay, and everything happens trustlessly.

The current state of wallets is that they support mostly standard transactions as described above. The AnyoneCanPay setup is not supported in any major wallet. The Lighthouse client above used to handle it but it had its own issues and got engulfed by the growing block size debate at the time.

Therefore we need to create a way for people to participate in assurance contracts. We considered many options that are described later, and for the first version we chose to use a plugin for Electron Cash. The experience will be something like this:

Install a plugin for Electron Cash. See a proposal on the Flipstarter site and set your pledge value. Get a piece of text from the site and paste it into the Electron Cash plugin. The text contains the information needed to create your pledge. The plugin gives a result for you to paste back into the site. It contains your pledge as a signed, partial transaction. Note that when the plugin creates a coin for your pledge, it is frozen so you will not accidentally spend it. You can manually un-freeze it at any time. The site collects and monitors pledges until it has enough to build the complete transaction. The site finalizes the assurance contract, and pays out to the target addresses. If the campaign does not get enough pledges, then everyone can un-freeze their pledge and use it as normal. That is, the coin never leaves Electron Cash until the whole campaign succeeds.

It looks a bit clunky, but the process is more secure, non-custodial, does not require the user to take their coins out of Electron Cash and it lets us get something working with limited time and resources.

Other options we considered:

Users pay to a QR code generated by a temporary web page that knows how to create an AnyoneCanPay pledge. Pro : Easy UX with standard wallets. Con : Real risk of losing funds if the script has errors, or the user makes a mistake.

Use a smart contract where donations are made in a linked series of contracts (design by @TobiasRuck). Pro : Easy UX with standard wallets. Con : Complexity would delay release of first campaign, and users would have to wait in line for the previous pledges to complete before they can make their own.

Use a smart contract where donations are made in a distributed tree of contracts (design in progress by emergent_reasons#100🌵). Pro : Easy UX with standard wallets. Con : Complexity would delay release of first campaign.



If you know a trustless, non-custodial solution that has a better UX than above, please contact us.

There is a long list of things that can improve after we complete the initial goals. Volunteers will continue to develop it, and there is opportunity for a for-profit team to develop it into a full fledged platform. Whatever happens, we are making the first version so that anyone can fork it and run a campaign by themselves.

Soon we will run some private tests before the real EatBCH campaign. If you want to participate, please contact us.

We have the talent to finish our to-do list but there is a mostly unlimited number of things to do after the first version if you are willing to take ownership and present a good plan.

The current repositories are in the gitlab flipstarter group. Some are still not visible while code is being cleaned up.

Big thank you to the group of volunteers making Flipstarter happen. Special thanks to the heavy lifters:

@Dagur (Electron Cash plugin)

Jonathan#100☯ (Frontend, backend design and implementation in nodejs)

@Leandro_DiMarco (Logo, designs, diagrams)

@Sploit (Backend implementation in golang)

Any read.cash tips will be sent to the Flipstarter donations multisig address. It is co-signed by emergent_reasons and im_uname.

telegram @emergentreasons

keybase @emergent_reasons