Proposal for full bitcoin integration

[reedlaw]

While #14 addresses bitcoin pay-in and #310 pay-out using external services, this proposal is for supporting bitcoin directly as an alternative payment vehicle.

Workflow

• A participant who wants to give bitcoin is presented with a custom Gittip funding address.
• Once this address is funded, the giver can start distributing it.
• Profiles with bitcoin enabled (i.e. with a bitcoin address) are eligible to receive bitcoin tips.
• Recurring payments will happen automatically until the giver's funds run low.
• Recipients are paid directly into their bitcoin wallet.
• Email notification are sent reminding givers to replenish their funds.

Implementation

• A long passphrase is used to generate an offline wallet, or "brainwallet".
• The passphrase-generated deterministic wallet is never stored on disk. By deterministic wallet I mean given a passphrase x and a procedure f, f(x) always generates the same wallet.
• The passphrase is never stored on disk but only as an environment variable on the Gittip server.
• The passphrase is converted to a private key which is used in memory for signing all bitcoin transactions.
• When a participant requests a bitcoin funding address, a new bitcoin address is generated based on the passphrase plus a unique identifier. The way bitcoin addresses work is they are a key pair stored in a wallet file for each receiving address. This proposal uses offline wallets so it doesn't support storing multiple key pairs in a single wallet file. Instead, we can create a new key pair based on the passphrase + id of each participant.
• When it comes time to send out weekly payments, private keys are regenerated in memory based on the passphrase and ids. These keys are then used to sign transactions sending funds to recipients' addresses. They way bitcoin works is that transactions are stored in a chain of blocks representing every transaction from the beginning, including those that generate new bitcoins. These transactions must be signed cryptographically. Transaction history determines the current amount of bitcoins associated with each bitcoin address. In order to transfer bitcoins from one account to another, someone has to have the private key associated with the sending address. The private key signs a transaction in much the same way you would sign a check. A transaction signing is an event that is published immediately on the bitcoin network and rapidly confirmed by thousands of other nodes until it becomes a permenant record in the block chain. Thus bitcoin transactions are irreversible once signed. That's what makes the next section so important.
• Much of the bitcoin-related code has already been implemented and well documented elsewhere in multiple languages. Thus it would be a matter of integration.

Security

• At first when the amount in the funding account is small, it should be sufficient to store the passphrase as an environment variable on the server. An attacker would have to have access to either the working memory on the server or its environment variables in order to compromise this system.
• A better solution would be not to store the passphrase anywhere, but instead use some form of secret sharing such as Shamir's or implement multi-signature transactions like in the Armory client. This would mean that an attacker could not compromise the system with only a single secret, but it would be much harder to implement.

[colindean]

This is very well though-out and I appreciate the time and attention to detail. This is definitely a significant push in the right direction.

However, I'm against any implementation that necessitates Gittip itself being responsible for the security of bitcoin balances via control of a single private key or set thereof. If this description were to be implemented, the suggestion for secret sharing would be mandatory.

I'm still not sold on that, though, because I feel that Gittip should not at all be responsible for this duty. Rather, it's better off in the hands of an external service that can focus on the security and transfer mechanics while exposing a useful API to Gittip and other services.

[reedlaw]

I agree that managing a passphrase is not ideal. But if Gittip relied on an external service, the API key could grant similar access to Gittip's account and would have to be guarded with the same caution. See the security notes at the bottom of this page.

Also, any service that offers recurring bitcoin payments would require givers to make an account on that service and fund it. This is how Coinbase works. I don't think requiring a Coinbase account to use Gittip goes along well with the decentralized nature of bitcoin.

We could use bitcoin's upcoming payment protocol to send payment request links to givers on a regular basis. It requires a lot more manual intervention on the part of givers which could lead to a decline in giving.

I think that with Gittip being an open company, keeping secure secrets presents an interesting challenge which at some point I hope is achievable. Perhaps a simple solution is to choose a single trusted person as an escrow holder who receives all the payments and sends out the weekly payments. This person could earn a fee for the service and taking on the risk and thus be responsible for all the needed security measures.

[reedlaw]

Alternative Implementation

Multi-signature transactions could provide what we're looking for. A multi-signature transaction could be signed first by the giver and later by Gittip when it's time to send the weekly pay-out. The bitcoin funds would not be stored in Gittip's wallet so this method would be more secure. A compromise of Gittip's signing key would only result in the ability for an attacker to sign the transaction earlier than the pay-out date.

