2012-12-19 archive.org - My adventure in donating bitcoins to the Internet Archi

[julz]

Fascinating to see the damage MtGox is doing themselves by the way they communicate(or rather - fail to) their AML procedures.

My adventure in donating bitcoins to the Internet Archive
A Bitcoin Adventure in Four Parts

Brewster Kahle (digital librarian)
2012-12-19

http://blog.archive.org/2012/12/19/i-donated-bitcoins-to-the-internet-archive/

...
Last year, we received a few thousand dollars in bitcoin contributions. So far this year, Internet Archive supporters have donated 186 bitcoins worth U.S. $2,400 at the current exchange rate.
...

Surprisingly the author still maintains an upbeat tone after this rigmarole... Ah well, we all know there is a fair way to go in terms of convenience/usability.

[marcus_of_augustus]

Agreed, Mt. Gox is a big FU in many ways ... let's not revisit that. He should have gone localbitcoins.com (or similar) for the "full" off-the-grid bitcoin experience.

I found this comment interesting for its insight into psychology of a noob ...

I am rather proud of succeeding and now kind-of like the adventure.   I feel like I am a member of a club

and in a way he is correct. He has joined a club, of people that are technically competent enough to set themselves up as their own banks.

Lets see if he can hang onto his monies ... 

[Stephen Gornick]

Posted in another thread:

"Hey, in Japan they only have JPY, and my local intermediary in Japan can process this wire as a domestic transfer for only USD 10. Let's convert the amount to JPY, and take 3000 JPY fee for the whole process!"

That must be what happened here:

I asked my big bank to wire a hundred dollars to the bank MtGox suggested which is in Japan. Well, my bank cannot send dollars to Japan, only yen. And since I requested dollars, they had first transfer the money to JPMorgan, a bank that can transfer dollars.

 - http://blog.archive.org/2012/12/19/i-donated-bitcoins-to-the-internet-archive/

What "big bank" cannot send an International bank wire transfer in USDs?

[Raoul Duke]

This is a smart man. At least he learnt something with it:

My lesson: avoid MtGox.

[caveden]

The "part 2" problem could be "solved" if bitcoin.org did not link directly to bitcoin-qt.

Before downloading bitcoin-qt, everybody should be exposed to the fact that it will download the entire transaction history, and index it locally, what's a very costly operation. People should be prevented that, if they want to avoid that, they can download a lightweight client like MultiBit or Electrum.

What I mean is that I think the direct links on bitcoin.org should be removed and everybody should have to pass through this page (or an equivalent) before downloading anything.

[Mike Hearn]

This is a smart man. At least he learnt something with it:

My lesson: avoid MtGox.

Er, no, that's not the lesson. The lesson is if you deal with financial institutions you have to ID verify. Also - US banks suck.

The reason Mt Gox is doing this isn't just AML/KYC, it's also to handle phished bank accounts that try to cash out via Bitcoin. This is a much bigger deal for inbound wires from US banks because US banking security is piss poor and fraudulent wire transfers are a bigger problem there. We have seen multiple times what happens if that isn't done - the exchange accounts get blacklisted by the banks and they'll refuse to process wires to them (see: InterSango), which is an even bigger fail than requiring ID verification.

When I have interacted with Mt Gox I didn't have any of these problems because

a) UBS has good security around wire transfers (you sign the destination IBAN with a dedicated hardware device)
b) UBS knows how to wire money to other countries without doing currency exchange in the process

ie, my bank does not suck. Neither of these things are exactly rocket science, but many US banks can't handle it.

So while the blog post is painful to read, I'm glad Mt Gox has these policies in place. The problems he's having with wiring money to Mt Gox are problems he'd have with any form of online currency exchange, it's not unique to Bitcoin.

The issue with which client to recommend is of course well discussed already. The sad fact is there are no "good" clients right now that tick every box we might wish to have (security, performance, privacy, decentralization, etc). It will get resolved with time.

[caveden]

The sad fact is there are no "good" clients right now that tick every box we might wish to have (security, performance, privacy, decentralization, etc). It will get resolved with time.

