Implement Bitcoin payment

[tonylampada]

Bitcoin will be the next available payment method on FreedomSponsors. But we need to get a few details down first, regarding user experience. Here's what I can think of so far.

1) User should be able to select wich methods they work with (Paypal and/or BTC). This should be done from the "edit user profile" page. This info should be visible to others in [user profile / view issue / view offer] pages

2) BTC users will need a place to register BTC payment addresses, so they can receive money.

3) Offers would still be made in USD.

4) The payment page will alert the sponsor if there's any "receiving programmer" with incompatible/unsupported payment methods

5) When applicable, payment page will let the sponsor choose the payment method (Paypal or BTC).

6) If the user chooses to pay with BTC, FS will suggest a USD/BTC rate. But the user is able to edit paid values if desired.

7) To simplify the transaction to the sponsor, the BTC's will go through FS's wallet before hitting the programmers' wallet (otherwise, the sponsor would have to make 2 or more payments, in a non-transactional fashion)

[zooko]

Converting between BTC and USD can be problematic. The exchange rate between BTC and USD is constantly changing, and it can be expensive and time-consuming to convert money between them (in contrast to how cheap and fast it is to send BTC from one corner of the world to another). Also, a lot of users of freedomsponsors.org might not even have or want USD! (They might be using Chinese Yen or Russian Rubles or something instead.)

Hm, oh, but I see that it would be complicated to have two amounts in two different currencies listed for each bounty.

Okay, there are some fundamental questions here that I haven't thought through yet.

1. If I pledge a BTC bounty, then do I actually transfer the BTC from myself to freedomsponsors.org at that time, or do I keep it for now (in which case I might fail to actually pay up later, when the bounty is claimed)?
2. Does the recipient who earns the bounty get to choose to receive either USD or BTC, or they must take USD, or they must take BTC?
3. If they are going to receive USD, is the conversion from BTC to USD going to happen when I make the pledge or when they receive the bounty? This could result in different amounts of money if the exchange rate has changed in the interim.

You should think through these questions carefully. Not only do the answers have a big effect on the user experience, but they could have other effects. For example, if freedomsponsors.org is holding the pledged-but-not-yet-earned BTC, then it will become a target for BTC thieves.

It sounds like you'd like to treat Bitcoin as more of a payment mechanism than a currency here. That would simplify the user experience (everyone will always see a single number, expressed in USD), and would probably make your interface with BTC-world more like your current interface to Paypal. A good way to do that might be to hire a Bitcoin payment processor who will basically do all the work for you and just transfer USD to you at the end. I think "Mtgox" offers such a service:

https://mtgox.com/merchant

I have used Mtgox a little as a currency market, but never used their merchant services.

This one is one of the oldest services:

https://bitpay.com/

(Which in Bitcoin terms means it has been around for more than a whole year...)

And it has done a lot of business -- probably millions of USD worth -- and I haven't heard any complaints. Again, I haven't used it.

Here's another one, which I don't know anything about:

http://paysius.com/

So if you're going that route then you would keep all of the workflow and user interface like it currently is, just using bitpay.com or one of the others in place of paypal.com.

One complication to this route is that the value of a BTC-pledge in USD terms would fluctuate over time.

Oh, I get it, in this case you might ask the donors to specify their pledge in a USD-amount, even though they will use Bitcoin as the payment mechanism when the time comes to pay.

Okay, that sounds quite simple and sound.

The other approach is kind of cool, to me, because I'm an enthusiast about Bitcoin as a currency, but it would mean you'd have two numbers -- amount pledged in USD and amount pledged in BTC -- on the display.

Maybe you should try the more familiar approach first, and then consider using Bitcoin in new and interesting ways in the future.

[tonylampada]

It gets complicated fast doesn't it? :-) Thanks for the links. I'll look through each one of them with more detail.

[tonylampada]

@zooko Thanks for digging out all that info.

