Sorry for Necrothread, but this is the most appropriate.

I no longer see any BTC/CAD trading, but I do still see BTC/INR.

Is that market still trading?

(i.e., can a person sell BTCs to buyers, and then withdraw as a bank transfer?)

Also, new look for Bitcoin-Central. 

But now isn't when Bitcoin needs a familiar monetary unit.  That was needed more back when a bitcoin was worth less than a penny, or maybe five cents, or fifty cents even.

If the BTC/USD back then was 1 BTC equals 0.005 USD, then maybe it might not have been acceptable just as Bitcoin started to get publicity in tech circles.

At least when it did, it was simple numbers for people to understand.  1 BTC = $1-ish. (Feb 2011)    The months that followed saw bitcoin awareness grow very fast.

But in your client change units from BTC to mBTC, and you are right back to wbere one unit (of mBTC) reflects about a U.S. penny.

So, we start getting used to the term milibits.

You seem to be disappointed by this.

This must be a well-paying scam, ...

It started out as  EaszPay.com, til that got shut down.
Then it was MtGax.com til that got shut down.
Then MtGix.com ... for several weeks, but now shut down.

And ... the latest incarnation:

 - http://i4dollars.com

The PayPal account has changed though, and now the scammer is receiving payment through: pay.techo@live.com

Ok, try this.  Copy the bitcoin.conf to bitcoin.conf.tmp
then rename the bitcoin.conf to bitcoin.conf.sav
and then rename bitcoin.conf.tmp to bitcoin.conf

Then try to launch as server and see what happens.

I'm seeing the event referred to as "Halving Day".

What sucks is that the specific day isn't known ... and likely won't even be known with any degree of certainty of +/- 24 hours accuracy until maybe within a week of it happening.

You'll need to PM Theymos:

 - http://bitcointalk.org/index.php?action=profile;u=35

Here's a related thread on speculation as to the date.  But it looks to be more November than December:

 - http://bitcointalk.org/index.php?topic=67185.0
 - http://www.BitcoinClock.com



What happens is people see things like "Oil supply drop following hurricane/mideast tension/undersea drilling catastrophe/whatever" and remember that after that happens the price of oil jumps 20% so they think that the same type of cause-and-effect is going to occur with Bitcoin.  

The big difference is that hurricane, or middle east issue or whatever wasn't expected, and the prices had to quickly adjust to the new reality.

This upcoming block reward drop is already known.  It was known back on January 3rd, 2009 (when the genesis block was created).    Sure, the exact date wasn't known ...., it was initially targeted to not occur until January 3rd, 2013 but faster mining has pulled forward the date to now where it is expected to occur sometime around November 30th, 2012 or earlier.

So with no "surprise" coming, the market might already have priced in the drop.  It may even have over-estimated the importance of the drop by pricing BTC/USD at $12.  Maybe come December if the exchange rate is still $12, a bunch of investors that were waiting for the big payoff see that it didn't happen and unload, pushing the exchange rate down into single digits again.

Nobody knows.

What isn't known is how widely bitcoin will gain traction and when that might start in earnest.  That is why the blockchain daily transaction numbers and estimated total output metrics are watched so closely -- they are unknowns and weigh more on the exchange rate than the previously known block reward drop from 50 BTC to 25 does.

The difficulty adjusts every 2,016 blocks.  If that happens in 5 days instead of 14, then it happens in 5 days instead of 14.  No big whoop.  And the target is back to 7,200 BTC per day.

Now there is a max increase though of 4X the prior difficulty.   So difficulty can't increase more than four times the previous level from one difficulty adjustment period to the next.

As far as "inflating the supply",   those were coins that were going to be entering anyway, they just were pulled forward by a few days.  An extra 5K or 10K BTC per day issued doesn't mean an extra 5K or 10K BTC hitting the exchanges, especially since unlike GPUs, most ASICs were paid well in advance and thus miner's may not be anxious to cash out.  Especially with the block reward subsidy drop to 25 coming (or already there by the time ASICs ship.)

The bitcoin.conf should be in Bitcoin directory ... the same directory where the wallet.dat resides.

Do you have a file permissions issue maybe, where the user running Bitcoin-qt can't read the .conf ?

Hit 'em with kindness, but hit 'em square where it hurts -- right in the pocketbook.

That was a fine job there, unterhund!

Yes, I do know.   Former northern MN Iron Ranger here.

But why not capture the heat and save on your gas bill?

Are you running on an encrypted filesystem?  That will really slow things down.


With Bitcoin v0.7 you can load from a blockchain data file:

 e.g., from the command prompt:

   C:> bitcoin-qt  -loadblock="C:\temp\blk0001.dat"

Get a current blockchain database here:

 - http://eu1.bitcoincharts.com/blockchain


You can even tell the client to not make any connections:

  (add   -maxconnections=0  to your bitcoin-qt command line)



[Update: Fixed.  -loadblock not -loaddata
One other suggestion, you might find someone who can provide you with a fast download of a current blockchain and index.   Or perhaps you can pay to have someone take your wallet and do a spend transaction that sends the funds to your EWallet. ]

You can see if there is any interest on #bitcoin-otc:

 - http://webchat.freenode.net/?channels=#bitcoin-otc-foyer
 - http://www.bitcoin-otc.com

[Update: If you would like, put out what trade you are looking for here in this thread and I'll cross-post it to the Mt. Gox <--> Dwolla thread:

 - http://bitcointalk.org/index.php?topic=78512.0 ]

When payments made in settlement of payment card transactions (e.g., credit card) exceeds a threshold then the payment processor must report that as income to the IRS, using form 1099-K.

That threshold is currently $20K USD but only if you received 200 or more payments in the year.

 - http://www.irs.gov/Businesses/New-1099-K-Reporting-Requirements-for-Payment-Settlement-Entities

What that means is if you sell on eBay and have received $20K in the year on your PayPal, then you'll get a 1099-K reporting that income.

That just means that your income tax return must include this income.  Obviously you will have expenses against that income -- like the cost of the merchandise, the selling fees, shipping costs, etc.   Only on the profit that results would there need to be income tax paid.

Now, while this is a new requirement (2012 the second year where selling activity is subject to this reporting requirement) there have been reports of problems already.  Some payment processors are reporting even those with well under $20K having been reached.   People who received personal payments through PayPal from family members are now finding they now need to keep records, proving that the transfer was truly a gift or for tuition, for example, rather than proceeds from selling on eBay, for instance.

Incidentally, if anyone was interested -- Amazon gift codes with MoneyPak.

 - https://www.moneypak.com/Partner/Payment.aspx/AmazonGiftCard

This provides a way then for someone with cash to purchase coins from you.

In order to offer a solution to a problem, you need to show that there really is a problem that needs to be solved.  

If there's no flaw, then what need is there for a solution?  So for the purposes of their research they make the assertion that there exists this rack attack problem.

Now because they are correct that one or more configurations will leave Bitcoin vulnerable as they describe, they used one as an example and ran with it.   Their solution will lessen the double spending race attack regardless of whether the client is configured correctly or not, therefore it is beneficial work they did, but merchants have alternatives that work nearly as well which they didn't reveal (configure with no incoming connections, and explicitly connect to well-known nodes).

How did this research published months ago end up back in the news?

Anyways, they are claiming near 100% success in double spending using a race attack under a configuration that is not recommended for merchants.

Following the basic recommendations for merchants (don't allow incoming transactions, explicitly connect to well-connected nodes), the chance of a race attack becoming successful drops to a level that can be managed, if not eliminated completely.

 - http://bitcointalk.org/index.php?topic=79090.0;all


There is no protection against a Finney attack except for that attack being so expensive to carry out (over $1 per second to hold a block while trying to carry out the attack.)

That being said, no traders have reported losing funds to a double spend resulting from a race attack.

A coin changer at the laundry that takes bitcoins -- sure, that's vulnerable to the race attack.  But selling coffee on 0/unconfirmed and most other types of bricks and mortar commerce have little to fear from accepting bitcoins as payment before the transactions have any confirmations.

Here's more regarding recommendattions:

 - http://bitcointalk.org/index.php?topic=106026.0

It is in there ... getrawtransaction   

 - http://en.bitcoin.it/wiki/Original_Bitcoin_client/API_Calls_list

 - http://en.bitcoin.it/wiki/Raw_Transactions

That should come as a surprise then to the exchange in Denmark where today you can purchase Bitcoins with UKash (through CashU).