Wet White Sands

The sand was wet. Our sand disc had trouble gliding across the sands and instead broke in half.

At the border checkpoint, I was enthusiastic in proving my eligibility to cross the area and offered my ID card in hand. The border crossing guard was not interested in checking it. Power move indeed.

Alcohol may prevent amphetamine action by impairing central insulin signaling

Alcohol may prevent amphetamine action by impairing central insulin signaling.

These alterations produced by alcohol cause severe hepatic and central nervous system insulin resistance as the cells fail to adequately transmit signals downstream through Erk/mitogen-activated protein kinase (MAPK), which is needed for DNA synthesis and liver regeneration, and phosphatidylinositol 3-kinase (PI3K), which promotes growth, survival, cell motility, glucose utilization, plasticity, and energy metabolism


Because insulin and PI3K signaling have been shown to fine-tune DAT cell surface expression (Garcia et al., 2005; Wei et al., 2007), it is possible that inhibition of PI3K signaling in vivo, by reducing DAT cell surface expression, inhibits AMPH-induced DA efflux. Selective inhibition of PI3K via LY294002 results in a dramatic reduction in AMPH's ability to elicit DAT-mediated DA efflux in heterologous cells, dopaminergic neurons, and in vivo within the striatum of rats as measured by both in vivo voltammetry and fMRI (Lute et al., 2008; Williams et al., 2007).


Caffeine competitively inhibits amphetamine action?

Caffeine-amphetamine interactions were studied to determine whether attenuation of amphetamine-induced activity by caffeine pretreatment (30 mg/kg) is the result of increased or decreased sensitivity to amphetamine. Caffeine pretreatment attenuated amphetamine activity in the rats without producing a horizontal shift in the dose-response curve. Results support a reduction in sensitivity to amphetamine. A cross-tolerance design revealed an asymmetrical interaction between caffeine and amphetamine. Multiple caffeine treatments (30 mg/kg) produced tolerance and attenuation of subsequent amphetamine activity (1.5 mg/kg). Amphetamine did not produce tolerance or affect subsequent caffeine-induced activity.

Caffeine + Amphetamine is more neurotoxic than Amphetamine alone, but not through adenosine receptor antagonism

To investigate mechanisms, additional animals were pretreated with the adenosine agonist, 2-chloroadenosine (2.5 and 10 mg/kg), before being challenged with NS, 90 mg/kg cocaine, or 42 mg/kg amphetamine. Pretreatment with 2-chloroadenosine had no affect in reducing cocaine or amphetamine toxicity. Combination pretreatment with caffeine and 2-chloroadenosine potentiated cocaine toxicity. The phosphodiesterase inhibitor, pentoxifylline, did not potentiate cocaine toxicity. The authors conclude that caffeine potentiates the acute toxicity of both cocaine and amphetamine, and that the failure of 2-chloroadenosine to alter this suggests that the toxicity of the stimulants cocaine and amphetamine may be modulated by nonspecific rather than specific adenosine- or phosphodiesterase-induced mechanisms.


It may be difficult for amphetamine to be significantly more neurotoxic in presence of other psychoactive substances or unfavorable states where the latters are not significantly adverse alone. Higher mental functioning is progressed to be efficient in the human state and additional efficiencies are expensive to achieve, and therefore adverse scenarios require exceptional conditions. Amphetamines may be illusionary in cognitive benefit that is not derived from increasing arousal.

Coinbase can send Bitcoins from your wallet without your permission

I wrote this circa 2014. Since then, a lot of things have changed, and a lot have stayed the same in the Bitcoin community. I forgot to publish this, but am doing so now to reflect on changes.


Yes, Coinbase can send Bitcoins from your wallet without your permission.

Last week, Coinbase announced a promotion where new Coinbase accounts registered with a .edu address would receive $10 worth of Bitcoins for free.

My friend John (named as so for the purpose of this post) and I realized that not everyone we knew were going to be interested with Bitcoin. We came up offering $5 upfront for the Bitcoins each person received if they signed up for a Coinbase account.

John was able to get 18 interested individuals in sending him their account balances, coming up to a total of .47005 Bitcoins. I however had a less impressive amount.

Later, John received an email notification from Coinbase that someone had emptied his wallet balance.

That someone was Coinbase. Make no mistake that Coinbase in all intents and purposes is not a traditional wallet. They will "spend" your coins if it suits their interests, as is seen here.