I got answers for 1 and 3: 1) I like the fact that FS is a "post-paid" service. That is, sponsors pay after they get what they need. That is by phylosophy. I want to encourage people to pay developers because they feel grateful for their work, not force them to it. Also, I would feel uneasy holding other's people money (in whatever currency) so I'll avoid doing that whenever possible.

3) The conversion thus must happen at payment time - or not at all (that will depend on the answer to 2)

I looked into mtgox and bitpay, and they have a similar approach for merchants: they receive from the customer in bitcoins and I can choose the currency in which I want to receive.

AFAIK, bitpay and mtgox are not able to forward part of that money to FS's receiving programmers (in bitcoins on otherwise). It would be awesome if they did.

I'll try to talk to them and ask if something like this will ever be supported. (Paypal does this through its "parallel payments" - which is what FS currently uses.)

But even if bitpay/mtgox won't support something like this, I can still enable bitcoin as a separate currency AND payment method. Offers could be placed in BTC or USD. BTC offers would be paid with bitpay or mtgox, USD offers would still be paid with paypal.

The receiving programmer would have to be able to take the money in the pledged currency. That's might be a little cumbersome to the programmer, but maybe it's good enough for now. So this is a "temporary" answer for 2. How does that sound?

Maybe when BTC gateways start to support different payment processes, things can get more interesting.

[tonylampada]

Just sent an email to info@bitpay.com relevant content below

(...) A payment on FS is made from a sponsor to one or more programmers. The sponsor decides how much will be paid to each programmer, and FS keeps 3% of it.

Currently, FS uses a Paypal feature called "Parallel Payments" - https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_api_APIntro Using this, none of the money ever has to go through FS's account - Paypal deliver to each receiver directly. FS is just another receiver. Personally, I don't like Paypal, but I do like this feature they have :-)

With bitcoins, my ideal world would be to have something similar using Bitpay. Sponsor would pay bitcoins to Bitpay, and Bitpay would distribute the coins among FS and the receiving programmers.

AFAIK, Bitpay does not support anything like this (payments with multiple receivers), right? Please correct me if I'm wrong. My question is, can this be supported in the future? Does this make sense to you?

Would be even better if multiple receiver "types" were supported - for example, for a single payment to 3 receivers:

• one would receive in bitcoins
• other would receive USD through direct deposit
• another would receive USD in her Paypal account

Can I have your thoughts on this? :-) (...)

[bitpay]

We don't have these features yet. We would like to add them, but it won't happen for a while (we have a lot of other higher priority things on our plate). We want to implement them by taking advantage of the Bitcoin protocol...which means that we could implement a lot of these kinds of features in such a way that you wouldn't even have to trust Bitpay to hold or distribute the funds...buyers would pay to special addresses whose corresponding script sets the payout constraints and the Bitcoin networks ensures that it is enforced.

What we've done with other crowd funding sites is that the person/company proposing the project puts in their BitPay account information. Once the project has met the funding goal, then it goes into a mode where the people that have pledged are asked to go ahead and make the payment. Then the Bitcoins are collected via BitPay and the project organizer receives the funds into their BitPay account (and can either be paid in BTC or USD or a handful of other currencies). Since the funding goal and the payouts can be done in any currency, you are able to do it in a way that the BTC exchange is basically a non issue.

