Quite a few years ago, I led a migration off from a legacy logging provider that offered little more than full text search over unstructured text.
Logging at the time was somewhere in the ballpark of 1% of our total common infrastructure spend and widely acknowledged as too expensive relative to the minimal value we got from it with that rudimentary feature set, but it also was nowhere near enough cost to justify doing something about it. We had other observability costs that dwarfed it.
What finally justified the overhaul was that security couldn’t really operate usefully on log data unless we pulled the data out somewhere else like Athena and processed it there. That slowed down security incident response times dramatically.
The migration ultimately benefited the whole engineering organization but it had to be security led to get any traction.
There's also the committee factor. Google doesn't hire/no-hire based just on one person's opinion. If half your committee says, "90% of our engineers use his thing!" and the other half says, "But he can't code on a whiteboard!" then the committee is already kinda likely to take a pass due to lack of consensus. If there's any doubts at all on culture fit, which Google absolutely does care a great deal about, even more so. That said, when I was there, I interviewed someone who was essentially going to be my partner on something and everyone else (who weren't going to be working with this person) ranked the person poorly and I was the sole voice of (positive) dissent. I wasn't on the committee, so I don't know what their logic was, but the person was hired. And they were great. So it's not always even a majority opinion thing with the interviewers. In a nutshell, not only are we dealing with incomplete information here, we're dealing with VERY incomplete information.
I used 0.0005 BTC (~5kb), but you're absolutely right that a simple transaction is substantially cheaper. My assumption here is that as the economy grows, due to the underlying technology of Bitcoin, more BTC will need to be 'gathered' together in a wallet before being sent out. This results in a larger transaction size and a higher fee to exceed the priority threshold.
I suspect that in the future, this will be a fairly common case. I suppose I might liken the theory here to defragging a hard drive. An unused hard drive stays in a nice neat, contiguous state. But use it a whole bunch and things get messy. And in BTC's case, you have to pay a bit extra for the miners to come along and tidy everything up.
I could be totally wrong on whether that will ever become common, and the developers could just as easily reduce fees over time as well, but such is the nature of taking guesses at the future.
Fair enough. That said, I know of small businesses that are charged vastly larger %s going through a merchant account, etc (like nearly double what Square/Stripe charge) so I don't think the rate is entirely unfair. I'd rather aim for a median rate than 'lowest possible' for a table like this, but I haven't seen anybody post average rates that are anything but estimates and I am reluctant to publish a number in a table like that that I'd just pulled out of thin air. I believe median card-not-present rate is ~2.5%, but that's a thin air number.
Completely agree that my post is ignoring those things. The post is an extremely forward looking one. Bitcoin could crash and burn before anyone gets a chance to implement something like this. It could be replaced by a second generation cryptocurrency that doesn't have a public ledger. There's a lot of scenarios here where nobody ever gets to do what I was talking about.
I opted to focus entirely on the costs of transmitting the money. If we did a full analysis, we'd also have to look at chargebacks, figure out how to set a value on the speed of the transaction, and deal with the fact that sometimes Western Union just 'loses' your money and isn't sure where it is. Not all of these costs would be paid by the same person, but they do all add up to a systemic cost.
But that's not actually the primary point. There's plenty of reason to believe (besides transaction cost) that cryptocurrency and smart contracts have a long future ahead of them. I'm simply trying to point out that there are business models here that aren't yet being explored.
I used credit card transactions rates published by Stripe for the table. Square's pricing is pretty similar, though they don't have a '+ X cents' for non-manually entered transactions, which does make them a very good choice for buying a $3 coffee. Certainly Walmart is going to get better volume rates than anybody using Square or Stripe, but most people are not large retailers.
Bitcoin is actually regulated already, however the costs of Bitcoin regulation cannot be reflected in the protocol's transaction fee. An additional fee could be assessed by the service provider, but so far these fees typically happen right now at currency exchange points, rather than as a bonus 'sales tax'. BitPay has chosen to charge a flat rate monthly payment for their non-free plan while Coinbase charges 1% to cash out to USD.
Also I'm well aware of LevelUp. Point was not that other payment mediums cannot do the same but that Bitcoin can potentially provide valuable insight for a much larger set of transactions once you're able to make sense of a big enough chunk of the blockchain.
FWIW, Chris Dibona's record response time to a request I've made to open source a project was somewhere on the order of seconds. Maybe 10 seconds I think. It was like he had his finger hovering over the "Approve" button. Patent approval takes longer and does seem to push things into the 3-7 day range, but I once didn't get a response from them, and Chris basically just said, "Well, that's their problem. They were supposed to respond and they didn't, so you can go ahead and release." The open source team at Google is amazing and frankly, more companies should copy them. This stuff matters.
Logging at the time was somewhere in the ballpark of 1% of our total common infrastructure spend and widely acknowledged as too expensive relative to the minimal value we got from it with that rudimentary feature set, but it also was nowhere near enough cost to justify doing something about it. We had other observability costs that dwarfed it.
What finally justified the overhaul was that security couldn’t really operate usefully on log data unless we pulled the data out somewhere else like Athena and processed it there. That slowed down security incident response times dramatically.
The migration ultimately benefited the whole engineering organization but it had to be security led to get any traction.