The only disadvantage to this method is that the giver has to pre-sign an arbitrary number of transactions. If someone wants to give $5 a week for one year, that means they have to sign 52 transactions upfront. Gittip will later have to sign these transactions as well, once a week for 52 weeks. Gittip's signing could be automated but there's no easy way for a giver to automate the pre-signing of 52 transactions. Also, the giving will stop after 1 year, whereas with credit card-based recurring payment processors there is no need to stop unless explicitly cancelled. Maybe with these drawbacks in mind it would be better to do monthly bitcoin payments rather than weekly.

[rummik]

I hate to say it, but I think this will get a -1 from me: I used to really want full Bitcoin integration, but it seems to me more like it would add confusion if we handled multiple currencies internally. I think people should be able to fund their account by converting from BTC (and others) to USD, and that payouts should work about the same (from USD to BTC/etc). It makes things way less confusing in the long run, since we wouldn't have to list how much someone receives in every single currency they receive.

[zwn]

I am also thinking that what we need now is make gittip simpler, more approachable for both - developers and users. When we are rock solid in what we have, we can think about more features. We have a lots of code already and not that many people familiar with it. That's is also why I think it is worthwhile to focus on infrastructure now (#1474).

[reedlaw]

@rummik the distinction I see between "bitcoin integration" and "handle multiple currencies" is that bitcoin is a digital currency without borders, that is, a universal currency. It can be sent and received as readily as git pull requests, so anyone who can contribute to free software should also have the necessary equipment to use it (i.e. computing device with Internet connection). Supporting bitcoin would make supporting other currencies redundant or at least less urgent.

[mvdkleijn]

@reedlaw That's some assumptions you're making there. Most people in my area have heard of BitCoin but few want to touch it. I'm in the EU by the way. People outside of the US and EU, especially in poorer countries, would probably have a painful time converting BitCoins into local currency to help pay for costs.

BitCoin is far from ubiquitous. You're also assuming that contributors are developers... they might just be a writer who helps out writing a marketing piece or some docs.

[rummik]

@reedlaw In my experience, it's a trick to buy things with it. About the only thing I've spent any BTC on directly was a few Humble Bundles. While I agree that it's easy to move them around, my point was more that we'd have to say how much someone receives in BTC too, not just USD, which adds a layer of confusion. I'd rather have an option to convert their USD to BTC on payday, and have people fund their accounts with BTC. It makes it way less confusing internally and to newcomers

[passcod]

@rummik's right on the multiple-currencies front: there should only be one internal currency, conversion into other currencies should be done at payout (gittip can still do it on their end, but it should only be handled at that moment, not before). Now, whether that currency is USD or BTC is another question…

Now, those concerns about people wanting to use bitcoins or the difficulties of spending bitcoins are misplaced. Bitcoin payouts will probably always be an option, not the only way, so bitcoins will be payed out or deposited by people who know what they're doing and want to do it. The rest will use USD or wait for international payouts.

[reedlaw]

@passcod, conversion to and from USD is going to add up in fees. If givers want to give bitcoin to someone who wants to receive bitcoin wouldn't it be better to handle that directly? A lot of the concerns here are related to handling multiple currencies in general, which is an important consideration, but I believe bitcoin is a special case because it already has online exchanges in many countries that support local payout methods. For instance, in China you can convert bitcoins to RMB and withdraw into an Alipay account, which is more popular there than PayPal. If Gittip wanted to support RMB withdrawals it would have to integrate with Alipay or some other third-party service. Multiply that effort by all the countries' currencies that Gittip someday may want to support. On the other hand, if we just add bitcoin, it's not too hard for users to set up one of their local options for bitcoin to local currency conversion.

[passcod]

@reedlaw Hmm, right, yes, I hadn't considered the cost of converting to and fro. However, are we going to do this for every currency ? Consider Alicia, from Italy, funding her account in EUR, and Barnabé, from France, receiving some of her money, wouldn't it be better to handle that directly?

[reedlaw]

@passcod, yes it would make sense not to convert X -> USD -> X. But to support additional currencies for both pay-in and pay-out requires integration of external services, except bitcoin which can be handled server-side or even in javascript (see this page for example). That's not to say bitcoin integration is without difficulty, but it seems much easier than traditional currencies and has the advantage of having many online exchanges in various countries that each support local payment options.