We're big fans of crowd funding of open source software (in fact, if I wasn't developing bitpay, I'd most likely be working on a software crowd funding startup myself). However, I don't think the bounty approach works well (as a developer, I've never considered working for a bounty because the risk that someone else gets the bounty before I do is too great). Instead, I would suggest looking into dominance assurance contracts. In that model, someone arranges for specific people (could be themselves) to do the development work and markets the project to raise funds. They state up front that they need X amount of money to complete the project. If that amount is raised, then the project goes forward. In not, then it doesn't. But the developers doing the work will know that they'll get paid for doing that work...it won't be subject to the random chance that someone else beats them to the punch. People will pay a premium to people or teams that have a good track record of producing good software. And the teams will compete with each other to raise funds for their projects. I'm convinced this model is going to play an significant role in the software industry in the future (worrying about copyrights and licensing is simply too inefficient).

The Bitcoin protocol can support dominant assurance contracts (people can pledge money in a way that it can't be accessed unless/until sufficient funds have been raised...if sufficient funds are raised by a certain deadline, the recipient(s) receive it, if not, it reverts back to the contributors. It's all enforced by the Bitcoin network and does not require trust in any individual or company.

[zooko]

bitpay: who are you

Tony: like bitpay, I am very interested in "dominant assurance contracts". (Note: bitpay didn't describe the full details of "dominant assurance contracts" above. The system he described in that note sounds to me just like what sites such as Kickstarter currently do, and those are technically just "assurance contracts" and not "dominant assurance contracts". But nevermind about that for now!)

Like bitpay, I am also very interested in "smart contracts", in which the rules of who gets what money when get baked into a machine-readable contract, and then automatically enforced by the distributed, world-wide Bitcoin Transaction Processing Machine. That way, no company holds the money, and nobody can cheat, steal, or just screwup and cause the contract to not go off the way it was intended.

But, nevermind about that for now, too! Let's take things one step at a time.

My take on freedomsponsors.org is that you already have a live system which relies on Paypal, and the first step is to add Bitcoin as an alternative payment mechanism (but not really as an alternate currency, inasmuch as you can avoid it).

The next step after that could be, if you choose, to implement assurance contracts (Kickstarter style) or implement dominant assurance contracts (I'd be eager to talk about that if you're interested). In this approach, you'd still be using Paypal and some Bitcoin payment processor as two alternative payment systems, you'd still be mostly treating the currency as USD instead of BTC (I guess), and you wouldn't be doing any of the fancy science-fiction "smart contracts" stuff -- just running code on your server that decides who should get what money and then telling Paypal's server or the Bitcoin processor's server.

So anyway, it sounds like the very next step on this is contact other Bitcoin payment processors besides Bitpay and see if they can offer you the feature you want of sending some money to you and some money to the other user.

[zooko]

bitpay: excuse me I seem to have sent the comment incomplete or something. I meant to say: "Who are you? Perhaps you are Tony Gallipi, CEO of Bitpay?" https://bitpay.com/about-bitpay

[tonylampada]

Thanks @zooko ! I already sent similar emails to mtgox and paysius. Still waiting for their reply.

And I've opened #81 for the "dominant assurance contracts" discussion :-)

[zooko]

Tony Lampada: if no Bitcoin processor offers the feature that Paypal does, of sending some money one recipient and another amount of money to another recipient at once, you might find that it is easiest to implement that yourself. Bitcoin actually natively supports that a single transaction can pay different amounts to different recipients. You could look at these web sites that offer exploration and visualization of Bitcoin transactions:

https://blockchain.info/

http://blockexplorer.com/

For example, here is a transaction that I recently made. I forget what it was for -- I think it was a donation to a musician:

https://blockchain.info/address/14HRdapiCevEs155gGGb6iPdps4fx1XszL

http://blockexplorer.com/address/14HRdapiCevEs155gGGb6iPdps4fx1XszL

Oh, I see. I used a search engine to search for the recipient Bitcoin address and found what it was: I donated to the blogger who wrote the post that come up earlier in this conversation. :-)

Oh by the way, it looks like blockchain.info may provide some merchant services that you might be able to use.

But, I now think that the best next-step is for you to learn how to write code that directly uses Bitcoin. You could probably generate a button or hyperlink, or a couple of buttons or hyperlinks, which when clicked prompt the user's bitcoin client to ask the user if he wants to make a certain payment. (I.e., when the user clicks "Pay this bounty" on your site, then that prompts the user's Bitcoin client to make the payment.). Then, you have a daemon running that watches the Bitcoin blockchain to see if a payment of the right amount to the right recipient address(es) has been made. Once it has, then you update your web site.

Relatively simple! An important simplifying assumption for this purpose -- for the purpose of getting you started on writing something that works soon -- is to forget about USD conversion! Imagine, at least for the time being, that you have a separate parallel bounty in which everything is only in BTC. That will make the experiment I outlined above a lot simpler.

I'd be happy to be your guinea pig and try making payments. :-)

Actually, even simpler than having a button or link that prompts the user's bitcoin client, is just having instructions, that say: "To pay this bounty, send ⓑ2.00 to the coder — 14HRdapiCevEs155gGGb6iPdps4fx1XszL — and also please send ⓑ0.06 to freedomsponsors.org — 1CyFqmQUcMiEL2p5dGMJd4aaHqvAbZJWy5 — to pay for the development and operation of this web site. Thank you very much."

This is getting very simple now! There is almost no code you have to write for the payments. It is mostly just generating HTML that says something like the above. ☺

[tonylampada]

Nice, I like that :-)

