Thoughts on the Lighthouse protocol and proposed BIP70 alternative protocol #196
Comments
andychase
changed the title
|
Hey Andy, I think there's some confusion here about the threat model Lighthouse has. Trust isn't one dimensional. I may trust you to, for example, make a nice music album. But that doesn't mean I trust you to be a computer security expert who can handle digital cash. That's a different skillset and different set of possible mistakes. Lighthouse removes the need for the second kind of trust. Note that if you don't trust the project creator to actually deliver what they are promising to make then that's a different problem. In that case, what you want is a Lighthouse project that pays to a multisig address where the signers are judges who decide if the project is completed successfully or not. The maker can then borrow against the pledged money. Note that once the crowdfund completes, and the money moves to the escrow holders, the pledges can't be revoked anymore so the funds can be used as collateral. The "you can just get a loan and take the pledges" model assumes an untrustworthy project operator. Obviously, even if they complete a project themselves, they are still on the hook for delivering what they said they'd make. If you are concerned they might defraud you or prove terminally incompetent, then the solutions are multisig escrow, or ID verification+lawsuits, or just accepting the risk as Kickstarter backers do. With respect to features like timeouts, overcollection etc - they can be added as features on top of the existing Lighthouse model too. The app doesn't have them because it's the work of one man (me) who has many other features to think about, not because they're impossible. |
|
(This conversation has been edited to remove my comments in which I learn more about the Lighthouse models pros/cons. Archive here: https://archive.is/0QMZL) |
In your model the money is under the control of the project owner, even when the project is not completed. If you raise half the money and then get hacked and the funds are stolen, then what? |
|
No - all that would do is transfer the hackers money to the project owner. Think about it. |
|
Most pledge files are kept on Lighthouse servers, which are totally different computers to those running users wallets. But obviously if the hacker can get the private keys of the place you keep your crowdfunded money, it's game over with both your protocol and mine. The difference is, the Lighthouse protocol lets you specify the address as being e.g. a cold wallet. And you don't have to touch that cold wallet during the crowdfund, even if people decide they want their pledged money back. And because there's no confusion over ownership, you avoid tricky legal issues .... if you take deposits and refund them then you can actually end up being regulated like a bank, which in practice makes it impossible to do. It's just safer and clearer all round if money only ever has one owner in the base case. Anyway, all this stuff is already covered in the FAQ: |
|
First off I want to thank you for participating in this discussion. Truly my only intention here is to have a clear understanding of what Lighthouse is and what I can do to push Bitcoin crowdfunding along. Okay I think I'm starting to make headway here in understanding! I get now that you are saying that Lighthouse has a decisive advantage in the case that you are using a third-party entity to handle donations, and that those donations alone can't be used as an attack vector. I get it! BreakdownThat is a pretty cool advantage in my opinion. But my focus has been all along: How much is actually gained vs how much is actually lost with this approach vs BIP70? Okay to sum up this conversation I'd like to go through some of the features I'm talking about and lay down what would be needed to implement them in lighthouse. Lighthouse Advantages:
Lighthouse Disadvantages/TODO:
|
|
tldr;
LegalityYou brought up the legal nature of my protocol. I defer to this post on the mailing list: s7r writes --- Thu Aug 27 09:33:16 UTC 2015:
Instant RefundsTo replicate the functionality of a pledger being able to reverse their funds at any moment, I propose an implementation of a "pledge claim ticket" that is simply an off-chain transaction that is signed back to the pledgors Now: In practical terms, this could be a text file with the base64 encoding of the transaction that a pleger can download after they pledge. A website would be set up where this file could be drag-n-dropped in or copy/pasted to have it claimed/broadcasted. Later: Maybe Bitcoin clients should have a way of standard way accepting and broadcasting off-chain transactions? SecurityThis would require that the private key be available during the campaign for signing back each transaction, which, as you mentioned, isn't the most secure. I think there's ways to mitigate this like using a secure web wallet service for use in centralized mode (It's already centralized, so using a hardened service should be fine). X.509 Certificates and Campaign AuthorizationOne part of the Lighthouse model that worried me was that there is no authorization. Anyone can produce a campaign in decentralized mode and start collecting funds under a false premise. (This suggestion could be integrated in Lighthouse, the advantage here is that BIP-70 wallets support pledging with authorization and pledgers don't have to download Lighthouse. I'll spin the Lighthouse suggestion into a separate feature request.) My method allows use of a X.509 certificate to sign and authorize the campaign outputs. The easiest method for getting a certificate I believe would be to use a X.509 email certificate such as from https://www.comodo.com/home/email-security/free-email-certificate.php Pledgers would be able to see that email address when they initialize the pledge from their BIP-70 enabled wallet and know they are sending their money to someone authorized email. This is not a perfect security scheme (attackers could just use an email address that looks close, hack the email, or intercept the email), but I would suggest is more integrated and trustworthy then a non-certificate approach. Centralized mode benefitsIn the centralized mode, the central campaign server operator is expected to verify each campaign separately, where in my model the verification could be just based on the certificate and done automatically (either for email or website ssl certificates). Although server operators could set up their own email verification system, the advantage here is that you offload the trust to Comodo or some other and so you are trusting a verified third-party instead of the campaign server operator. Disadvantage: The CA model has flaws and is not seen as perfect. Perhaps something like namecoin or keybase.io is the future (last one wouldn't work in my model as they use pgp keys not x.509 which is needed in BIP-70). Trade-offsThere's a tradeoff here of simplicity and practically in my approach vs some minor security benefits in your approach, but believe we are on the same page there's no such thing as a "perfect solution":
I believe that my approach is simpler, easier to implement and maintain, and offers more immediate features for crowdfunding users and project owners. I believe my make-or-break feature is being able to pledge with any BIP-70 enabled wallet. OfferIf my implementation is a success and no major flaws are discovered, I'd love to work with you to implement this into the Lighthouse brand and push Bitcoin crowdfunding forward in a non-fragmented way. |
|
Re: using X.509 certs to digitally sign projects, good thinking. I fully agree, which is why I already thought of it and filed an item for doing so here in issue #54 last year. An implementation would be most welcome. Lighthouse projects are already (extended) BIP 70 protobufs so the same infrastructure can be reused. Re: legality. The issue is not the legality of Bitcoin but of running a service where you are taking and managing deposits of money that isn't yours. If someone has given you money on the understanding they can withdraw it at any point, then that money isn't legally yours, it's theirs, even if they have agreed that it may become yours if a goal is reached in future. Taking deposits has a long history of going wrong, which is why it's regulated. If you can't control the money that's been given to you as a pledge until the exact moment the goal is reached, there are no such issues. With respect to refunds:
This doesn't work: the project owner can invalidate the 'claim ticket' at any point by just spending the money you gave them back to themselves, thus rendering it largely pointless. This is why Lighthouse works the way it does. What's more, the moment you have such things, you're back to needing a specialised wallet to handle it all. Ordinary BIP70 supporting wallets won't know how to do any of this stuff. If they're going to be upgraded to support crowdfunding specifically, they can just as easily support the current Lighthouse protocol. So I still don't see what your proposal does better. Working through your list of disadvantages/todos: Lighthouse Disadvantages/TODO:
It requires changes to the Bitcoin protocol. After the block size hard fork, we'd need another one that improves the signature hash protocol. So yes, this is being worked on, but is ultimately dependent on the Bitcoin community working through its social issues around upgrades to the block chain.
A simple implementation is to upload your time locked refund transaction to a few different Lighthouse servers and have them broadcast when the time is right. This is much less than one year of work. Probably a few days of work at most, for someone familiar with the code. Perhaps a week or so otherwise. But bear in mind that the deadline feature in sites like Kickstarter is probably more about keeping their site clean of failed projects than being a fundamental component to a crowdfund. Lighthouse doesn't have that issue as it doesn't have a single website for every project. So I'm not sure why a project really needs a deadline: most of the time if you think it's a good idea, you'd still think it's a good idea in six months.
"All" software is overkill. Adding just a pledging client isn't that hard, especially for code based on bitcoinj, as the Lighthouse code can be reused. With some refactoring I'm sure we could do a demo of how to integrate it into MultiBit or Bitcoin Wallet for Android in way less than a year.
If by "many" you mean a handful of Bitcoin Core developers who can be relied on to make almost any change controversial then yes, but I couldn't care less about that. This isn't a problem that needs fixing. There are plenty of XT nodes these days.
A crowdfund with partial refunds is essentially a kind of loan, or a subset of a loan. You can talk to Mike from CoinShark about the work he's doing to add P2P lending support to Lighthouse.
Indeed, this is not hard. It is issue #63
Please see issue #85 |
Analysis of the Lighthouse model
In short, I don't see the point in trying to make crowdfunding "trustless" using smart contracts. Here's why:
It seems to me if you want to contribute money towards a project, you must completely trust the project owner straight away.
Suggested Alternative BIP-70 protocol
refund_to^ 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)
Campaign successful
1.The funds were collected during campaigning, nothing needs to be published
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
Campaign failure
(either manually because of not enough interest or a deadline is reached):
Limiting trust / Centralized mode
If you want to limit trust, you can use a intermediary (Kickstarter, essentially), to dox project owners or take charge of pushing legal action against the rouge project owner.
Lighthouse model limitations:
BIP-70 model advantages:
Should a static output be used?
In my model using mixed addresses is possible through BIP-70, but the addresses would likely be revealed when the campaign owner starts using the outputs.
The text was updated successfully, but these errors were encountered: