_Lemon_

I agree but what happens if someone posts under someone else's name?

It would probably be best not to perpetuate these things and to just end the vitriol now.

Does anyone know of any replacements?

I get zero chargebacks via Google and struggle to find anything that's comparable?

I've got the usual horror story behind PayPal (that cost a lot) and Stripe does not have adequate anti-fraud.

At the moment Amazon Payments seems to be a worthwhile competitor (they guarantee no chargebacks related to fraud) however their service is much harder to integrate. Although plenty of humans in the mix which is a very nice touch.

As a merchant, this is why Bitcoin is so valuable.

From my understanding is that it lets the customer's bank see exactly who's making the payment and gives them a chance to deny it. The merchant is then protected from fraudulent chargebacks and these are covered by the bank.

Essentially, they get to perform their own fraud prevention and it's a way of trying to improve confidence in online payments.

I believe the idea that it takes away rights from the customer is a misconception (I also think most of these protections are given by law).

From my understanding 3D secure would go a long way to help protect against chargebacks. Why not make it optional?

https://support.stripe.com/questions/does-stripe-support-3d-...

I heard years ago that Level 3 were trying to encourage people (non-customers?) not to use these DNS servers. I guess this is one way to ask people not to use them.

Having said that, 8.8.8.8, Google DNS, has been planted firmly in my memory as my go to "is this machine up?" IP.

As an alternative, I switched to Adblock Edge: https://addons.mozilla.org/en-us/firefox/addon/adblock-edge/

Yes I would, I'd probably jump back to them. I've just not had time to sit down this year!

Definitely a third party service. Then place the bumper sticker "No Bitcoins on our servers" somewhere :)

I integrated MtGox and BitPay. Compared to Google Checkout (XML mania) and PayPal (documentation drama) they take about 5 seconds to implement (test is another thing entirely).

I went with MtGox in the end since it was cheaper. I was then happy to offer a 3% discount to make up for the fees users got stung with purchasing BTC. However MtGox has a number of bugs that make it a show stopper for some customers.

If you ask the right questions they will acknowledge the bugs and tell you they are working on it and need plenty of time. I would probably not use MtGox if I had known about the bugs prior to integrating.

Earlier today I received a phone call from a number in Mountain View CA. It was Google letting me know in advance that Google Checkout was to be shut down (and asking to keep the call quiet). This was, to say the least, very surprising considering I have very little correspondence with Google Checkout and was actually thinking there was a huge problem with my account. Thankfully not but this is still bad news for myself and I presume the industry at large.

Google Checkout was very good with their fraud protection to the point that I did not have to think about it. In fact, over the years I have been growing my business Google have been my rock---never a real issue with them.

PayPal was a similar story but it also seemed to attract the sort of customer that would open a dispute at almost any issue (or just threaten it). You can also count me in one of their horror stories that indirectly cost me £5k and even got to the point where they just flat out refused refunds for my customers who wanted them.

I have a Stripe and GoCardless account as well and I've been trying to make it work but their fraud protection is just not up to scratch compared to Google and PayPal, which is a real shame. I'm not sure if I'll ever be able to see enough data to get quite the same fraud protection. Stripe do look fun though.

Another perspective from a merchant: roll on Bitcoin. With exchanges offering guaranteed payouts in another currency (for me, GBP) I take on zero risk by accepting it and it solves so many problems. There's no wonder more and more websites are starting to accept it.

This won't protect against OVH being compromised.

In the manager you can select the netboot / PXE option and "boot from rescue mode". From there you get e-mailed the logins from the server booted onto a Debian rescue image. You have full access to the OS / hard drives.

I personally feel this is a really minor problem (if that!)

I found my personal phone number appearing on customer bank statements as a Stripe merchant. That's a bigger deal than exposing an e-mail address, but it's still a minor issue.

Do you know how Google Checkout solves this? It explicitly states what's public information to buyers so I can make the decision of what I'm exposing.

This left me thinking "what are the signs of cancer"? Here are a couple of links after a quick search:

* http://www.cancer.org/cancer/cancerbasics/signs-and-symptoms... * http://www.macmillan.org.uk/Cancerinformation/Aboutcancer/Si...

Have you considered providing this data to merchants? For example, it would be great to know if you do get any calls for customers (or my prospective customers) and to see roughly what they're asking.

That way the merchants can act on the data too (and hopefully reduce the number of customer calls).

I laughed, but that's not true. It's the first payment option available: http://bitcoin2012.com/tickets

It's just done manually.

I was in a similar position with my ex -- although I think I used my start up as an escape putting more time into it than I would have otherwise. Then again, I could just have an addictive personality and it might not have made a blind bit of difference.

Either way, dwelling negatively on the past does not help as you cannot change it. I don't believe I would have come to the same conclusions if I had not experienced it first hand. Remember: work smarter, harder not longer!

No it does not, it's only when you ping their edge routers do you see packet loss, they still pass all traffic (and thus ping) over them just fine. You can see this in traceroutes or running mtr.

I believe (not 100% sure) they put their anti-dos on these routers which is why I think the US servers will have the same anti-dos measures.

Have you tried asking them? I do not believe they would hide this fact (it would be interesting to know whether they mark it as a selling point or not).