That's what I'll do then: study how to write Python code to watch for transactions. Thanks @zooko !

[tonylampada]

I need BTC$ 1! :-) http://www.freedomsponsors.org/core/issue/74/lend-a-bitcoin-to-freedomsponsors I'll pay you back!

[tonylampada]

@zooko just lent me. And blockchain supports JSON (nice). Here's the transaction list for the address I provided - http://blockchain.info/address/1MehTUzFetEe9AfwzcNoxUvdYtU6RJvAfu?format=json

[tonylampada]

Hey @zooko, I have a few questions, can you please help me understand a little more about bitcoin?

1) Looking at the link I pasted above, it seems that you sent me bitcoins in a transaction where you paid another BTC 10.8880599 to another address, is that right?

That would illustrate what you said earlier:

Bitcoin actually natively supports that a single transaction can pay different amounts to different recipients.

I installed the MultiBit client and I don't see an option to make a payment like that. So I'm assuming that even if it's supported by the bitcoin protocol, it won't be implemented by all clients. Is that correct? Can I ask you which client do you use?

2) Regarding payments on FS:

requirement*: We need to be able to link bitcoin payments to payments in FS (so that we can mark an issue as paid)

To do that, the only way I can of is this:

a) Every programmer that wants to receive BTC would have to provide not one, but a few (for example 10) receiving addresses - If the programmer should receive money payments from different people and different issues, FS cannot use the same BTC address for two distinct payments, otherwise we can't meet the requirement*. Then each time someone goes to the "pay with bitcoins" page, we can "lock" that address for, say, 15 minutes.

b) For the same reason, we need to have multiple receiving addresses for the FreedomSponsors wallet. Of course, it's better if FS can generate addresses automatically rather than having them be registered through some admin interface. So I need a python lib to manipulate a BTC wallet (no need to do transactions, only generate addresses)

Does that analysis sound correct to you?

[tonylampada]

Having some trouble with multibit client... https://github.com/jim618/multibit/issues/58

[zooko]

1) Looking at the link I pasted above, it seems that you sent me bitcoins in a transaction where you paid another BTC 10.8880599 to another address, is that right? ... Can I ask you which client do you use?

I used an online service — a website — to make that payment. I have some Bitcoin in an account held by https://intersango.com. I entered into a form on that site (served over HTTPS) how much BTC to send and your address to send it to, then clicked "submit".

Now, I didn't pay any attention to the other part of that transaction, but now that you draw my attention to it, I guess it must be that the target of the ⓑ10.8880599 must be another private key also controlled by https://Intersango.com.

What if, instead of your proposals a) and b) above, you did something like this:

