Thanks Eric. This well-captures what we hope to do. Please drop me a message at [email protected] -- I'd love to talk about how our projects can work together.
The article's main concern is that "decline of religiosity has probably led to increased loneliness". The loneliness concern doesn't seem to resonate with the commenters here, so I dug in to the article's footnoted references.
The gist of the references is that loneliness is a problem for old adults, and religious community helps them. Intuitively, religious communities could probably help other groups at elevated risk of loneliness (the youth, the poorly educated, the depressed, etc.) even though I don't see studies showing that they do. The article's statement that "people are lonelier than ever before" is not supported by the references (except insofar as the population is aging, and the elderly are lonelier than the middle-aged). Footnote 11 suggests increasing social isolation across society but is, imo, not conclusive. Footnote 15 explicitly asks "Are we getting lonelier?" and finds the results inconclusive.
On the whole, it seems consistent to say "I'm not lonely right now, but I think that more diverse, intergenerational communities would be good for society."
It's a good question. We want Bitcoin acceptance to be straightforward for our users, so we deal with a failed confirmation on our side. We do not debit the user.
(I work at Stripe.) We love the PaymentProtocol, and we have an integration internally. Because the protocol is fairly new, we want to gauge demand from our users before exposing the extra infrastructure.
(Christian from Stripe here.) We credit USD to our user's account when we see a transaction that we believe will become confirmed. The time-delay between when the customer pushes the transaction and when we notify our users is typically less than 15 seconds and almost always less than 60 seconds.
(As an aside, Stripe prices bitcoin payments at 0.5% rather than 3%.)
I don't follow your description of Case 1. On Dec 18, to use the timing from your example, you have two options: (a) keep the $380 object (b) exchange it (via a refund) for $380 worth of bitcoin. These are the same options that you would have if Stripe was not in the picture: keep your funds outside of bitcoin or buy bitcoin at the market price. I don't see what benefit you derive from the refund API (beyond using it as a fairly priced bitcoin/USD exchange). Sorry if I am misreading the example!
If you were using your testmode keys, then we would not generate a valid bitcoin address (to avoid all kinds of confusion). It must be the case that these were your livemode keys. If you're able to reproduce an inaccurate "test mode" banner, can you send a bug report to [email protected]? You can cc me, [email protected]. I'm happy to take a look, but I haven't been able to reproduce on my side.
Thanks for the clear description. In Stripe's case, this arbitrage won't work. When we refund a bitcoin payment, we refund the USD value of the payment (converted to bitcoin at the time of the refund). The customer does not necessarily receive the same bitcoin amount that they sent.
For example:
(1) At the initial time, each bitcoin is worth 100 USD. A Stripe user accepts a 10 USD payment (0.1 bitcoin).
(2) Bitcoin then increase in value to 1,000 USD each. The Stripe user fully refunds the payment. Their customer receives 0.01 bitcoin (10 USD).
The Stripe user and their customer both have a net of zero USD in this scenario.
We could have implemented refunds in the opposite way: a net of zero BTC and non-zero USD. However, that would have introduced the issue that you describe.
Our users tend to want unified behavior across payments of all different types. Of course, it's possible to filter by payment type in the API, dashboard, and data exports.
To the original question: drop us a line at [email protected] if you want to talk more about not converting the payments. It's definitely something we'll support if there's user interest, but it's not something we do today.