Ya, that's unusually sparse considering the population level and tech-savviness. 

Consider checking in on this thread:

NH & Boston area Bitcoiners
 - http://bitcointalk.org/index.php?topic=104371.0

Interesting ... it is a bug in Chrome, apparently, fixed in Chrome v19.

 - http://code.google.com/p/chromium/issues/detail?id=113711


I'm on 18 but didn't just do any update.  Bizarre.

Here's a wiki article with some suggestions:
 
 - http://en.bitcoin.it/wiki/Securing_online_services

For some reason in Chrome the CSS is hozed, displaying a blue background.

I didn't notice it at first and it seemed like it all of a sudden started occurring after I had done some spam article deletions, but I can't see anything that I would have done that would have touched the CSS so it must have been a coincidence.

But there's a problem yet so I'm not sure how to proceed.

Sometimes people think this is a way to re-use the same blockchain, so just wanted to point out that this method will maintain the blockchain database in each datadir.

The simple scenario is where a hacker gains access to an individual's Dwolla account and transfers funds to the hacker's own Mt. Gox account.   If Mt. Gox has identify from verifying the account, then Dwolla would know who supposedly received the funds.   This also lessens the chance of a fraudulent claim that the transfer was not authorized.



I don't think it matters, at least not for deposits.  I can send my Dwolla funds to your Mt. Gox account I believe.   But with Dwolla being U.S. only, presumably only Mt. Gox accounts that are verified with a U.S. address then could receive Dwolla transfers.

But you can't withdraw your Mt. Gox USDs to my Dwolla I believe -- those two must be the same party, I believe.

So this verification cuts down on the permutations of risk to ones that are less exploitable.

They just got past their July backlog of orders and are now working on August's:

 - http://bitcointalk.org/index.php?topic=77796.msg1175468#msg1175468

BitFloor hasn't described many of the details regarding that security breach other than to say it was a "forgotten unencrypted backup".  So they may have had an adequately secured webserver with an inert wallet but were still left completely vulnerable due to poor security practices on a completely different system.

Until Bitcoin gains traction as money where it is recognized and accepted widely enough to function as a currency the recipient might instead still be better off with a money transfer or hawala even with exorbitant fees.   

That's why Bitcoin adoption needs to start catching on before the crisis. 

The way for that to happen is for there to emerge money changers who will act as the money transfer agent.  This is how M-PESA grew -- agents become M-PESA agents because they were earning commissions, sometimes better than they were earning from their other work.

These agents simply can work independently.   

So here's the scenario I envision. 

1.) An individual receives a text notifying that bitcoins were added to the mobile phone's (hosted) E-wallet.
2.) Individual coordinates with the Bitcoin agent to arrange a meeting time and place (.e.g, cybercafe, hotel lobby or other public place -- for safety) of both.
3.) Individual sends a text to spend bitcoins to the Bitcoin agent's address (e.g., "send 1.23 btc to 50922345678"  )   50922345678 being the Bitcoin agen'ts phone#
4.) Bitcoin agent hands over the cash

Coinapult can do this ... it works in the U.S. and Canada now. They were waiting on their text messaging backend (Twilio) to expand their global footprint I believe.

The problems with that are if this type of exchanged is not welcomed (and we know it likely is not) then SMS transactions are not secure (sent in clear text across mobile network.)   So at a minimum, the transfer from the individual to the Bitcoin agent should be not be traceable.  So I figure the send message basically just gives a PIN code that the individual then shows to the Bitcoin agent who then has a method to retrieve via SMS, using that PIN.

The next problem is where the individual Bitcoin agents then also need to convert the bitcoins that were received in order to restock the cash supply (and to unload the exchange rate risk exposure.  So either other Bitcoin agents nearby might trade with each other for a small fee and eventually a larger agent ends up with a number of coins and then either trades them with local investors or transacts such that the cash stock gets replenished in a timely manner.

So that's one idea as to how Bitcoin will emerge in these areas.   Basically anywhere there are tourists as well as tourists arriving might want to buy local currency with bitcoins and then sell their levftover fiat before leaving and get bitcoins for the trip back home.   These areas are hotels, B&Bs, cybercafe's,  dining establishments even.

If you are talking about a job that is performed entirely remote from the employer, such as a telecommuting position, there are still differences -- language, timezone, cultural differences, etc.   So there is not always going to be consistent pay regardless of location.

Currently the bulk of the hiring for this remote and telecommuting work is, as expected, from the wealthier nations which finds less expensive labor in poorer nations though only to those where there is a skilled workforce.   The reason a freelancer in a foreign country might be paid less than the employer's local hires isn't because of the exchange rate of the currency in that worker's country but because of supply and demand.  The employer looking for less expensive labor finds a much larger pool of willing and able potential employees when looking globally and thus supply and demand is what determines price.  

Paying in bitcoins doesn't really change anything with that.

But a significant reason the companies that are doing this remote hiring are able to do so is because of their access to capital.   If that capital too knows no borders, then there's a different dynamic.  Now it is a local employer in that foreign country that might be doing the hiring.  That's where you might see bitcoin becoming a game changer.  There can now be investment that, for the first time, becomes accessible to a team of these talented people who might want to form a company of their own.   They have, for the first time the ability to reach a market outside their own country thanks to their ability to get paid in bitcoins.  The arrival of these two options (to raise capital globally and the ability to sell their goods and services globally) will probably do much more for increasing wages for talent in these regions than does just making it easier to get paid as a remote teleworker.

Incidentally, here's a talk by Michael Levinson, VP of Product, oDesk, which has a lot of freelancers from developing nations.  He describes the challenges to (and importance of) paying those contract workers.  Notice that the bitcoin topic just keeps coming up over and over by those in the audience.  (Which is interesting, because this video is over a year old.)

 - http://vimeo.com/29287295

I've never gone through the Create a Security steps on GLBSE.  I'm presuming at the end of that process you were given that bitcoin address then? 

There is no way for anyone other than you to confirm that ... unless you were to ask Nefario to reply and confirm that here maybe?

While this is a neat experiment, the track recrord for GLBSE assets offered anonymous has not been good.

Can the warning in the OP regarding the bet with MNW be removed ... that's over.

Well, there is a configuration that leaves you very vulnerable to an attack vector.

Researchers were claiming to have reached near 100% confidence that a double spend can be performed.  

 - http://eprint.iacr.org/2012/248.pdf

Of course, they didn't follow the recommended actions ... configure your client to accept no incoming connections and for outgoing to explicitly connect to a well-connected node (or a node operated by a trustworthy party).  

Here are the various double spending attacks:

 - https://en.bitcoin.it/wiki/Double-spending#Race_attack

Blockchain.info likely only has outgoing connections but that doesn't mean that is the best method for a merchant to use for notifications as the attacker might receive a connection from Blockchain and through that connection relay simultaneously to Blockchain.info and to the various mining pools simultaneously.   You want to ensure with certainty that your node does not have a direct connection to or from the attacker.

I'm going to have to check out Multibit pretty soon.  Man, so many good things going on all at once!

I don't know Multibit yet to be able to answer if about what that client stores locally.  For traces, are you describing transaction residue (e.g., included in logs), or just the security of your private keys.?)

How about securing an escrow partner who will make the payment directly to GLBSE?

The Bitcoin-Qt client will look in the default directory unless it is started using the -datadir parameter.

The default directory:
 - http://en.bitcoin.it/wiki/Data_directory

Datadir parameter:

 - http://en.bitcoin.it/wiki/Running_Bitcoin#Command-line_arguments

Now, presumably you want just wallet.dat and not the blockchain and the rest in TrueCrypt.  For that you'll want to use a symlink for the wallet.dat

An example of this is in the Bitcoin wiki article on wallet security:

 - http://en.bitcoin.it/wiki/Securing_your_wallet#Mac

The Bitcoin-Qt client GUI doesn't have any support for that but bitcoind does.  On a Mac though, there is no bitcoind.  You could run Bitcoin-Qt in server mode ( $ bitcon-qt  -server ), and config file changes so that it could accept RPC commands but that's probably more than you want to do.

Mt. Gox makes it easy to redeem private keys.  Use the Funding tab.

Also Blockchain.info/wallet allows you to import private keys as wel.

 - http://Blockchain.info/wallet

Then you an send the funds to your wallet on your Mac.

Normally, the response would be a lecture about how MoneyPak can't easily be used for buying bitcoins.

There is an exception at this particular moment.


And that almost seems to be the solution, except:


So, ... that is about the only option you'll find today I suspect.

If they could get away with saying that Bitcoin eats babies and will likely result in the flipping of the earth's magnetic poles they would try that excuse instead.

Unfortunately for them, that would make them look silly so instead they latch onto the next closest thing that they can, which is the AML / KYC provision that financial institutions know their customer (as in how does the customer earn money, are these funds deposited by the customer earned in a legal manner, etc.)



Ok, now that is a different question.  That one is simple.  Banks have a hard time dealing with fraud.  They don't require that their customers all use two-factor authentication.  Hell, most of them let you reset your password through the e-mail, and they consider it secure because some even insist that you you know your dog's name (yes, the same name you just Tweeted about or commented on in your publicly available Facebook page.)

So rather than deal with the risk that fraudulent transfers will be routed through accounts of bitcoin exchanges, they would rather keep their heads stuck in the sand.  (Well, that isn't entirely true.  See most bank executives are just two more annual bonuses away from retiring, and if this whole bitcoin thing can just be put off for a while longer, the costs of imposing proper security won't be incurred until after those bonuses have been paid.  And since neither you nor I are allowed to open a bank to compete against them, they can continue to get away with the crap that they do, like not serving customers that are unprofitable.)