Keep all of this in mind when we head towards increased adoption of Bitcoin.

Mojang threatens lawyers against pay-to-win Minecraft server operators

Oh Grum, why did you choose to serve these fans such unfortunate news?

So if you haven't been following the Minecraft drama in the past few hours (or days), you might be interested to know that Mojang is currently in the works to shut down Minecraft servers that give perks to players who pay, whether these be donations or not. Players and server operators are not happy.

As far as I currently know, and as the situation currently develops, Erik Broes (@_grum) on behalf of Mojang chatted up with server operators, namely MCPVP, Hypixel, and other ops to verbally serve them a cease and desist on their operations. I've been able to grab up a few snippets from Skype logs and from my friends [1].

Erik Broes: doesn't matter at all, based on plugins or not, you cannot make money with Minecraft without our permission :)
Erik Broes: running servers is *NOT* A BUSINESS*

Even threatening the presence of lawyers.

Erik Broes: We'll ask nicely and then send really mean lawyers :)

It doesn't take a Bitcoin sheep to understand that Mojang is trying to rid of the community that currently surrounds paid servers. The community which currently surrounds pay-to-win servers is no small speck.

Erik Broes: It just made me sad someone spent $1200 on a server, he could have given 44 kids a copy of minecraft rather than paying again for pixels he already owned

While spending $1,200 on a server is odd in the grand scheme of things to begin with, it isn't unheard of in the gaming world. Often, you don't find individuals who spend several thousand on a hobby, such as rocketry or rc airplanes peculiar. But that's just what Minecraft is, a hobby. One serves an individual's satisfaction; the other is straight up charity.

When was the last time you donated $1,200 to charity?

Unforeseen consequences

While it is purely of Mojang's right to enforce their policies on their intellectual property, many players believe that this will have disastrous effects for the community.

A significant player base of Minecraft revolves around large servers (500+ slots) that take huge amounts of resources to run. Server costs, custom development work on plugins reach in the several thousands of $ a month to maintain a server of this size. Each is like an individual startup. Hundreds of servers of this size exist as to date.

Servers of this size usually operate on the model that users pay for game perks or in-game cosmetic items to receive appearance benefits. Models like these generally work well enough to support costs and provide a working salary for those who work full-time on the servers [2].

The issue is that Mojang is officially on the stance that server operators can only receive donations, and that no incentive for these donations/benefits can be given.

Eric Broes: donations are no problem, but only in that purest sense, you get *NOTHING* back for a donation

Pure donations at the current time are an unsustainable solution for servers of these size. With nothing to be given in return, many users are given no incentive to donate. Similar to the events of a deflationary spiral, the majority of servers whose cost to maintain is higher than that of a vanilla server will inevitably shutdown.

Development for multiplayer servers will have to rely on the goodness of developers to provide something other than the Vanilla servers that often many players get tired with.

In the EULA, planned beforehand

It's interesting that this clause has been in the the EULA (end user license agreement) since at least last December, however it had never been enforced until now. It is likely that Mojang had been waiting to make this move for a while, but did not have the nerve to do so.

Updated: 11 December 2013 15:22



So the one major rule is that (unless we specifically agree it – such as in brand and asset usage guidelines) you must not:

  • give copies of our Game to anyone else;
  • make commercial use of anything we‘ve made;
  • try to make money from anything we‘ve made; or
  • let other people get access to anything we‘ve made in a way that is unfair or unreasonable.

Hidden agenda?

Currently it's very prominent that Mojang makes money off of Minecraft primarily through game purchases and merchandise licensing. It seems that this isn't enough. Mojang might be beginning to fancy the potential for "pay-to-win" servers, and is tightening down control of the current Minecraft ecosystem. However, much like Twitter has done in the past, it doesn't seem that voicing any complaints will help.

Edit: One plausible theory proposed by altcognito on Hacker News is that Minecraft is trying to funnel users to their "rent-a-server model" business, Realms. Personally, this seems much more likely.

Earlier today, there was a change.org petition against Mojang to modify the EULA in users' favor. It has since been removed.

Mojang is making a dangerous play, one that may cripple the flourishing community indefinitely. It will be interesting how this plays out in the next couple of days.
[1]: The various logs I've collected can be seen here and here. More are on Skype, however it serves as an inconvenience to get them.

[2]: As a personal example, my friend (who will be unnamed) partially contracts his time out for $1-2k a month for his plugin development work.