[patcon]

-1 from me for self-hosting BTC infra. +1 for using something like blockchain.info like reddit btctipbot does:
https://github.com/NerdfighterSean/bitcointip/blob/master/src/bitcointip.py

[ELLIOTTCABLE]

My 48.78µɃ (that's $US 2¢ in BTC, at the moment), as a hard-core philosophical Gittip believer and supporter:

• Anybody living in the real world, even a Bitcoin ‘believer’ such as myself, knows Bitcoin is buttfuck-useless right now. Seriously. None of us (or at least, none of us with operating grey-matter) thinks Gittip should shoot itself in the foot by supporting only bitcoin, or, more relevantly, by making Gittip harder to use (in any way!) for the Bitcoin-ignorant or the Bitcoin-deriders.
• It thus follows that any implementation of Bitcoin support, whatever the reason (catching the hype involved in anything cutting-edge … it being aligned in-spirit with Gittip itself … a one-size-fits-all solution for currencies foreign to the USD …), must not affect the interaction-flow for someone who doesn't utilize that implementation.

So, taken together, I think it's absolutely clear that Gittip should not display some sort of separate, secondary “Bitcoin contribution” on everybody's pages. This will confuse non-Bitcoin users, which should be anathema to a growing service like Gittip. Instead, I think only one value should be displayed on a Gittip page: at least for the moment, their total received tips' value in USD.

Now, that said … that doesn't necessarily mean that those tips all need to be received, sent, or (and this is the kicker) processed in USD. There's no reason we can't take a Bitcoin payment from a Bitcoin user, store it in Bitcoin (or store half-signed transactions, as described above … or store it on an external service … or any number of other things mentioned above), and then pay it out in Bitcoin to another Bitcoin-enabled user, all without needlessly wasting their tip-money on exchange fees. I'm entirely for that. I just think it should be transparent.

So, my suggestions, all that considered:

Display all values, converted internally with a reasonable, as-real-time-as-possible, spot conversion rate, in USD. Hilight, subtly, (either in color, or with a subscript, or a symbol somewhere nearby, or …) values that have rolled-in Bitcoin-tipping (as I think it's important for users to be able to see, at a glance, whether a tip-value depends on the more variable Bitcoin market, or not). Obviously, allow for it to be explained more explicitly, and broken down into Bitcoin-tips and USD-tips, with a click or hover. (Whatever we can agree is less intrusive and confusing.)

On receiving users' settings-page, in the same vicinity as the settings for bank-account information, provide a warning until they also add a Bitcoin pay-out address: inform them that they will A) lose a percentage of any incoming Bitcoin tips to conversion fees, and B) that all incoming Bitcoin tips will be delayed, and only paid out on the first pay-out of every month, to reduce those same fees … until/unless they're willing to set up a separate Bitcoin wallet, and deal with that aspect themselves. Ensure the warning is worded in a way that isn't too abusive or derisive of the user who doesn't care about Bitcoin. (Obviously, also provide immediate links to relevant tutorials on how to securely set up a wallet, or provide our own such tutorial.)

For contributing users', when visiting a user's profile or viewing their list of contributions or anything similar, a toggle will be provided to select whether to pay a particular tip in Bitcoin or USD, as long as they have both Bitcoin and USD payment-methods configured in their own settings. The toggle will default to Bitcoin, if the receiver has a Bitcoin pay-out address configured (and, obviously, if the payer has a Bitcoin payment method configured.) If the giver toggles to Bitcoin when the receiving-user doesn't have a pay-out address, then a similar warning to the one mentioned above will appear, informing the giver that some of their tip will be lost to transaction-fees, if they choose to donate in Bitcoin to this non-Bitcoin-receiving user.

All this means that $US transactions, and BTC transactions, can happen their separate ways, without incurring transaction fees at every turn … if the users can be convinced to care about Bitcoin.

That covers $US → $US, BTC → $US, and BTC → BTC. I believe, personally, those three to be the most crucial situations to this topic. I also believe that, for the moment, we explicitly should not handle $US-giver → BTC-receiver automatically, yet. The majority of receivers will have $US-compatible bank accounts, as they do now. It's a slightly more complex topic, one not as easily handled as the above (for instance, I'd rather not confuse non-Bitcoin-cognizant, $US-giving newbies, with warnings, every time they try to tip a Bitcoin-only receiver … but I also want to make sure we never assess fees, without both sides being aware that they're wasting money on those fees.)

(For that minority of situations where a tip-receiver needs to be Bitcoin-only (for instance, somebody having reason to take advantage of the anonymity of Bitcoin, perhaps an anonymous journalist wishing to solicit Gittips) … I suggest, for the moment, an arrangement involving manual conversion of all owed $US tips, and manual pay-outs of Bitcoin thereafter, i.e., what's already necessary right now.)

---

(Side-note: as mentioned above, I'm a Bitcoin believer. I'd love to see greater adoption of Bitcoin. In these comments, though, I probably sound to be the opposite: the way I see it, Gittip isn't a big enough player to do much to drive the adoption of Bitcoin … and I'm also a big Gittip believer, who thinks the anti-Bitcoin sentiment out there is enough to damage Gittip. And I'd hate to see that.)

[ELLIOTTCABLE]

So, that comment above, all pertains to my reasoning, and the UX we expose. Some more (YES I KNOW I'M VERBOSE, I'M SORRY GUYS I JUST CARE A LOT) commentary on the how:

Bitcoin security is a Motherfucking Minefield for small ventures like Gittip. I mean, we've all (that is, those of us following Bitcoin for any length of time) see various websites and services get bitten, hard, by having somebody steal all of their bitcoin, or something. I'd really love to see this thought through well ahead-of-time by all of us involved, and avoid that P.R. mess for Gittip.

As mentioned either above or elsewhere (I forget), relying on external services really isn't a solution, at least from a security perspective. The API keys, or whatever-else, would have to be just as secured as the private-keys hosted locally; and to boot, that adds another vector of attack, one that we don't control. So, again solely from a security perspective, 👎 to external hosting. (Mind you, there's other possible benefits there that might outweigh this concern: ease-of-implementation, or stability, for instance.)

As for self-hosting … well, the considerations here are well-known, at least to an extent. A lot of it can be boiled down to: “No respectable quantity of Bitcoin should be held in an online wallet for any length of time, if at all avoidable.” The ideas posted in the original issue here don't really address this at all, and I consider them wildly insecure (speaking as a long-time Bitcoin-security aficionado.) Instead, I'd like to see a proposal working out two separate problems:

• First off, programmatically negotiating payments without escrowing the money. Whether we propose some new protocol for recurring Bitcoin payments and back it (my personal horse, because this is a problem that Needs Solved™ anyway), or e-mail PaymentRequest or [temporarily] BitPay links, or something else entirely … the money should ideally only leave the givers' wallet immediately before it gets paid-out. Within twenty-four hours before the weekly USD payouts-time, I'd say, because it's nice to have everything in-sync. Then our system doesn't have to store money for those payments, it only has to route it. Much easier to secure.
• Second, for situations where that is unreasonable, if we have to escrow Bitcoin, we need to figure out a methodology to do so that A) is entirely offline for the entire storage period, B) only ‘comes online’ (manually) at payout-time, and C) doesn't depend on any single person. I'll elaborate (OMG I'M SO SORRY) below:

Escrowing Bitcoin

First and foremost, let's keep the money in offline wallets. This can not (and should not) be safely automated. Whichever people we entrust with the handling of this, should be expected to monthly, immediately-before-USD-payout (let's make Bitcoin-payout-time “the 24 hour period before the moment of USD payout.”), and following best-practices for an offline wallet, generate a single transaction from their individual offline-wallet on a cold-system, transferring exactly as much Bitcoin as is needed to fulfill Bitcoin-specific payouts (as described in my previous comment, above) to an online-address controlled by the codebase.

Those online-address will be watched by the system in that 24-hour period, and whenever the manually-generated transaction comes through, it will immediately and automatically be distributed back out again to all of the receiving addresses that are owed Bitcoin. At no point will the codebase hold any quantity of Bitcoin; any attacker would have to either A) continuously and unobservably subvert the codebase itself, or B) react in a very small time-window between the aggregated pay-out-portion being received, and it being subsequently processed … to successfully steal any of that week's payout.

