Lighthouse

Summary

Lighthouse was a desktop, peer-to-peer crowdfunding application built by longtime Bitcoin Core developer Mike Hearn, unveiled at the Bitcoin 2014 conference in Amsterdam and publicly released on January 20, 2015. Rather than routing pledges through a centralized platform like Kickstarter (which takes a cut and can unilaterally cancel campaigns), Lighthouse implemented "assurance contracts" — an economic mechanism where a project only gets funded, and pledgers only pay, if a target amount is collectively committed. It used raw Bitcoin transaction and script features (partial, unbroadcast transactions combined via SIGHASH_ANYONECANPAY) so that no escrow agent, smart-contract platform, or trusted third party was needed: the incomplete transaction itself was cryptographically meaningless — and therefore un-spendable — until enough pledges combined to reach the goal.

Design (Mechanism)

The assurance contract concept predates Bitcoin (it traces to economist Alex Tabarrok's work on funding public goods), but Hearn's insight was that Bitcoin's scripting system could implement it without a central collector. A project creator published a campaign file describing the funding goal and destination. Backers "pledged" by constructing a partially-signed Bitcoin transaction that sent their contribution to the project — but signed it with SIGHASH_ANYONECANPAY, a signature flag that commits only the pledger's own input while leaving the transaction open for other inputs to be appended by anyone. Each backer's pledge was a valid signature over their own coins only in the context of a transaction that also included every other backer's inputs and paid the total to the project owner.

Individually, a pledge transaction could not be broadcast or claimed — it was underfunded and thus invalid until it accumulated enough inputs to reach the target amount. Pledge files could be exchanged directly between users' computers (over email, USB stick, or a simple file-hosting server) with no blockchain interaction required until the goal was met. Once enough pledges were collected, anyone (typically the project creator) could combine them into one fully-signed transaction and broadcast it, atomically paying every pledged amount to the project. If the goal was never reached, no valid transaction ever existed, so backers' coins simply remained theirs — no refund logic, escrow, or dispute process needed. Lighthouse also supported a "serverless mode" (pledges shared as files with no infrastructure at all) and a lighter "server-assisted" mode where a public host aggregated and displayed campaigns, run by Hearn's company Vinumeris and by OneTap Software at launch.

Outcome

Lighthouse shipped as a working, open-source (LGPL) Java desktop app (github.com/vinumeris/lighthouse) built on Hearn's own bitcoinj library, and launched with a real campaign ("Mobile Medic," raising BTC for healthcare workers in developing countries) plus two independently operated public servers. Development was substantially funded by a community bounty (reported around $60,000) rather than venture capital. The mechanism worked as designed and demonstrated that non-custodial, script-level crowdfunding was technically achievable on Bitcoin without any additional consensus changes. However, the project never reached meaningful adoption beyond demos and a handful of test campaigns. In January 2016, Hearn publicly exited the Bitcoin community entirely (in his post "The resolution of the Bitcoin experiment," amid the block-size scaling dispute), sold his bitcoin holdings, and joined enterprise blockchain firm R3. With its sole maintainer gone, Lighthouse was left without active development; a community effort later ported the code to Bitcoin Cash ("bitcoinj-cash/lighthouse") and an unofficial "Lighthouse.cash" revival surfaced afterward, but the original project itself is dormant.

Why it worked

• The core cryptographic mechanism was genuinely trustless: because SIGHASH_ANYONECANPAY made an under-funded pledge transaction invalid and unspendable, there was no way for a project owner or intermediary to claim partial funds or run off with pledges before the goal was hit — the "escrow" was pure math, not a promise.
• It required zero protocol changes to Bitcoin, proving assurance contracts could be built entirely with then-existing (2014-era) Bitcoin script features.
• The serverless mode removed platform risk (no company that could freeze a campaign, take a cut, or be shut down) and let campaigns exist as portable files.

Why it failed or underperformed

• Bus-factor of one: the project was tightly coupled to Mike Hearn personally, and his abrupt, high-profile departure from Bitcoin in January 2016 removed both the maintainer and the public advocate for the tool, and development stalled.
• Poor UX relative to incumbents: pledgers had to run a desktop wallet app and manage raw pledge files/keys, versus a one-click web checkout on Kickstarter or Indiegogo — a large usability gap for mainstream fundraisers and backers.
• No refund flexibility or partial-success mechanics: because funds simply never move if the goal isn't hit, Lighthouse couldn't support common crowdfunding patterns like stretch goals, tiered rewards, or graceful partial funding, limiting its fit for real campaigns.
• Small addressable market at the time: Bitcoin holders willing to use a niche desktop tool for donations were a tiny overlap with people running or backing crowdfunding campaigns in 2015.

Lessons

• A cryptographically elegant trustless mechanism does not guarantee adoption if the UX cost of participating (installing a wallet app, managing pledge files) is much higher than the centralized alternative it's replacing.
• Assurance contracts are a genuinely reusable primitive — later generalized and popularized on smart-contract chains (Kickstarter-style crowdfunding contracts on Ethereum, quadratic-funding designs like Gitcoin Grants) once expressive on-chain contracts made the "refund unless goal is met" logic easier to build and present to users.
• Single-maintainer infrastructure projects are fragile: even a technically complete, working system can go dormant overnight if it depends on one person's continued involvement, independent of the mechanism's soundness.
• Building on existing script primitives (rather than requesting a protocol change) let Lighthouse ship quickly, but also meant it inherited all of Bitcoin's UX limitations of the era, with no separate community pushing the feature forward once its creator left.

Redesign (EDITORIAL)

EDITORIAL — hypothesis, not fact. A modern version of Lighthouse could keep the trustless assurance-contract core but move the aggregation step on-chain via a minimal smart contract (on Bitcoin via a covenant/Taproot-based construction, or on an EVM chain) so that pledges are custodied in a transparent, auditable contract rather than exchanged as ad hoc files — removing the need for a "server-assisted" mode entirely while adding a standard web wallet-connect flow for backers. Layering in optional partial-success thresholds (e.g., "80% of goal releases 80% of funds, pro-rata refund otherwise") and stretch-goal tranches would address the biggest functional gap versus Kickstarter-style platforms. Finally, structuring it as a public good maintained by a foundation or DAO rather than one developer's side project would address the bus-factor failure that ultimately killed the original.