It probably won't change. Their US routers do not appear to be any different to the EU ones (e.g., they both intentionally rate limit ping to them so you'll see a lot of timeouts).

I have a response from OVH:

We are aware of this and are currently investigating it. Our initial thoughts were that it was indeed a compromise but after further review it seems that this is actually a bug with Debian and certain versions of RedHat.

We've tested it with different keys and have suffered the same results. I'll let you know if anything changes and we'll be announcing this shortly.

Thank you in any case, but rest assured it's not a serious issue.

That's the only reason you've found so far? That's pretty good.

They have much worse things in place:- their anti-dos measures make it near impossible to put anything of value on their without a LOT of work. For example, once they detect a DoS (just 50 Mbps was enough but it varies) they will take down your server (not just its IP) for 4-12 hours at a time.

With that said, there are some great things about OVH: they drive down the costs and make everything quite efficient (e.g., hardware prices, support costs) but then seem to just forget that they need to reduce the costs for the customer as well (their anti-dos measures being an example of how they increase the cost).

I just fired off an e-mail to OVH to see their response (and to probably make them more aware of this).

OVH pre-install a number of things by default on their Debian image including monitoring software (it integrates into their manager) and this key.

The only way to make sure things like this are a non-issue is to do a clean install yourself, e.g., via debootstrap in "rescue pro mode".

You can then install the key on their request if required giving you more control.

I have decided on wanting to use riak as well. I was wondering if anyone had examples of how they used it with their data model?

For example this article mentions "With appropriate logic (set unions, timestamps, etc) it is easy to resolve these conflicts" however timestamps are not an adequate way to do this due to distributed systems having partial ordering. The magicd may be serialising all requests to riak to mitigate this (essentially using the time reference of magicd) in which case they're losing out on the distributed nature of riak (magicd becomes a single point of failure / bottleneck).

Insight into how others have approached this would be awesome.

Redis can only perform asynchronous replication because it uses a single thread. It cannot block the main thread waiting for the network and have acceptable performance. This makes replication as good as "appendfsync no" as you have no guarantees as to what happened on the network write.

The upside of the design is that it makes things simple (e.g., transactions, append only file).

(This is my understanding, please correct me if I'm wrong!)

That's not quite what I'm trying to stay.

OP's expectation was that Linode should have unlimited liability where no guarantee on their part has been made. If you expect Linode to take on the risk then you would want (and probably need) that in writing.

Otherwise, you take on the risk: which would be true wherever you hosted it without any guarantees regardless of whether it's a VPS, dedicated server, or your basement.

If you put $12k of value on their service, why do they take on that risk? Why wouldn't the risk fall squarely on your shoulders?

Why would a hosting provider take on the liability of what you host on it? If the underlying filesystem had an error that Linode could avoid and you lost data, would you expect them to replace the value that was lost? Why is it not limited (at most) to the value of the VPS itself? (I can't imagine them compensating for hardware failure either).

OVH put brand new disks in every server sold.

They also do remarkably well: out of the thousands I've had from Leaseweb and OVH, OVH wins hands down.

Another good one (from someone who worked at Amazon) is Pat Helland's "Life beyond Distributed Transactions: an Apostate’s Opinion" which details more generally how a system might work without a global transactions. Part of which boils down to delivering idempotent messages to services.

I thought it was interesting because there are a lot of parallels with how REST works but also service orientated architectures.

The paper (and presentation) can be found here (which I'm sure has a few more gems on the page): http://www.cidrdb.org/cidr2007/program.html

> what do you think, are there gonna be sufficient incentives in the future to decentralize certain services?

You bring a very good point, one that I hadn't considered at all.

Although I'm not sure, I think the "work from at least 50% of honest nodes" is an issue. The more demand you have to create work for decentralised services, the more you split and weaken said services.

For example, if x is a major player with 33% of workin one decentralised system, they are more likely to have > 50% in smaller systems. So they would have power in smaller systems being able to usurp them at will.

One way around this would be to have a lot of players in each system, such that it would only be realistic to have a few % at a time (each). However, this again would most likely be undermined by any state actors who would ultimately be able to produce much more than anyone could if they wanted.

While it depends on the country, you don't have to be a bank to be regulated in the UK.

For example, the Financial Services Authority says you need to be registered for accepting deposits or issuing e-money: http://www.fsa.gov.uk/Pages/Doing/Do/index.shtml

I have no idea whether this is simply or cheap though...

   > If I convert dollars to bitcoins, I would be tempted to wait a couple of days and sell on mtgox and then buy the service with dollars.

Remove the "purchasing a service" element out of the equation and this still holds up -- the temptation to put money aside in bitcoins is still there.

As the service is a month-to-month thing, there's a limit on the amount of time you can wait if you did purchase by bitcoins. Also, if the price of bitcoins is going up, it's encouraging customers to pay earlier and earlier which is a good thing as most customers seem to wait until the last day (but server bills come up before then...).

Interesting read, which also says I'm doing most things wrong.

Original (kind of disingenuous to just copy / paste the whole thing with a link at the end): http://www.inspirationandchai.com/Regrets-of-the-Dying.html