Namecheap's sneaky WhoisGuard renewal shenanigans

I was hit with a $48.96 debit on my Namecheap account balance yesterday for 17 WhoisGuard renewals.

Most of the domains that the WhoisGuard subscriptions were protecting were set to expire, and so each domain's auto-renew was turned off. Yet I was still charged.

Feeling outraged, I contacted their support trying to get the charges back credited to my account - that money would be better spent on domain renewals on some 40 pointless domains than on WHOIS privacy nonsense.

Namecheap's support great as always, granted me a one-time exception to their all-sales final policy. The support representative spent some 20 minutes on what seemed like deleting and refunding each WhoisGuard subscription individually.

It turns out that all WhoisGuard subscriptions are regarded as their own entity, and are not affected by the state of the domain (if any) it is protecting.

I turned off auto-renew on the rest of my domains, but it was painful. I couldn't help but feel that Namecheap had an agenda out to milk money out of their WhoisGuard customers.

No method to manage WhoisGuard subscriptions all at once

Unlike domains, there was no real way to manage the rest of the 23 WhoisGuard subscriptions I had left without clicking on each subscription individually.

Namecheap's site is awfully slow most of the time. Turning off auto-renewal for your WhoisGuard subscriptions is a 40 minute task.

WhoisGuard auto-renew is enabled by default

Great! Just what I needed.

Bitstamp was hacked 2 weeks ago, and only now users are finding out

Bitstamp, the current largest Bitcoin exchange in volume, tweeted yesterday that their customers should be careful with phishing emails sent to them impersonating Bitstamp.

This is really concerning. How did these attackers gain access to the email addresses of Bitstamp's customers?

I remembered that I stumbled upon a /r/bitcoin thread a few days ago from a user that warned users of suspicious emails from Bitstamp. He was wondering how the attackers were able to acquire his email, since he had given Bitstamp an address unique to them (e.g. bitstamp1823@ttian.com).

In the thread, eleuthria [1] confirmed that Bitstamp's support had been somehow compromised through his experiences with support.

Bitstamp's email list was confirmed stolen ~2 weeks ago, when a boatload of emails claiming to be from support@btcguild.com (but not sent from any of the BTC Guild mail servers) went out talking about a 3.201 bitcoin transfer. After replying to the people shouting at me for being a scammer, I was eventually able to narrow the source of the leak to Bitstamp at the very least, and likely a few other sources on top of it.

I informed Bitstamp that they had at least a breach on their email list, if not the rest of their system. At first they denied it, but in a follow up they eventually admitted to it.

They then sent out a little security update email mentioning 2FA/password security.

It's already been 2 weeks, and Bitstamp hasn't given any transparency into this issue. It sure feels like they're pulling off a Linode, and trying to sweep this under the rug.

Bitstamp, you're now the replacement to MtGox. Don't screw this up.

[1]: If you don't know eleuthria, he operates BTC Guild, one of the first and largest Bitcoin mining pools.

Bitstamp has a broken matching engine

At approximately 18:25 UTC, Bitstamp's trading engine reported a matched market order approximately 7% below the highest bid.

In an optimal matching scenario ~4,000 Bitcoins were needed to strike the price of 633.64. However, the volume at  5 minute interval was only 89.27 Bitcoins.

Something is seriously wrong with Bitstamp's matching engine, and apparently it's not the first observation by the community.

Edit: /r/bitcoinmarkets also reported this issue.

Bitcoin service StrongCoin hacks their users to recover stolen funds

The following was imported from my old blog.

Earlier this week, Ozcoin, a popular Bitcoin pool, had their payout script hacked, leaving them in the negatives of ~900 Bitcoins (~$132,000 USD). Today, the operator of StrongCoin, a online Bitcoin wallet, notified the Bitcoin community that he had intercepted the pool's coins from the attacker using their service, and sent them back to Graet [1].

Public Disclosure.

On Saturday afternoon I was notified that Strongcoin was holding 568 BTC believed to be from the Ozcoin theft. Everytime you make a payment from StrongCoin the fee goes to 1STRonGxnFTeJiA7pgyneKknR29AwBM77 so any payments from strongcoin held accounts are easily traced back to the site