1. The recipient registers a Bitcoin address (a.k.a. public key a.k.a. verifying key) with FS.
2. When the sponsor commits to a certain donation (by saying "I'll contribute ⓑ10 to this"), then FS generates a new key-pair, stores the private key (a.k.a. the "signing key") securely (about which see more below), and gives the public key (a.k.a. the verifying key) to that sponsor. The verifying key doesn't need to be publicly shown to everyone, it needs only to be shown to that user (the sponsor).
3. When the sponsor sends a payment to that target signing key, FS detects this, and makes a payment sending the FS fee to their own key and sending the rest to the recipient's key. FS also updates the site to show that the sponsorship was paid out.

This scheme has the disadvantage that the Bitcoin flows through FS on its way from sponsor to recipient, but it has advantanges: a simpler UI for the sponsor, and an easy way for FS to reliably detect that the sponsorship has been paid.

Now about security: there's a risk of theft of the signing keys, but this risk is limited by the fact that FS doesn't hold the payment from the sponsor for longer than it takes to initiate the payment to the ultimate recipient. So there isn't a growing pile of Bitcoin on the FS server that would attract thieves.

The fees that FS is collecting for itself would be a growing pile, but the FS signing key (private key) can be held off-line, so that an attacker who takes over the FS servers wouldn't get access to that.

There is also a risk of accidental loss. This is a bigger risk! Accidental data loss is much more common than theft of secrets. Also, in the design I've just suggested, if FS loses a signing key, then even if FS lost it and found out that it was lost before the sponsor sent the transaction, then it would still be too late to prevent that BTC from being irretrievably destroyed. To mitigate this: 1. make backups of the signing keys, 2. delay generating the signing keys until the sponsor clicks on something indicating that they are ready to pay now.

[tonylampada]

Thanks @zooko I'll probably go that way as it is the simplest thing for all users (both programmers and sponsors). There's a python lib that might help: https://github.com/laanwj/bitcoin-python Will make a few tests with it later

[tonylampada]

I'm resuming work on this issue. (sorry for the long delay :$) I'm having a little trouble with bitcoind, opened this issue here: https://github.com/laanwj/bitcoin-python/issues/12

Maybe that guy can give me a hand :-)

[tonylampada]

I found an interesting alternative to bitcoind: http://blockchain.info/api/json_rpc_api

With this, in theory, I can still use bitcoin-python without having to run bitcoind on the server (which is a major resource hog)

Sounds promising. Will make a few tests with it later.

[tonylampada]

I made a few tests and it looks good - bitcoin+blockchain API for the win!

• generating new receiving addresses - check
• sending from an adress - check
• notification of new payments - check
• confirm receive - check

seems like everything is in place

[tonylampada]

This is going well. Next step - Create a Payment object for a BTC payment

[tonylampada]

Finally, the implementation for Bitcoin support is finished! Next step: run it on the test environment.

[tonylampada]

A few tests on the test environment revealed a couple of bugs, which were patched. Tomorrow I'll run more tests.

[tonylampada]

I'm now satisfied with the behaviour on the test environment. The code is now deployed to production, but it's not enabled yet. Will be soon :-)

[tonylampada]

• Code enabled in production - check
• Blog post - check
• Email to Richard Stallman - check

Ok, let's call this done :-)

[mk-fg]

It was surprisingly hard to find (for me) if the thing is implemented at the moment.

In fact, FAQ states:

• How does payment work?

  We use Paypal. You don’t need to have an account right away, but you’ll need one when you want to send or receive payments, so we suggest you go ahead and create your account. ...

• I don't have a Paypal account, is that ok?

  Well, you’re gonna need one to send or receive payments. Your profile has a “primary email” and an optional “Paypal email” field. If you leave “Paypal email” field blank, and someone tries to send you a payment, FS will consider your primary email as the Paypal account email. ...

"About" page mentions Bitcoin though.

Can maybe FAQ page be updated to mention it as well? As it stands, it seem to contradict "About".

[tonylampada]

@mk-fg, good catch, thanks!

I just updated the FAQ.