I tell them I want to get paid X dollars in bitcoins, and they tell me how many bitcoins I should ask for and what address they should be sent to. Stripe then gives me the dollars I asked for (minus a small processing fee, of course).
How much is the fee? Is it a fixed amount or proportional to the transaction value? How does Stripe set the dollar denominated bitcoin price? One easy way to make a bitcoin payment look cheap is to offer a low fee but offer a slightly inflated exchange rate and take a profit out of the difference between the rate used for payment and the rate you can get in the market (exchanges or dealers). It's hard to compare the economic value of dollar denominated bitcoin payments (relative to credit cards) without knowing these details.
Will you be easing up on the "prohibited businesses"[0] restrictions for these Bitcoin transfers, since you aren't beholden to the credit card networks for these transactions? I've got a business that falls under category #2 that I'd like to use Stripe for but can't.
Hi Patrick. I think you should either give some guidelines, or ask for explicit suggestions about it. Great move, by the way. Happy to buy you a coffee and chat about it next time I see you in the Mission.
> How does Stripe set the dollar denominated bitcoin price? One easy way to make a bitcoin payment look cheap is to offer a low fee but offer a slightly inflated exchange rate
I just made a $5 payment, and the btc value matched the bitstamp exchange rate
If I were building it, I'd just match the price to whatever the prices were on the exchange I'm using, maybe with a small amount of padding to cover pessimal volatility.
@cperciva, slightly off-topic: I had a curious question this past week about one aspect of the scrypt algorithm. If I recall correctly, it sandwiches the memory hard function between PBKDF2, and uses Salsa20 as the mixing function internally. In the spirit of reducing code, I'm wondering if it makes sense to replace Salsa20 with HMAC, SHA256, or just SHA256's mixing function? It would reduce the number of crypto primitives in the implementation. Not that it really matters much, but just curious (and partially curious if Salsa20 had specific properties that are useful in scrypt's design). Sorry if this is a dumb question; I was going to read back through your scrypt paper, but have been busy all week.
Salsa20 could be replaced by almost anything -- the requirements for the mixing function are very very weak (basically just that there's no short-cut to iterating). But Salsa20 has an advantage in throughput, which matters for maximizing the amount of memory you can use in a given amount of time.
Asymptotically speaking the best function there is the one which maximizes [B/s software output]^2 / [B/s hardware output].
Thank you for reply. Then I suppose re-using the SHA2 primitive doesn't make much sense, except perhaps in awkwardly constrained environments (area starved ASIC/FPGA, embedded processor with accelerated SHA, etc). Regardless, it's interesting to know that the mixing function can be swapped around.
I believe they were planning to expand the number of countries they operate in. The US also has terrible credit card systems compared to any other developed nation.
They are, but it's to those twelve countries :) - eight of them are still in Beta.
The US also has terrible credit card systems compared to any other developed nation.
What do you mean? Aren't the CC systems pretty much the same everywhere? We do have some alternatives to the CC system as a whole, and they work fine, except when we want to sell internationally :|
It's strange that Stripe doesn't support paymentiframe.com's feature directly-- I'm sure many have similar concerns about embedding arbitrary JS into their domain.
It sounds like you might misunderstand which site cpercival is saying he upgraded, or maybe I misunderstood your response. From the paymentiframe.com site:
Who is the guy behind this?
Dr. Colin Percival — author of Tarsnap and FreeBSD Security Officer Emeritus.
I've been busy with bitcoin for the past few days -- I need to crunch some numbers on my AWS bills to see how much money this saves me; it's not as obvious as it sounds once GET/PUT costs and EC2 costs (which are mostly reserved instances, thus not affected by this price cut) are factored in.
But my first guess is that a price cut is very likely to be coming. ;-)
In addition to raising prices, please implement recurring payments as soon as reasonably practical.
This is what happens when one's pre-paid Tarsnap balance goes to zero:
You will be sent an email when your account balance falls below 7 days worth of storage costs warning you that you should probably add more money to your account soon. If your account balance falls below zero, you will lose access to Tarsnap, an email will be sent to inform you of this, and a 7 day countdown will start; if your account balance is still below zero after 7 days, it will be deleted along with the data you have stored.
I was N days from hitting a the 7 day warning, so 14+N days away from hitting "Lose all my business' backups for the last several years." It is possible that I would have gotten really lucky and seen those emails (which I was, by definition, not particularly expecting) rather than, oh, being on a business trip in April and finding about them after the fact.
I cannot put enough underlines under I Would Consider Losing All My Backups A Failure Mode.
This is something that's repeated here, but I have a feeling mostly by folks that are backing up small amounts of mostly static data.
Even after de-duplication and compression, my company stores about 400 GB of data with Tarsnap. Tarsnap is a double digit percentage of our monthly infrastructure costs.
I think, perhaps, it's rather that the value that a business backing up a 30 MB database every day gets isn't radically different from the value that we get backing up several orders of magnitude more than that.
The question really is if straight utility pricing makes sense. I could imagine that a floor on the pricing, or a non-linear curve would probably do better than simply keeping the same model and raising the prices. There's also a question of distribution of total revenue -- if the revenue for the small accounts was increased by 10x, would it balance out a 50% loss of large accounts?
There's also a question of distribution of total revenue -- if the revenue for the small accounts was increased by 10x, would it balance out a 50% loss of large accounts?
No. You wouldn't be far off if you assumed that 100% of Tarsnap's revenue came from large accounts.
> The question really is if straight utility pricing makes sense. I could imagine that a floor on the pricing, or a non-linear curve would probably do better than simply keeping the same model and raising the prices.
The question is if the costs of running tarsnap correlate exactly with the amount of data that is stored, or if the number of users also have to be factored into the equation, ie. if each additional user has an added cost. I would say that in a business like this, with a low barrier to entry, the price should reflect the costs as close as possible. So if there's a constant setup cost for each user, the price shouldn't be $X/GB, but $X/GB + $Y.
Ideally, Tarsnap should make the same amount of money from a single user storing 100 TB and 100×10^12 users store a single byte. If this is not the case, the pricing structure is suboptimal.
Agreed! I use a lot of Saas services and tarsnap is insanely cheap for the value it provides.
While I'm at it, a feature I would love to see in tarsnap is server side pruning of old archives so I can remove the delete permissions from my production keys and not have to setup a secondary pruning server.
This is my question too. Tarsnap is cool, and Colin deserves to get paid for his hard work, but the cost differential is far too much for me to use tarsnap right now. If they cut their costs in half, I'd be able to afford to use them over raw S3.
This is great news. One quick suggestion: I recommend dropping the material on Bitcoin's unsuitability as a store of value or unit of account, or at least softening the language to sound less certain. It's possible that these views, which are shared by most mainstream economists, will prove to be true, but Bitcoin's design is a test of the contrary position. It seems reasonable to concede that there's some uncertainty in the matter.
I'm disappointed that the parent comment, which offers constructive criticism, has been downvoted at least five times (though, to be fair, upvoted at least twice). Please don't downvote comments just because you disagree with them.
In the context of the OP, I felt that several opinions about Bitcoin were expressed as fact, but I appreciate cperciva's polite replies and have upvoted them accordingly. This is because I believe that all polite and constructive comments (even when critical) deserve to be upvoted, or at least not downvoted. I hope in future other HN readers will extend me the same courtesy.
I wonder how Stripe is going to handle the tax implications of Bitcoins. It may not have an impact because they shouldn't be holding them, but it could be complicated.
The IRS just ruled that Bitcoins are property, not currency, and are subject to capital gains taxes when they are spent. IOW, you have to keep track of your basis every time you buy and spend Bitcoins, just like stock.
How much is the fee? Is it a fixed amount or proportional to the transaction value? How does Stripe set the dollar denominated bitcoin price? One easy way to make a bitcoin payment look cheap is to offer a low fee but offer a slightly inflated exchange rate and take a profit out of the difference between the rate used for payment and the rate you can get in the market (exchanges or dealers). It's hard to compare the economic value of dollar denominated bitcoin payments (relative to credit cards) without knowing these details.