I was asked by 2 separate people on this forum if I could hold the funds (Sorry to the people I didn't reply to). The evidence that these funds came from the heist seemed plausible to me.

At 8am yesterday morning the funds were intercepted when the user made a payment. 


I've spoken to the user in question over email. The user says he sold a car for BTC but can't reveal who to due to an NDA agreement. 

Graeme and I had a conversation over the phone and some evidence came to light, that to me, made it very likely the user I have contact with was connected to the heist. I'm not going to reveal any details of the user accept to legal authorities if asked. I believe we should abide by due process.

I have sent a link to this post to the user so he/she can comment. Otherwise in the next few hours I will return the funds to Graeme, he can then decide what happens to those funds.

While this may appear to be a seemingly nice gesture, there are all sorts of wrong in this in incident. Lets look a bit closer on what StrongCoin is.


StrongCoin boasts that their service "only hold encrypted private keys", and that "neither [they] nor anyone else can spend your Bitcoins". Not only that, they also claim that Bitcoin private keys are "encrypted in your browser before it reaches [their] servers". How were they able to intercept the coins?

This leads to two inconvenient possibilites, neither which make StrongCoin appealing.
  1. Private keys were not actually encrypted on the client side, and were actually stored plain-text on their servers.
  2. They served malicious Javascript on the attacker's session, and stole the attacker's wallet's respective private keys.
They served malicious Javascript on the attacker's session, and stole the attacker's wallet's respective private keys.

Whether it be one or the other, neither make StrongCoin's decision right. They hacked their service to steal from a user, and probably for personal gain too. They have shown that they could, and would steal from their users at their discretion. None of their advertised security features protected anyone in this case. They lied to all current and potential customers.

Even if the operator of StrongCoin has a heart for the Bitcoin community, who is to say that the owner of StrongCoin would not take advantage of his position in a personal emergency? Or if StrongCoin decided to serve "justice" to one who has been wrongly tagged by the community? It's apparent that StrongCoin really should not have been involved in this incident, or let it any of their customer's transactions be any of their business. They voluntarily revealed that their service is just as useless as a shared wallet.

MyWallet, also an online wallet, by Blockchain.info also had similar case in 2012. In late last year, Roger Ver abused his "admin" privileges at MyWallet to expose personal information of a customer he had a dispute against from his business, which was completely unassociated with Blockchain.info. He gained these admin privileges initially from Ben Reeves, Blockchain.info's owner, to provide additional customer support to MyWallet's users, however, he used his abilities not what they were intended for. Roger Ver was able to look up accounts according to the addresses associated with them. From there, more information could be gathered looking up individual accounts.

Unlike StrongCoin, little damage was done in the aftermath. Ben Reeves decided that it was best he did not intervene with a dispute that was none of his business, and unlike StrongCoin's realm of wrong decisions, he also revoked Ver's administrative privileges. Better yet, MyWallet no longer has the ability to directly link addresses to accounts. There was no indication that Blockchain.info was even remotely interested in playing Bitcoin judge, like StrongCoin did in this incident.

It seems StrongCoin has better interests in playing world cop in the Bitcoin community than providing a secure service to the best of their abilities. Use StrongCoin at your own peril.

The bigger problem

Of these two incidents, there's a bigger problem that comes from the use of web wallets: they require arbitrary code to be executed from a potentially untrusted source. From a typical end user, there's no telling what, or how the wallet "encrypting" your private keys.

This is also the argument against web applications implementing client-side Javascript encryption. While it may appear client-side encrypted data negates the requirement to trust the provider with your data, it's important to note that the code to provide this added data security is also provided by the same source. Malicious Javascript can be served through hackings or forced government intervention, rendering the extra security useless.

An interesting way Blockchain.info mitigates the risk is by providing browser extensions which verify the code being served against their open-source GitHub repository which houses MyWallet's core client code. Attackers don't have access to the repository, providing a line of security. Another alternative provided is the full-featured Chrome application. The app's client code can't update without the user manually taking action. This is all great, that is, if you trust the people behind Blockchain.info.

This incident, while grave, also serves as a beneficial lesson to the community. Bitcoin, by design, removes the requirement of trust. When you do trust, and rely on someone for convenience or whatever reason, incidents such as this can and will happen.

Thanks to gmaxwell for digging up the following quote:
Then strong encryption became available to the masses, and trust was no longer required. Data could be secured in a way that was physically impossible for others to access, no matter for what reason, no matter how good the excuse, no matter what.

- Satoshi

[1]: Ozcoin's pool operator