BitcoinJ with its SVP model certainly ticks performance, privacy and decentralization boxes, at least when compared to alternatives. The only box you mention where some doubt could remain is "security"... since you're the lead developer of BitcoinJ, I must say this last comment of yours sounded suspicious... you don't trust BitcoinJ's security?

[Mike Hearn]

bitcoinj doesn't currently support encrypted wallets. It's being worked on by Jim but isn't there yet. Also it has a few important missing features in other areas - for instance, no compressed pubkeys and a missing fee calculation algorithm.

I'm hopeful that we can get bcj to the point where I'll be unconditionally recommending it for end users some time by EOQ1.

[marcus_of_augustus]

The "part 2" problem could be "solved" if bitcoin.org did not link directly to bitcoin-qt.

Before downloading bitcoin-qt, everybody should be exposed to the fact that it will download the entire transaction history, and index it locally, what's a very costly operation. People should be prevented that, if they want to avoid that, they can download a lightweight client like MultiBit or Electrum.

What I mean is that I think the direct links on bitcoin.org should be removed and everybody should have to pass through this page (or an equivalent) before downloading anything.

Hadn't noticed that welcome addition to the bitcoin.org site .... note those are all GUI clients ... why is bitcoind CLI client not listed there I wonder?

[caveden]

bitcoinj doesn't currently support encrypted wallets. It's being worked on by Jim but isn't there yet.

Meh, wallet encryption is purposeless against trojans, the only protection it may offer is against an attacker with physical access to your computer, like a dishonest roommate or something. And if you use ubuntu, your home dir may be encrypted natively, so wallet encryption becomes more of a placebo feature than anything.

I'm hopeful that we can get bcj to the point where I'll be unconditionally recommending it for end users some time by EOQ1.

Nice.

[Mike Hearn]

Meh, wallet encryption is purposeless against trojans, the only protection it may offer is against an attacker with physical access to your computer, like a dishonest roommate or something. And if you use ubuntu, your home dir may be encrypted natively, so wallet encryption becomes more of a placebo feature than anything.

Well, security is about raising the bar. If you assume all attackers have infinite skill and time then yes, it's purposeless. In practice the perfect crime is quite rare.

Encryption at rest is good enough to change wallet stealing from "read a file at a well known path and post it to a web server" to "install and run a background app that the user won't notice, and which can inject itself into the Bitcoin process, find the encryption handling code and then intercept the passphrase, and then hope the user unlocks their wallet before the virus is discovered and added to AV signature lists" ... which is a much harder programming problem. Novices can tackle the first. The latter needs more experienced people. Those people are, in turn, more likely to have well paying jobs in the white market that aren't worth risking for an uncertain payoff and possible jail time.

Real two-factor coins are even better of course. That's why Gavin is pursuing it as one of his main goals. The payment protocol work is an important first step.

[prezbo]

The "part 2" problem could be "solved" if bitcoin.org did not link directly to bitcoin-qt.

Before downloading bitcoin-qt, everybody should be exposed to the fact that it will download the entire transaction history, and index it locally, what's a very costly operation. People should be prevented that, if they want to avoid that, they can download a lightweight client like MultiBit or Electrum.

What I mean is that I think the direct links on bitcoin.org should be removed and everybody should have to pass through this page (or an equivalent) before downloading anything.

I'm pretty sure most people don't even see the clients link on the page, since the links for bitcoin-qt downloads are so obvious (I recently met a guy that had a good understanding of bitcoin but had no idea clients apart from bitcoin-qt even existed). Just replacing those with the link to the clients page would help a lot, I think. Judging by how many threads there are in the newbie section about users not understanding blockchain sync, I think this is long overdue. And honestly, bitcoin-qt should probably not be the clients bitcoin newcomers should be using.

[caveden]

Encryption at rest is good enough to change wallet stealing from "read a file at a well known path and post it to a web server" to "install and run a background app that the user won't notice, and which can inject itself into the Bitcoin process, find the encryption handling code and then intercept the passphrase, and then hope the user unlocks their wallet before the virus is discovered and added to AV signature lists"

It doesn't need to be that complex... the virus could just send the encrypted file to the attacker, patiently waits for the user to start his client and from this point on log everything the user types and send it to the attacker. The attacker could manually look for the password, it shouldn't be that hard I guess.

But anyway, yes, it adds complexity.