Second: the total of any amount of Bitcoin we find ourselves needing to escrow, should be distributed amongst multiple ‘reliable persons,’ (get to that in a second) each with their own offline-wallet, for which they are individually responsible. Whoever is chosen, we should go over best-practices in detail; they'll be handling (possibly quite a lot) of Somebody Else's Money™. Then, any Bitcoin necessary for the pay-outs described above will be split amongst the funds known to exist in the various escrows, and each escrow will be given their periodic instructions with whatever amount of the total portion is necessary to bring out of cold-storage.

Finally, as to the people entrusted to escrow Bitcoin funds: well, that's more of a social issue, and not one I'm as qualified to comment on, as I am the other security issues at hand … but perhaps we could use Gittip itself, as a source? Isn't Gittip, at its core, a way for the community to vote their trust in a person? “We trust this person to use this money well, to continue to help us in the ways they have helped us in the past.” To boot, any person receiving a substantial amount of money on Gittip likely has some sort of loyalty to the platform: after all, it's allowed them to pay their rent. So, what about some combination of “being one of the top receivers on Gittip,” and “having contributed a substantial pull-request to the Gittip codebase” could be used to filter for the more elusive “cares about Gittip enough to be entrusted not to steal everyone's money?” But that's just a random suggestion.

Postscript: Yes, this sounds paranoid. In my opinion, Gittip is important; and Bitcoin is irredeemable once lost. You should all be paranoid, too, at least for this discussion.

