I can think of a few reasons why we should accept bitcoin:
* It's consistent with our leadership in internet technology * Our peers like EFF, and Internet archive accept it * It's secured using the same kinds of encryption we rely on to maintain user privacy * It permits donations from countries that do not have Visa/Mastercard services * It has a fanatically loyal and growing following that is dying to give us money in that currency
Most imporantly, current technology would permit us to accept bitcoin without ever *holding* bitcoin. Companies like BitPay ( https://bitpay.com/) and CoinBase ( https://coinbase.com/) are little different than accepting Visa, Mastercard, or Paypal. It's now possible for funds received as bitcoins to be *immediately* converted to USD.
I don't think we should 'make a statement' by accepting bitcoin, I think the currency is simply at the stage where it would be to our benefit to do so.
Jake (Ocaasi)
On Wed, Dec 11, 2013 at 12:31 PM, Jake Orlowitz jorlowitz@gmail.com wrote:
- Our peers like EFF, and Internet archive accept it
To be totally honest, I think this is moot.
Support for bitcoin among these two organizations has hardly been a ringing endorsement. In the past, EFF has rejected it for very practical reasons I think still apply.[1] As for Internet Archive, I was literally in the room when their fundraising staff announced they started accepting bitcoin, and they actually said they didn't really understand what it was, other than people requested they accept it.
In general, I would personally like it if the WMF avoided accepting bitcoin. Today, bitcoin isn't really a functioning currency of exchange -- it's actually used more as an investment tool to create wealth that naturally appreciates in value, like playing the stock market or buying gold. Avoiding lots of risky investments is something our very competent financial managers already steer clear of, and I see no reason to start taking on more risk now.
On Dec 13, 2013 5:55 AM, "Steven Walling" steven.walling@gmail.com wrote:
On Wed, Dec 11, 2013 at 12:31 PM, Jake Orlowitz jorlowitz@gmail.com
wrote:
- Our peers like EFF, and Internet archive accept it
To be totally honest, I think this is moot.
Support for bitcoin among these two organizations has hardly been a
ringing
endorsement. In the past, EFF has rejected it for very practical reasons I think still apply.[1] As for Internet Archive, I was literally in the room when their fundraising staff announced they started accepting bitcoin, and they actually said they didn't really understand what it was, other than people requested they accept it.
In general, I would personally like it if the WMF avoided accepting bitcoin. Today, bitcoin isn't really a functioning currency of exchange -- it's actually used more as an investment tool to create wealth that naturally appreciates in value, like playing the stock market or buying gold. Avoiding lots of risky investments is something our very competent financial managers already steer clear of, and I see no reason to start taking on more risk now.
As Peter just said, there is no risk if WMF converts bitcoin donations to USD immediately.
-- John Vandenberg
On Thu, Dec 12, 2013 at 8:17 PM, John Vandenberg jayvdb@gmail.com wrote:
As Peter just said, there is no risk if WMF converts bitcoin donations to USD immediately.
Uh... except that because Bitcoin is not a regulated currency, it's value has the potential to fluctuate wildly, and seems to have done so since it attracts speculators of all crazy sorts. Seems pretty fuckin risky to me.
Who's to say if the work involved in accepting bitcoins, monitoring transactions, converting them, etc. will be worth the actual donations we receive in bitcoin? Developing and maintaining payments systems doesn't come for free. Fundraising and finance staff at WMF work extremely hard to keep these systems running smoothly, and I for one don't think it's worth adding yet another potential system to build/maintain just to placate bitcoin devotees who want us to help promote their libertarian fantasy project.
Steven Walling wrote:
Uh... except that because Bitcoin is not a regulated currency, it's value has the potential to fluctuate wildly, and seems to have done so since it attracts speculators of all crazy sorts. Seems pretty fuckin risky to me.
I see no reason why the fluctuation of Bitcoin would be of any significance for the decision of accepting it as a donation method or not, especially if you use same-day exchange systems. In the end, you cannot loose more money than you gain if you accept Bitcoin; even if its value drops significantly, it will still be more money than if you didn't accept it.
From where I stand, there is very little difference between Bitcoin and regulated currencies, except perhaps the fluctuation rate (as in quickness); take the Argentine peso, the Brazilian real, or the Zimbabwean dollar as examples that even government-backed currencies can fluctuate (or, more precisely, lose in value) in relatively short periods.
Tomasz
On 13 December 2013 11:43, Steven Walling steven.walling@gmail.com wrote:
Who's to say if the work involved in accepting bitcoins, monitoring transactions, converting them, etc. will be worth the actual donations we receive in bitcoin? Developing and maintaining payments systems doesn't come for free. Fundraising and finance staff at WMF work extremely hard to keep these systems running smoothly, and I for one don't think it's worth adding yet another potential system to build/maintain just to placate bitcoin devotees who want us to help promote their libertarian fantasy project.
This is probably the key point: will it be worth the resources? How do comparable charities that accept Bitcoin do?
I'm sceptical about Bitcoin in general, but if it was worth it, then sure.
(If you have reliable payment conversion, the acceptance bit is easy. Hardest bit is someone to supply reliable and trustworthy conversion from Bitcoins to dollars. e.g. Mt. Gox wouldn't pass the sniff test IMO. Some Bitcoin operations are *terrifyingly* naive, as if financial-quality computer system reliability had never been thought of.)
- d.
On 13 December 2013 14:00, David Gerard dgerard@gmail.com wrote:
On 13 December 2013 11:43, Steven Walling steven.walling@gmail.com wrote:
Who's to say if the work involved in accepting bitcoins, monitoring transactions, converting them, etc. will be worth the actual donations we receive in bitcoin? Developing and maintaining payments systems doesn't come for free. Fundraising and finance staff at WMF work extremely hard
to
keep these systems running smoothly, and I for one don't think it's worth adding yet another potential system to build/maintain just to placate bitcoin devotees who want us to help promote their libertarian fantasy project.
This is probably the key point: will it be worth the resources? How do comparable charities that accept Bitcoin do?
I'm sceptical about Bitcoin in general, but if it was worth it, then sure.
(If you have reliable payment conversion, the acceptance bit is easy. Hardest bit is someone to supply reliable and trustworthy conversion from Bitcoins to dollars. e.g. Mt. Gox wouldn't pass the sniff test IMO. Some Bitcoin operations are *terrifyingly* naive, as if financial-quality computer system reliability had never been thought of.)
- d.
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Anecdotally:
From Reddit in March this year (not sure whether the situation has changed
or not) "So far we're spending more money on accountants handling the non-trivial reconciliation of our BTC transactions than revenue we're making in Bitcoin, haha. Hopefully it will get better." http://www.reddit.com/r/Bitcoin/comments/19t3uq/hey_rbitcoin_you_asked_for_s...
From the Humble Indie Bundle (a collection of indie computer games)
"It [bitcoin] represents less than 0.1% of our sales for Humble Indie Bundle 8, which is pretty surprising for me" http://www.reddit.com/r/IAmA/comments/1fex7h/were_humble_indie_bundle_8_crea...
Peter / the wub (speaking in a strictly personal capacity)
On Thu, Dec 12, 2013 at 11:54 PM, Steven Walling steven.walling@gmail.com wrote:
naturally appreciates in value, like playing the stock market or buying gold. Avoiding lots of risky investments is something our very competent
I do not plan to get into a perpetual debate just wanted to point out that there is no "playing" and "buying" and "risky investment" involved. Nobody asked WMF to buy BC or to convert existing assets to BC. All the risk has been taken by the donors (whether they donate $100 or $0), WMF *finiancially* risks exactly nothing (provided that we assume people who want to donate in BC would not use goventment money anyway, which seems logical to me).
Peter
On Thu, Dec 12, 2013 at 2:54 PM, Steven Walling steven.walling@gmail.com wrote:
In general, I would personally like it if the WMF avoided accepting bitcoin. Today, bitcoin isn't really a functioning currency of exchange -- it's actually used more as an investment tool to create wealth that naturally appreciates in value, like playing the stock market or buying gold. Avoiding lots of risky investments is something our very competent financial managers already steer clear of, and I see no reason to start taking on more risk now.
While this is true, a more pragmatic view is that, as long as BTC has value to some people, there's no harm in accepting it and transferring it to USD the moment we receive any, provided legal/financial issues can be addressed with reasonable effort.
The strongest counter-argument is that we might not actually get a donation total that makes this worth our time. The Internet Archive has a single-use Bitcoin address that's received a total of <$30K at current (insanely high) exchange rates.
But for me, the main reason not do this sooner is that it would have significantly fueled the Bitcoin speculative bubble, and WMF should remain neutral on the utility of Bitcoin. At this point though, whatever WMF does or doesn't do is just a small drop in the bucket of the overall Bitcoin mania, so I'm personally fine with a decision being made on pragmatic grounds alone.
My own view is that Bitcoin has significant design flaws (built-in economic inequality, most rational actors will hoard rather than spend, doubtful long-term scalability, questionable value as an actual currency due to crazy volatility, tendency to centralize power with miners, rampant security attacks against BTC holders, etc.), but as long as no more severe technical flaws are discovered/exploited, at least some value will likely attach to BTC for some time to come, even if it's dramatically less than the current exchange rate.
With that said, I fully defer to our fundraising team on this since it's a decision that should be made purely on cost/benefit grounds, perhaps by also comparing with other currencies that see relatively little use.
The one unambiguous positive that I see coming out of Bitcoin mania is a renewed interest in peer-to-peer networks; the last time that happened was about 12 years ago, and it resulted in technologies like BitTorrent, Tor, various file sharing networks and many others being developed. Experimenting is, overall, a good thing, and no matter how this one plays out (and how exhausting a topic it can be given the idiocy of coverage about it), I'm optimistic that we will see positive ripple effects for the free culture movement.
Erik
[1] https://blockchain.info/address/1Archive1n2C579dMsAu3iC6tWzuQJz8dN
Thanks Erik for a well written overview.
Would it be possible for the WMF to give an estimate on what it would cost to build and/or what the threshold of annual bitcoin donations would make it worthwhile building. Someone might be interested in donating specifically to have this built, or we could obtain pledges to donate to see if the threshold can be reached. On Jan 9, 2014 9:06 AM, "Erik Moeller" erik@wikimedia.org wrote:
On Thu, Dec 12, 2013 at 2:54 PM, Steven Walling steven.walling@gmail.com wrote:
In general, I would personally like it if the WMF avoided accepting bitcoin. Today, bitcoin isn't really a functioning currency of exchange
--
it's actually used more as an investment tool to create wealth that naturally appreciates in value, like playing the stock market or buying gold. Avoiding lots of risky investments is something our very competent financial managers already steer clear of, and I see no reason to start taking on more risk now.
While this is true, a more pragmatic view is that, as long as BTC has value to some people, there's no harm in accepting it and transferring it to USD the moment we receive any, provided legal/financial issues can be addressed with reasonable effort.
The strongest counter-argument is that we might not actually get a donation total that makes this worth our time. The Internet Archive has a single-use Bitcoin address that's received a total of <$30K at current (insanely high) exchange rates.
But for me, the main reason not do this sooner is that it would have significantly fueled the Bitcoin speculative bubble, and WMF should remain neutral on the utility of Bitcoin. At this point though, whatever WMF does or doesn't do is just a small drop in the bucket of the overall Bitcoin mania, so I'm personally fine with a decision being made on pragmatic grounds alone.
My own view is that Bitcoin has significant design flaws (built-in economic inequality, most rational actors will hoard rather than spend, doubtful long-term scalability, questionable value as an actual currency due to crazy volatility, tendency to centralize power with miners, rampant security attacks against BTC holders, etc.), but as long as no more severe technical flaws are discovered/exploited, at least some value will likely attach to BTC for some time to come, even if it's dramatically less than the current exchange rate.
With that said, I fully defer to our fundraising team on this since it's a decision that should be made purely on cost/benefit grounds, perhaps by also comparing with other currencies that see relatively little use.
The one unambiguous positive that I see coming out of Bitcoin mania is a renewed interest in peer-to-peer networks; the last time that happened was about 12 years ago, and it resulted in technologies like BitTorrent, Tor, various file sharing networks and many others being developed. Experimenting is, overall, a good thing, and no matter how this one plays out (and how exhausting a topic it can be given the idiocy of coverage about it), I'm optimistic that we will see positive ripple effects for the free culture movement.
Erik
[1] https://blockchain.info/address/1Archive1n2C579dMsAu3iC6tWzuQJz8dN
Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
I will probably regret saying this[1] -- but the figure we like to throw around here in fundraising tech is that a new payments gateway [2] is not even worth considering unless it is likely to make us at least 500K USD a year[3]. Or, in the case that it is not an immediate payoff, if it is strategically relevant for the future of our income stream (think our recent forays into mobile). It's also worth stating that at this time we only use four gateways (we get the hundreds of currencies through gateways that serve multiple methods and countries.)
It is a significant undertaking to integrate a new gateway with our current code (think several man months of time related to coding, code review, donor services preparation, and testing; not including contract negotiation and legal review.) In addition, every gateway incurs additional maintenance, auditing, and troubleshooting costs on an ongoing basis. Because of these costs, we have only four gateways (Adyen, Amazon, GlobalCollect, and PayPal); with active plans to add another (already determined) gateway this year for common methods and regions we don't already serve.
Formally the dept has not conducted a cost/benefit analysis of accepting bitcoin or any other cryptocurrency. Nor have we asked the legal dept to look into it from a compliance point of view. I have been attempting to gather data for an informal blog post on the topic and I have found no indication that if we were to conduct such a study formally that it would come out positively.
I will state again the contents of our FAQ: "We do, however, strive to provide as many methods of donating as possible and continue to monitor Bitcoin with interest and may revisit this position should circumstances change." I would encourage those who are put off by the Wikimedia Foundation's non acceptance of cryptocurrency donations to consider alternative methods of donation and promoting of free knowledge; namely by becoming active editors.
[1] <personal hat> The bitcoin community should be aware that their persistent and often times aggressive, rude, and vulgar messaging towards me and my fellow coworkers is not appreciated; nor does it help their cause. If the goals of the cryptocurrency movement include shedding the world of fiscal dictators, centralized control, and autocracy; then perhaps it is time for some introspection. From my standpoint the actions of the movement (or at least the actions of a significant number who are public on the internet that I have read) are scarily similar to those whom the moment stands to replace. </personal hat>
[2] A payments gateway can be simply thought of as a collection of APIs, coupled into DonationInterface, our backend CRM, and financial software, that can accept payments and remit them in an auditable way to the Wikimedia Foundation in one of our working currencies.
[3] This number isn't set in stone and should not be considered a formal estimate, but consider that the Wikimedia Foundation's yearly budget is ~$50M. As fundraisers ideally we want to focus effort on things that can provide a significant portion of that. We also do not wish to spend money on things that would increase our useful spending to overhead spending ratio.
~Matt Walker Wikimedia Foundation Fundraising Technology Team
On Wed, Jan 8, 2014 at 7:05 PM, John Vandenberg jayvdb@gmail.com wrote:
Thanks Erik for a well written overview.
Would it be possible for the WMF to give an estimate on what it would cost to build and/or what the threshold of annual bitcoin donations would make it worthwhile building. Someone might be interested in donating specifically to have this built, or we could obtain pledges to donate to see if the threshold can be reached. On Jan 9, 2014 9:06 AM, "Erik Moeller" erik@wikimedia.org wrote:
On Thu, Dec 12, 2013 at 2:54 PM, Steven Walling steven.walling@gmail.com wrote:
In general, I would personally like it if the WMF avoided accepting bitcoin. Today, bitcoin isn't really a functioning currency of exchange
--
it's actually used more as an investment tool to create wealth that naturally appreciates in value, like playing the stock market or buying gold. Avoiding lots of risky investments is something our very
competent
financial managers already steer clear of, and I see no reason to start taking on more risk now.
While this is true, a more pragmatic view is that, as long as BTC has value to some people, there's no harm in accepting it and transferring it to USD the moment we receive any, provided legal/financial issues can be addressed with reasonable effort.
The strongest counter-argument is that we might not actually get a donation total that makes this worth our time. The Internet Archive has a single-use Bitcoin address that's received a total of <$30K at current (insanely high) exchange rates.
But for me, the main reason not do this sooner is that it would have significantly fueled the Bitcoin speculative bubble, and WMF should remain neutral on the utility of Bitcoin. At this point though, whatever WMF does or doesn't do is just a small drop in the bucket of the overall Bitcoin mania, so I'm personally fine with a decision being made on pragmatic grounds alone.
My own view is that Bitcoin has significant design flaws (built-in economic inequality, most rational actors will hoard rather than spend, doubtful long-term scalability, questionable value as an actual currency due to crazy volatility, tendency to centralize power with miners, rampant security attacks against BTC holders, etc.), but as long as no more severe technical flaws are discovered/exploited, at least some value will likely attach to BTC for some time to come, even if it's dramatically less than the current exchange rate.
With that said, I fully defer to our fundraising team on this since it's a decision that should be made purely on cost/benefit grounds, perhaps by also comparing with other currencies that see relatively little use.
The one unambiguous positive that I see coming out of Bitcoin mania is a renewed interest in peer-to-peer networks; the last time that happened was about 12 years ago, and it resulted in technologies like BitTorrent, Tor, various file sharing networks and many others being developed. Experimenting is, overall, a good thing, and no matter how this one plays out (and how exhausting a topic it can be given the idiocy of coverage about it), I'm optimistic that we will see positive ripple effects for the free culture movement.
Erik
[1] https://blockchain.info/address/1Archive1n2C579dMsAu3iC6tWzuQJz8dN
Erik Möller VP of Engineering and Product Development, Wikimedia Foundation
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Wed, Jan 8, 2014 at 8:38 PM, Matthew Walker mwalker@wikimedia.org wrote:
It is a significant undertaking to integrate a new gateway with our current code (think several man months of time related to coding, code review, donor services preparation, and testing; not including contract negotiation and legal review.)
That makes perfect sense, Matt. It's easy to forget that because BTC is so novel, none of the existing payment gateways we have implemented support it, so comparing to existing currencies is really misleading. So you're left with either the DIY approach the Internet Archive is taking [1], or the technical effort of properly integrating something like Bitpay.
The bitcoin community should be aware that their persistent and often times aggressive, rude, and vulgar messaging towards me and my fellow coworkers is not appreciated;
Indeed. Unfortunately the incentive structure of Bitcoin's bubble economy turns ordinary people into obnoxious hucksters.
Erik
[1] Srsly! Just one example: http://blog.archive.org/2013/03/05/bitcoin-to-cash-converter-box/
On Jan 9, 2014 11:38 AM, "Matthew Walker" mwalker@wikimedia.org wrote:
I will probably regret saying this[1] -- but the figure we like to throw around here in fundraising tech is that a new payments gateway [2] is not even worth considering unless it is likely to make us at least 500K USD a year[3].
Thanks for putting a number on the table.
It is a tad higher than I expected, being more than several very highly paid person years, but it is a starting point.
In case an enthuiast who can code is reading this thread, which repository needs bitcoin support?
-- John
That very rough number that Matt threw out there has far less to do with the cost of applying human brainpower than it does with the cost of taking the available brainpower away from things we know are going to significantly increase our efficacy. We have several of those things looming on the horizon, and we choose to concentrate new development on what we know will be the biggest earners out of those.
My understanding (I am no analyst) is that we continue to have a difficult time finding hard evidence that bitcoin is currently anywhere near the other top candidates, so it remains off the roadmap in favor of concentrating on solid numbers. If anybody would like to supply us with hard figures, we’d certainly be interested in seeing them.
The main reason the expected earnings > one dude’s salary calculation of worthiness doesn’t work here, is that there are four people in fundraising engineering. The four of us support and maintain all existing payments functionality, ensure integrity of the donation pipeline, and do all new code development and review. For the sake of the foundation and the movement, each one of us has to do significantly better than individually break even.
As the fundraising tech lead, I definitely appreciate any outside interest in potentially helping us out by modifying fundraising code in order to support more payment methods, and I would be happy to outline the general process of integrating with a new gateway in a way that is consistent with our current code.
Before I get in to the nitty-gritty, though, I want to be completely clear on this one point: Even if I had the authority to do so (I do not), there is no universe in which I am willing to enable new functionality simply because the switch exists. Matt has already done a pretty good job outlining the scope of the collective distraction that bitcoin represents, and that scope extends well beyond tech. In fact, it seems to me that producing the actual integration code is the most trivial issue regarding bitcoin integration that has been brought up thus far, and I would not be pleased to see well-intentioned volunteer time go to waste over hastily dismissed blocking issues which exist well outside the purview of the fundraising tech team.
That said, here is a very general 30,000 foot view of a typical new gateway integration from a purely technical standpoint:
* Donation Interface[1]: This is the mediawiki extension that initiates payments. A new gateway adapter child class will need to be created, which will run in parallel to the existing enabled gateway adapters, and not short-circuit any of the class constraints that have been deliberately built in to the gateway adapter parent class. Then, an appropriate form (or redirect) should be created to handle the user experience, which uses the RapidHTML templating system. At the end of it all, after a successful donation has been made, an internal donation message should be queued. Happily, examples of all the things I just mentioned already exist in other gateway adapter objects; New gateways are rarely so unusual that we haven’t nearly done it before. * Payments Listener[2]: Most payment gateways worth even brief consideration, have an optional near-realtime notification system. This system tells us when we receive new payments, and existing payments change status (cancels, refunds, chargebacks). We would need to create a listener to receive realtime payment updates, process them securely, and queue donation messages when appropriate. Though a realtime message listener is usually not strictly required in order to get paid through a new gateway integration, I have recently decided to require them wherever possible. * Nightly reconciliation / auditing[3]: Every payment gateway we integrate with provides a daily downloadable list of all the transactions we should have on record. So, a job needs to be created that will download the daily file and chew through our records to make sure we have all the relevant data, and rebuild anything we may have missed. This job needs to be set up to run daily. * Queue consumer module for civicrm integration[4]: The donations queue consumer will need to be modified, to accept and correctly process donation messages from the new gateway, in a way that is consistent with our existing data.
Of course, all of this work will require pretty consistent code review, which will bottleneck on the same four fundraising engineers. As it happens, the number of non-fundraising engineers who are willing to code review for fundraising without special encouragement, has historically been so close to zero it’s almost not worth mentioning.
In the event that any volunteers are willing to take this on, I have three things to say: #1 - There are no guarantees that your code will ever be enabled by the WMF. Ever. Yes, I already said it. It seems important enough to mention twice. Even if the tech team decides your code is beautiful and flawless and we love you, it is still likely to end up an overblown expression of futility that spans four codebases. If this isn’t a problem for you, by all means: Go for it. #2 - To greatly increase the likelihood that your code will be reviewed, looked on favorably, and eventually merged (not enabled, though. Not my call. See #1), you should probably get in contact with the fundraising tech team and keep us informed about what you’re up to. The best way to do that is to get in contact with us on IRC. There are usually a few of us tech types in #wikimedia-fundraising, so that’s probably the best place to start looking for specific guidance. #3 - Just kidding; It’s #1 again.
-Katie Horn Fundraising Tech Lead Wikimedia Foundation
[1] - Donation Interface: https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Donatio... [2] - Listener: https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/SmashP... [3] - Reconciliation and Auditing: At the moment, our auditing code is not centralized. Some of it is in the CRM repo (below), and some of it lives in https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/tools,... [4] - Donations Queue Consumer: https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/crm,br...
On Wed, Jan 8, 2014 at 9:31 PM, John Vandenberg jayvdb@gmail.com wrote:
On Jan 9, 2014 11:38 AM, "Matthew Walker" mwalker@wikimedia.org wrote:
I will probably regret saying this[1] -- but the figure we like to throw around here in fundraising tech is that a new payments gateway [2] is not even worth considering unless it is likely to make us at least 500K USD a year[3].
Thanks for putting a number on the table.
It is a tad higher than I expected, being more than several very highly paid person years, but it is a starting point.
In case an enthuiast who can code is reading this thread, which repository needs bitcoin support?
-- John _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Hi everyone,
I thought it may be worth pointing out that this conversation has be re-opened by Jimmy on reddit: http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_wi...http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_wikipedia/
On it he states "I'm planning to re-open the conversation with the Wikimedia Foundation Board of Directors at our next meeting (and before, by email) about whether Wikimedia should accept bitcoin." More info at the thread itself.
Regards,
Charles / User:Chuq
On Fri, Jan 10, 2014 at 10:44 AM, Katie Horn khorn@wikimedia.org wrote:
That very rough number that Matt threw out there has far less to do with the cost of applying human brainpower than it does with the cost of taking the available brainpower away from things we know are going to significantly increase our efficacy. We have several of those things looming on the horizon, and we choose to concentrate new development on what we know will be the biggest earners out of those.
My understanding (I am no analyst) is that we continue to have a difficult time finding hard evidence that bitcoin is currently anywhere near the other top candidates, so it remains off the roadmap in favor of concentrating on solid numbers. If anybody would like to supply us with hard figures, we'd certainly be interested in seeing them.
The main reason the expected earnings > one dude's salary calculation of worthiness doesn't work here, is that there are four people in fundraising engineering. The four of us support and maintain all existing payments functionality, ensure integrity of the donation pipeline, and do all new code development and review. For the sake of the foundation and the movement, each one of us has to do significantly better than individually break even.
As the fundraising tech lead, I definitely appreciate any outside interest in potentially helping us out by modifying fundraising code in order to support more payment methods, and I would be happy to outline the general process of integrating with a new gateway in a way that is consistent with our current code.
Before I get in to the nitty-gritty, though, I want to be completely clear on this one point: Even if I had the authority to do so (I do not), there is no universe in which I am willing to enable new functionality simply because the switch exists. Matt has already done a pretty good job outlining the scope of the collective distraction that bitcoin represents, and that scope extends well beyond tech. In fact, it seems to me that producing the actual integration code is the most trivial issue regarding bitcoin integration that has been brought up thus far, and I would not be pleased to see well-intentioned volunteer time go to waste over hastily dismissed blocking issues which exist well outside the purview of the fundraising tech team.
That said, here is a very general 30,000 foot view of a typical new gateway integration from a purely technical standpoint:
- Donation Interface[1]: This is the mediawiki extension that initiates
payments. A new gateway adapter child class will need to be created, which will run in parallel to the existing enabled gateway adapters, and not short-circuit any of the class constraints that have been deliberately built in to the gateway adapter parent class. Then, an appropriate form (or redirect) should be created to handle the user experience, which uses the RapidHTML templating system. At the end of it all, after a successful donation has been made, an internal donation message should be queued. Happily, examples of all the things I just mentioned already exist in other gateway adapter objects; New gateways are rarely so unusual that we haven't nearly done it before.
- Payments Listener[2]: Most payment gateways worth even brief
consideration, have an optional near-realtime notification system. This system tells us when we receive new payments, and existing payments change status (cancels, refunds, chargebacks). We would need to create a listener to receive realtime payment updates, process them securely, and queue donation messages when appropriate. Though a realtime message listener is usually not strictly required in order to get paid through a new gateway integration, I have recently decided to require them wherever possible.
- Nightly reconciliation / auditing[3]: Every payment gateway we integrate
with provides a daily downloadable list of all the transactions we should have on record. So, a job needs to be created that will download the daily file and chew through our records to make sure we have all the relevant data, and rebuild anything we may have missed. This job needs to be set up to run daily.
- Queue consumer module for civicrm integration[4]: The donations queue
consumer will need to be modified, to accept and correctly process donation messages from the new gateway, in a way that is consistent with our existing data.
Of course, all of this work will require pretty consistent code review, which will bottleneck on the same four fundraising engineers. As it happens, the number of non-fundraising engineers who are willing to code review for fundraising without special encouragement, has historically been so close to zero it's almost not worth mentioning.
In the event that any volunteers are willing to take this on, I have three things to say: #1 - There are no guarantees that your code will ever be enabled by the WMF. Ever. Yes, I already said it. It seems important enough to mention twice. Even if the tech team decides your code is beautiful and flawless and we love you, it is still likely to end up an overblown expression of futility that spans four codebases. If this isn't a problem for you, by all means: Go for it. #2 - To greatly increase the likelihood that your code will be reviewed, looked on favorably, and eventually merged (not enabled, though. Not my call. See #1), you should probably get in contact with the fundraising tech team and keep us informed about what you're up to. The best way to do that is to get in contact with us on IRC. There are usually a few of us tech types in #wikimedia-fundraising, so that's probably the best place to start looking for specific guidance. #3 - Just kidding; It's #1 again.
-Katie Horn Fundraising Tech Lead Wikimedia Foundation
[1] - Donation Interface:
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Donatio... [2] - Listener:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/SmashP... [3] - Reconciliation and Auditing: At the moment, our auditing code is not centralized. Some of it is in the CRM repo (below), and some of it lives in
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/tools,... [4] - Donations Queue Consumer:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/crm,br...
On Wed, Jan 8, 2014 at 9:31 PM, John Vandenberg jayvdb@gmail.com wrote:
On Jan 9, 2014 11:38 AM, "Matthew Walker" mwalker@wikimedia.org wrote:
I will probably regret saying this[1] -- but the figure we like to
throw
around here in fundraising tech is that a new payments gateway [2] is
not
even worth considering unless it is likely to make us at least 500K
USD a
year[3].
Thanks for putting a number on the table.
It is a tad higher than I expected, being more than several very highly paid person years, but it is a starting point.
In case an enthuiast who can code is reading this thread, which
repository
needs bitcoin support?
-- John _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Jimmy's already noted this is WRONG, but the erroneous Telegraph story reads:
"Wikipedia charity begins accepting Bitcoin donations after co-founder Jimmy Wales set up a personal account "to play around" with digital currency and was swamped with cash"
http://www.telegraph.co.uk/technology/wikipedia/10687380/Wales-inundated-wit...
*Jimmy Wales* @jimmy_wales https://twitter.com/jimmy_wales 7mhttps://twitter.com/jimmy_wales/status/443031310207311872
Yo, @Telegraph https://twitter.com/Telegraph, this story is wrong: http://www.telegraph.co.uk/technology/wik ipedia/10687380/Wales-inundated-with-Wikipedia-donations-after-publishing-personal-Bitcoin-address.html ... http://t.co/fM3CTBzRsE No decision has been made for Wikipedia to accept BTC!
On Mon, Mar 10, 2014 at 9:26 AM, Charles Gregory wmau.lists@chuq.netwrote:
Hi everyone,
I thought it may be worth pointing out that this conversation has be re-opened by Jimmy on reddit: http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_wi... < http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_wi...
On it he states "I'm planning to re-open the conversation with the Wikimedia Foundation Board of Directors at our next meeting (and before, by email) about whether Wikimedia should accept bitcoin." More info at the thread itself.
Regards,
Charles / User:Chuq
On Fri, Jan 10, 2014 at 10:44 AM, Katie Horn khorn@wikimedia.org wrote:
That very rough number that Matt threw out there has far less to do with the cost of applying human brainpower than it does with the cost of
taking
the available brainpower away from things we know are going to significantly increase our efficacy. We have several of those things looming on the horizon, and we choose to concentrate new development on what we know will be the biggest earners out of those.
My understanding (I am no analyst) is that we continue to have a
difficult
time finding hard evidence that bitcoin is currently anywhere near the other top candidates, so it remains off the roadmap in favor of concentrating on solid numbers. If anybody would like to supply us with hard figures, we'd certainly be interested in seeing them.
The main reason the expected earnings > one dude's salary calculation of worthiness doesn't work here, is that there are four people in
fundraising
engineering. The four of us support and maintain all existing payments functionality, ensure integrity of the donation pipeline, and do all new code development and review. For the sake of the foundation and the movement, each one of us has to do significantly better than individually break even.
As the fundraising tech lead, I definitely appreciate any outside
interest
in potentially helping us out by modifying fundraising code in order to support more payment methods, and I would be happy to outline the general process of integrating with a new gateway in a way that is consistent
with
our current code.
Before I get in to the nitty-gritty, though, I want to be completely
clear
on this one point: Even if I had the authority to do so (I do not), there is no universe in which I am willing to enable new functionality simply because the switch exists. Matt has already done a pretty good job outlining the scope of the collective distraction that bitcoin
represents,
and that scope extends well beyond tech. In fact, it seems to me that producing the actual integration code is the most trivial issue regarding bitcoin integration that has been brought up thus far, and I would not be pleased to see well-intentioned volunteer time go to waste over hastily dismissed blocking issues which exist well outside the purview of the fundraising tech team.
That said, here is a very general 30,000 foot view of a typical new
gateway
integration from a purely technical standpoint:
- Donation Interface[1]: This is the mediawiki extension that initiates
payments. A new gateway adapter child class will need to be created,
which
will run in parallel to the existing enabled gateway adapters, and not short-circuit any of the class constraints that have been deliberately built in to the gateway adapter parent class. Then, an appropriate form
(or
redirect) should be created to handle the user experience, which uses the RapidHTML templating system. At the end of it all, after a successful donation has been made, an internal donation message should be queued. Happily, examples of all the things I just mentioned already exist in
other
gateway adapter objects; New gateways are rarely so unusual that we
haven't
nearly done it before.
- Payments Listener[2]: Most payment gateways worth even brief
consideration, have an optional near-realtime notification system. This system tells us when we receive new payments, and existing payments
change
status (cancels, refunds, chargebacks). We would need to create a
listener
to receive realtime payment updates, process them securely, and queue donation messages when appropriate. Though a realtime message listener is usually not strictly required in order to get paid through a new gateway integration, I have recently decided to require them wherever possible.
- Nightly reconciliation / auditing[3]: Every payment gateway we
integrate
with provides a daily downloadable list of all the transactions we should have on record. So, a job needs to be created that will download the
daily
file and chew through our records to make sure we have all the relevant data, and rebuild anything we may have missed. This job needs to be set
up
to run daily.
- Queue consumer module for civicrm integration[4]: The donations queue
consumer will need to be modified, to accept and correctly process
donation
messages from the new gateway, in a way that is consistent with our existing data.
Of course, all of this work will require pretty consistent code review, which will bottleneck on the same four fundraising engineers. As it happens, the number of non-fundraising engineers who are willing to code review for fundraising without special encouragement, has historically
been
so close to zero it's almost not worth mentioning.
In the event that any volunteers are willing to take this on, I have
three
things to say: #1 - There are no guarantees that your code will ever be enabled by the WMF. Ever. Yes, I already said it. It seems important enough to mention twice. Even
if
the tech team decides your code is beautiful and flawless and we love
you,
it is still likely to end up an overblown expression of futility that
spans
four codebases. If this isn't a problem for you, by all means: Go for it. #2 - To greatly increase the likelihood that your code will be reviewed, looked on favorably, and eventually merged (not enabled, though. Not my call. See #1), you should probably get in contact with the fundraising
tech
team and keep us informed about what you're up to. The best way to do
that
is to get in contact with us on IRC. There are usually a few of us tech types in #wikimedia-fundraising, so that's probably the best place to
start
looking for specific guidance. #3 - Just kidding; It's #1 again.
-Katie Horn Fundraising Tech Lead Wikimedia Foundation
[1] - Donation Interface:
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Donatio...
[2] - Listener:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/SmashP...
[3] - Reconciliation and Auditing: At the moment, our auditing code is
not
centralized. Some of it is in the CRM repo (below), and some of it lives
in
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/tools,...
[4] - Donations Queue Consumer:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/crm,br...
On Wed, Jan 8, 2014 at 9:31 PM, John Vandenberg jayvdb@gmail.com
wrote:
On Jan 9, 2014 11:38 AM, "Matthew Walker" mwalker@wikimedia.org
wrote:
I will probably regret saying this[1] -- but the figure we like to
throw
around here in fundraising tech is that a new payments gateway [2] is
not
even worth considering unless it is likely to make us at least 500K
USD a
year[3].
Thanks for putting a number on the table.
It is a tad higher than I expected, being more than several very highly paid person years, but it is a starting point.
In case an enthuiast who can code is reading this thread, which
repository
needs bitcoin support?
-- John _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
<sarcasm>
Wow, we've made an entire 1.6k out of bitcoin? This totally seems like the highest-value way to spend our time! Thanks, Bitcoin! I'm sure that the value of these items won't wildly vary in short spaces of time based on things like, oh, your propensity to have banking neophytes host your exchanges and end up shut down.
</sarcasm>
On 10 March 2014 07:39, Andrew Lih andrew.lih@gmail.com wrote:
Jimmy's already noted this is WRONG, but the erroneous Telegraph story reads:
"Wikipedia charity begins accepting Bitcoin donations after co-founder Jimmy Wales set up a personal account "to play around" with digital currency and was swamped with cash"
http://www.telegraph.co.uk/technology/wikipedia/10687380/Wales-inundated-wit...
*Jimmy Wales* @jimmy_wales https://twitter.com/jimmy_wales 7mhttps://twitter.com/jimmy_wales/status/443031310207311872
Yo, @Telegraph https://twitter.com/Telegraph, this story is wrong: http://www.telegraph.co.uk/technology/wik
ipedia/10687380/Wales-inundated-with-Wikipedia-donations-after-publishing-personal-Bitcoin-address.html ... http://t.co/fM3CTBzRsE No decision has been made for Wikipedia to accept BTC!
On Mon, Mar 10, 2014 at 9:26 AM, Charles Gregory <wmau.lists@chuq.net
wrote:
Hi everyone,
I thought it may be worth pointing out that this conversation has be re-opened by Jimmy on reddit:
http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_wi...
<
http://www.reddit.com/r/Bitcoin/comments/201fa6/hello_from_jimmy_wales_of_wi...
On it he states "I'm planning to re-open the conversation with the Wikimedia Foundation Board of Directors at our next meeting (and before,
by
email) about whether Wikimedia should accept bitcoin." More info at the thread itself.
Regards,
Charles / User:Chuq
On Fri, Jan 10, 2014 at 10:44 AM, Katie Horn khorn@wikimedia.org
wrote:
That very rough number that Matt threw out there has far less to do
with
the cost of applying human brainpower than it does with the cost of
taking
the available brainpower away from things we know are going to significantly increase our efficacy. We have several of those things looming on the horizon, and we choose to concentrate new development on what we know will be the biggest earners out of those.
My understanding (I am no analyst) is that we continue to have a
difficult
time finding hard evidence that bitcoin is currently anywhere near the other top candidates, so it remains off the roadmap in favor of concentrating on solid numbers. If anybody would like to supply us with hard figures, we'd certainly be interested in seeing them.
The main reason the expected earnings > one dude's salary calculation
of
worthiness doesn't work here, is that there are four people in
fundraising
engineering. The four of us support and maintain all existing payments functionality, ensure integrity of the donation pipeline, and do all
new
code development and review. For the sake of the foundation and the movement, each one of us has to do significantly better than
individually
break even.
As the fundraising tech lead, I definitely appreciate any outside
interest
in potentially helping us out by modifying fundraising code in order to support more payment methods, and I would be happy to outline the
general
process of integrating with a new gateway in a way that is consistent
with
our current code.
Before I get in to the nitty-gritty, though, I want to be completely
clear
on this one point: Even if I had the authority to do so (I do not),
there
is no universe in which I am willing to enable new functionality simply because the switch exists. Matt has already done a pretty good job outlining the scope of the collective distraction that bitcoin
represents,
and that scope extends well beyond tech. In fact, it seems to me that producing the actual integration code is the most trivial issue
regarding
bitcoin integration that has been brought up thus far, and I would not
be
pleased to see well-intentioned volunteer time go to waste over hastily dismissed blocking issues which exist well outside the purview of the fundraising tech team.
That said, here is a very general 30,000 foot view of a typical new
gateway
integration from a purely technical standpoint:
- Donation Interface[1]: This is the mediawiki extension that initiates
payments. A new gateway adapter child class will need to be created,
which
will run in parallel to the existing enabled gateway adapters, and not short-circuit any of the class constraints that have been deliberately built in to the gateway adapter parent class. Then, an appropriate form
(or
redirect) should be created to handle the user experience, which uses
the
RapidHTML templating system. At the end of it all, after a successful donation has been made, an internal donation message should be queued. Happily, examples of all the things I just mentioned already exist in
other
gateway adapter objects; New gateways are rarely so unusual that we
haven't
nearly done it before.
- Payments Listener[2]: Most payment gateways worth even brief
consideration, have an optional near-realtime notification system. This system tells us when we receive new payments, and existing payments
change
status (cancels, refunds, chargebacks). We would need to create a
listener
to receive realtime payment updates, process them securely, and queue donation messages when appropriate. Though a realtime message listener
is
usually not strictly required in order to get paid through a new
gateway
integration, I have recently decided to require them wherever possible.
- Nightly reconciliation / auditing[3]: Every payment gateway we
integrate
with provides a daily downloadable list of all the transactions we
should
have on record. So, a job needs to be created that will download the
daily
file and chew through our records to make sure we have all the relevant data, and rebuild anything we may have missed. This job needs to be set
up
to run daily.
- Queue consumer module for civicrm integration[4]: The donations queue
consumer will need to be modified, to accept and correctly process
donation
messages from the new gateway, in a way that is consistent with our existing data.
Of course, all of this work will require pretty consistent code review, which will bottleneck on the same four fundraising engineers. As it happens, the number of non-fundraising engineers who are willing to
code
review for fundraising without special encouragement, has historically
been
so close to zero it's almost not worth mentioning.
In the event that any volunteers are willing to take this on, I have
three
things to say: #1 - There are no guarantees that your code will ever be enabled by the WMF. Ever. Yes, I already said it. It seems important enough to mention twice.
Even
if
the tech team decides your code is beautiful and flawless and we love
you,
it is still likely to end up an overblown expression of futility that
spans
four codebases. If this isn't a problem for you, by all means: Go for it. #2 - To greatly increase the likelihood that your code will be
reviewed,
looked on favorably, and eventually merged (not enabled, though. Not my call. See #1), you should probably get in contact with the fundraising
tech
team and keep us informed about what you're up to. The best way to do
that
is to get in contact with us on IRC. There are usually a few of us tech types in #wikimedia-fundraising, so that's probably the best place to
start
looking for specific guidance. #3 - Just kidding; It's #1 again.
-Katie Horn Fundraising Tech Lead Wikimedia Foundation
[1] - Donation Interface:
https://gerrit.wikimedia.org/r/#/admin/projects/mediawiki/extensions/Donatio...
[2] - Listener:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/SmashP...
[3] - Reconciliation and Auditing: At the moment, our auditing code is
not
centralized. Some of it is in the CRM repo (below), and some of it
lives
in
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/tools,...
[4] - Donations Queue Consumer:
https://gerrit.wikimedia.org/r/#/admin/projects/wikimedia/fundraising/crm,br...
On Wed, Jan 8, 2014 at 9:31 PM, John Vandenberg jayvdb@gmail.com
wrote:
On Jan 9, 2014 11:38 AM, "Matthew Walker" mwalker@wikimedia.org
wrote:
I will probably regret saying this[1] -- but the figure we like to
throw
around here in fundraising tech is that a new payments gateway [2]
is
not
even worth considering unless it is likely to make us at least 500K
USD a
year[3].
Thanks for putting a number on the table.
It is a tad higher than I expected, being more than several very
highly
paid person years, but it is a starting point.
In case an enthuiast who can code is reading this thread, which
repository
needs bitcoin support?
-- John _______________________________________________ Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe:
https://lists.wikimedia.org/mailman/listinfo/wikimedia-l,
mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
Wikimedia-l mailing list Wikimedia-l@lists.wikimedia.org Unsubscribe: https://lists.wikimedia.org/mailman/listinfo/wikimedia-l, mailto:wikimedia-l-request@lists.wikimedia.org?subject=unsubscribe
On Mon, Mar 10, 2014 at 11:02 AM, Oliver Keyes okeyes@wikimedia.org wrote:
<sarcasm>
Wow, we've made an entire 1.6k out of bitcoin? This totally seems like the highest-value way to spend our time! Thanks, Bitcoin! I'm sure that the value of these items won't wildly vary in short spaces of time based on things like, oh, your propensity to have banking neophytes host your exchanges and end up shut down.
</sarcasm>
Sounds like an interesting headache for Jimmy's tax accountant! Income tax implications of getting donations in bitcoins, cashing them out and donating them to a tax exempt organization... might be complicated.
It's hard to credit that people are still pushing for the WMF to accept Bitcoin payments after the worlds major venue for trading them, the Magic: The Gathering Online Exchange, crashed and "disappeared" $500m. Obviously not a safe and secure payment modality right now, where is the rush to jump into something so risky?
On Mon, Mar 10, 2014 at 10:13 AM, Nathan nawrich@gmail.com wrote
It's hard to credit that people are still pushing for the WMF to accept Bitcoin payments after the worlds major venue for trading them, the Magic: The Gathering Online Exchange, crashed and "disappeared" $500m. Obviously not a safe and secure payment modality right now, where is the rush to jump into something so risky?
The risk her was trusting a centralized place with being an escrow for your money though, not Bitcoin itself.
On 15 March 2014 13:31, Daniel Zahn dzahn@wikimedia.org wrote:
On Mon, Mar 10, 2014 at 10:13 AM, Nathan nawrich@gmail.com wrote
It's hard to credit that people are still pushing for the WMF to accept Bitcoin payments after the worlds major venue for trading them, the Magic: The Gathering Online Exchange, crashed and "disappeared" $500m. Obviously not a safe and secure payment modality right now, where is the rush to jump into something so risky?
The risk her was trusting a centralized place with being an escrow for your money though, not Bitcoin itself.
Functionally, a currency is its social structures and how it flows - not just the objects deemed currency themselves. It's not money unless it flows, and Bitcoin flows through exchanges that range from laughably inept to criminal.
- d.
Charles Gregory, 10/03/2014 14:26:
On it he states "I'm planning to re-open the conversation with the Wikimedia Foundation Board of Directors at our next meeting (and before, by email) about whether Wikimedia should accept bitcoin." More info at the thread itself.
What's the board of directors?
Nemo
wikimedia-l@lists.wikimedia.org