[patcon]

First off, thanks @ELLIOTTCABLE. It's really tough to comment on this all at once, because I believe large parts of it are built upon base assumptions that I think we need to talk about first.

More generally, the whole first post made me realize that we need likely need a visual tool mockup tool to discuss UI changes. Not that it's your fault, but that whole first post seems like it could be summarized in a few nicely-annotated mockups, which would make that parts of the discussion much more accessible to those who can't spend as much time reconstructing its recommendations.

@whit537 Any objection to my reaching out to team @balsamiq about how we could collaborate over this stuff. Version-controlling some balsamiq mockup files would be awesome, if that made sense.

Related: http://support.balsamiq.com/customer/portal/articles/105924#oss

[patcon]

Secondly, @ELLIOTTCABLE, I'm still not convinced we must convert, among others things I'm unconvinced of. Yes, we should display tips in USD as much as possible, but is it not simplest to just use the blockchain API and create a wallet like reddit bitcointip bot does? Also, if I understand the law (and your proposal) correctly, hosting our own bitcoin wallet infra within a system that converts BTC→USD (and vice versa) while in any way circumventing know your customer (KYC) regulations, this breaks the law laid out for Money Services Businesses (MSBs), and this is not something we can do.

So in short, I'm personally not yet onboard that:

1. 3rd-parties are a bad idea,
2. that converting automatically to USD is the right approach, and
3. that your proposal is even legally feasible.

Would you mind addressing those points first?

If you feel another long post developing, perhaps we could discuss on IRC first, so as not to make this issue even more intimidating and inaccessible. (And again, I say that last bit without trying to trivialize the real time and thought you've already put into this.) My irc handle is either patcon or patcon_.

[ELLIOTTCABLE]

@patcon definitely. I'll try and hop online sometime in the next few days. Freenode, presumably? #Gittip? I'm in #ELLIOTTCABLE nearly 24/7. Hilight me. <3

[rohitpaulk]

We don't do bitcoin anymore, closing this.

[knocte]

You've lost some users then :) For anyone coming here and wondering about an alternative that does support bitcoin: bountysource's Salt.

[ELLIOTTCABLE]

@knocte thanks for the heads-up re: an alternative. /=

[mattbk]

For context, bitcoin was removed in order to meet anti-money-laundering regulations: gratipay/inside.gratipay.com#192 (comment)

See also: gratipay/inside.gratipay.com#192 (comment)

[chadwhitacre]

For context, bitcoin was removed in order to meet anti-money-laundering regulations

Yes. We dropped bitcoin in order to clearly meet the second of four parts to the definition of a payment processor (by which we are exempt from regulation as a money transmitter), namely, that we "operate through clearance and settlement systems that admit only BSA-regulated financial institutions". Here is a longer explanation.

[mattbk]

I wanted to make it clear due to this Twitter stream: https://twitter.com/passcod/status/652630603574067200.

[passcod]

Back-linked to this on the Twitter thread for accuracy :)

[mattbk]

Hey, thanks!