The contract was settled at 20:01 UTC, just like the contract says.

PM means after 12:00.  08:00 hours + 12:00 hours = 20:00 hours.  

The forum post time is 08:39 pm UTC, which is the same as 20:39 pm UTC.    He posted the forum post 39 minutes after settlement occurred.

 - http://en.bitcoin.it/wiki/Trade#Precious_.26_Base_Metals.2FCoins

Several interactions with Benson.  Pleasant experience on all.

Then the question is, how can you prove to the person you paid that the address was one that they gave you to pay?

And the answer to that:


And a variation of which is being developed now.  The Development mailing list has a thread on the topic.

If you are using v0.8, the initial download is about a day or less -- and much less if you have decent hardware and bandwidth.

If you are using v0.7, stop (or stop, if you don't have decent hardware, bandwidth and patience.)

If you are using really old hardware, consider MultiBit, which is an SPV client -- it only downloads block headers and unspent transactions for addresses in the wallet.

Yup, Blockchain.info was reporting wrong values.

Here's more info:

- https://twitter.com/blockchain/status/313269863365877760

Give it another try and report back.

The URL for that:
 - https://localbitcoins.com/country/IL

There's Meni's:
 - http://bitcoil.co.il/

There's also:
 - http://bitcoinisrael.co.il  <---   Fairly new, perform due diligence, use and escrow maybe?


You can also pay cash to buy either a CashU card or a UKash card, and use that instrument to buy bitcoins through Bitcoin Nordic (either), VirWoX (UKash) or mercabit.eu (UKash).

For larger amounts, of course, an International bank transfer to an exchange works.

The more comprehensive list of exchanges:
 - http://en.bitcoin.it/wiki/Buying_bitcoins

The BitInstant support thread is here:

Official BitInstant Support Thread (Active Customer Support)
 - http://bitcointalk.org/index.php?topic=128314.0

That question has been raised, but not answered as far as I can tell:

The newer clients (v0.7 and higher) are less ignorant of bad data in the wallet.dat.     Are you getting a message unable to open wallet.dat?

You could try joric's pywallet and see if it can get more out of it than Bitcoin-Qt can.

How to export keys from the Debug console?

Or how to get to the debug console?    The Debug Console option is in the pull-down menu, like Help -> Debug Console maybe?  (I'm not using a machine with Bitcoin-Qt installed at the moment and I can't remember exactly which pull-down.)

The command to get a list of all addresses in your wallet:
  listaddressgroupings

Then to get the private key for each:
  dumpprivkey [address]

Then to import the private key for each:
  importprivkey [private key]

You can copy and paste from the Debug Console into an editor, and then create the commands to somewhat automate it.

Here's more on importing:
 - http://en.bitcoin.it/wiki/How_to_import_private_keys

Sure.   Call it e-gold.   Sell the snot out of it!   Great idea!   Someone should do it!

[/snark]

Well nobody knows what the change to purchasing power is if this hypothetical "economic majority forces an immediate end to the block reward subsidy" and thus that 2.5% of currency inflation that was expected in year 2024 goes away.

That's why the buyer should require that lending contracts include some language that addresses changes in the protocol that would affect the currency inflation rate.   

But it is really a moot point, I believe.  The lending from the economic majority also includes loans to miners, and miners made an investment in their capacity counting on the subsidy -- it was part of the deal.  The miners would default on their loans causing once again for the economic majority a wash between the two options.   And that's a relatively minor issue compared to the bad image it would give.  If there were any alternatives a black eye like that would be a great catalyst to move to another one which is even more resistant to that type of corruption.

Well, the weekend isn't over but it looks to be about a break even to buy back right now, then less fees for a sub 1% loss.    At the time of the post (late Wednesday (West), mid-day Thursday (East)) the exchange rate was something like $47.80.  The last trade at this very moment was $47.52.

There was a dip, down to $46.05 and many opportunities to buy back at a small profit when it was under $47 and was looking quite apparent that this weekend was not going to see a big selloff.  The thing the weekend dip strategy couldn't have seen in advance was the IMF going batshit crazy like they did.  Now I gotta figure out how to reverse some other positions where I'm on the wrong side before Europeans rush the exits and discover bitcoin as a new home for their money.

You might be confusing the term "reverse transaction" with "reverse confirmations".    An attacker with 51% can release a blockchain that started a number of blocks back and invalidates a number of blocks.  For any transactions that the attacker does not include in the new longest chain, those transactions will simply sit as 0/unconfirmed.   That's technically not "reversing" the transactions.

And for part two of that, "Send coins that never belonged to him", I'm not sure why you would think that an attacker with 51% could do that.


They'ld throw twenty million+ dollars away?  I doubt their shareholders would think it wise.

Anyways, two years ago when bitcoin had just hit parity with the dollar, (giving a total dollar valuation of about $7 million USD) and the cost to do a 51% attack was probably less than $1 million of hardware this same argument came up then.   "If bitcoin becomes mainstream, $1 million would be nothing for a government or big bank".   Which probably is true, but nothing happened.    Now the cost is 20X that, ... no longer something that would be done "just for laughs".    A few more months, that might be $40 million.    They better hurry, because this thing is starting to look like it could go mainstream.

Nope.  Those v0.8 clients simply added those transactions from the orphaned block back into the memory pool.  It does not re-broadcast them.  I don't even think the node that sent the transaction will re-broadcast the transaction immediately upon the block being orphaned -- it probably gets treated like normal, at some random point (e.g., over the next half hour) it will re-broadcast it because it has no confirmations.  [Edit: the sending node was a v0.7 node so it had no concept of orphaned v0.8 blocks, so it should've just simply re-broadcast periodically until confirmed.]


Take the 211.9093 BTC (~ $10K) transaction to OKPay (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195).  It had been broadcast and then included in the v0.8 side in block 225,446 (00000000000000757de9173ee2f01c9f957c8aa3b4f71b901b0fa19683ab1fa1) but did not confirm on the v0.7 side, presumably because the transaction had inputs that hadn't even confirmed yet on the v0.7 side.  So on the v0.7 after the transaction had been broadcast and relayed you had new v0.7 mining nodes starting up.   But they don't pull transactions from peers, they only listen for broadcasts.

So that's a normal situation where these new v0.7 mining nodes are ignorant of a double-spending race attack potentially being attempted.  Only BTC Guild knows if and when that node had received (12814b8ad57ce5654ba69eb26a52ddae1bff42093ca20cef3ad96fe7fd85d195) and if it had then why their node (running v0.7 by then) no longer knew of it when it mined the double spend (762443f6373b7c8b3833d4ad23578fc3099cc29b86d1359d0c0565e3c8614f91) more than six and a half hours later.  It could be that the node was just spun up and the memory pool just hadn't received that transaction yet.  I might suspect that the memory pool for that node was filling and as a result was housekeeping by flushing older and lower priority transactions out.  This was an intentional double spend (even if the losses to the merchant were repaid voluntarily by the "attacker" at a later time) and was carried out by running a script to broadcast the double spend continuously every ten seconds.   The initial transaction was submitted through Blockchain.info (though I'm not sure if that was as a raw transaction through their pushtx or if it was through their API (or normal web interface maybe even).  It is possible that it was a fire and forget action, where the transaction wasn't re-broadcasted ever again.

What might have been useful is if there was some hard fork recovery approach in which the memory pool was initialized using the list of transactions from a set of blocks (the ones that would be orphaned on the v0.8 side).  If any blocks arriving had transactions that included a double spend of the recovery transactions those blocks would be ignored.  This mode would continue until all transactions from that initial set were either included in blocks or rejected for being invalid.  Then the client would switch back to normal and bring in the transactions that had queued up while the node was in the recovery mode.  As long as enough hashing capacity followed this "deferential recovery" mode the recovery might have been nearly as quick and no merchants would have had confirmed transactions on the v0.8 side that ended up not confirming on the v0.7 side when the transaction was valid on both.  That's not a violation of the protocol but instead is just a manual override mode that would help protect Bitcoin's prime directive #3 -- transactions having six confirmations or more on the longest chain are never reversed.

The granularity of Bitcoin's passphrase encryption isn't at the file level, it instead is at the Bitcoin Address record level.  There is one field in the Bitcoin Address record in the wallet.dat and that is what needs to be decrypted.

So after being decrypted, in memory is only the decrypted private key for Bitcoin addresses(es) being used for a transaction.  But in memory at some point as well is the Bitcoin passphrase that you just entered which is then used for decryption.  So like the other posts mention, the Bitcoin client still requires a secure computing environment to protect from keyloggers and other malware.

I think this is an issue that is going to see an increase in the number of times it comes up.  The question to start out with is ... what is your functional currency?

When I buy bullion, in most practical instances I need to convert the metal back to my functional currency to spend the value from them.   So even though silver rounds could be used in commerce in some instances, they wouldn't be my functional currency.

Bitcoins now are what I consider to be my functional currency.  Because my spending comes from bitcoins (either directly if I can use bitcoins to pay for my purchase, or indirectly if I need to convert coins to dollars and make my purchase that way), then I might consider buying dollars for investment purposes as being one of my investment options.  When buying dollars I'm essentially going short on a currency (bitcoins) that I will return to after I close my investment position (when I sell my dollars, and obtain the proceeds from that transaction in bitcoins ... which are my functional currency.)  

But someone else who doesn't see bitcoins as the functional currency then wouldn't have the same viewpoint that holding a different currency (dollars in this instance) is a way to short bitcoin.

It would be the same as if someone would assert that I today am shorting the Japanese yen (simply because I don't have any).  Of course since I don't plan to hold any yen regardless if the yen's value goes up or down means I am not short the yen.   My purchasing power of my bitcoins versus yen might have changed, but I didn't profit from a move either up or down in the value of the yen.

As far as methods for shorting bitcoin, I just had read that EToro plans to support BTC in one or more currency pairs.  So there are more methods coming.

Right now, if you are looking to short, the BUJ3 futures contract on ICBIT is probably the most attractive method right now.   There are no ASK orders below $54.5.  That contract settles Apr 15, 2013.  So that means the BTC/USD doesn't even need to go down from today's level and you could still make money shorting it that way.    So let's say you put up an ASK for 100 BUH3 at a price of $54.   You would need to deposit about 4 BTC to make that offer (there is up to ~30X leverage available for the BUJ3 at this level).    Then let's say on April 15th at 20:00 UTC settlement at the 24 hour weighted average at Mt. Gox is $50.00.      You would gain 0.88 BTC after fees, on your 4 BTC investment in that short position, and the exchange rate didn't even need to drop.

The problem with using leverage at that level (30X) though is that even a small move the wrong way can cause you to get a margin call, and there's not a whole lot of liquidity.  When that happens you are at best able to buy back at a level above BTC/USD market price but if there aren't other ASKs that you can buy from (as there is a limited trading range) you could see your position end up being liquidated and depending on the liquidation price your entire balance of your account (4 BTC in that example) could go to zero.

You could use less leverage so that if there is volatility but still believe that on April 15th the exchange rate will be below the current ASK, then you would still be able to weather it out.      At 25X leverage where you sold 100 BUH3 at $54 with only 4 BTC in your account then if it hit into the low $60s you would be completely wiped out.   But deposit 8 BTC instead of just 4 BTC to sell that 100 BUH3 contracts (at $54), giving you about 12.5X leverage and you could weather a spike of the BUH3 up to the $70s without seeing a margin call but then as long as BTC/USD settles at $53.67 or lower on April 15th you've still made money.   If it drops -- say to where the BTC/USD settles at $45 on April 15th then you'ld make 3.1 BTC on that 8.0 BTC investment.

[These computations were made with only a rough calculation as to where the margin call comes into play.]

I'm looking to see how I can change my password, as I initially used a relatively weak password and now want to use a strong password.  I was thinkin it would be on the /account# page but don't see it there.

Well, no miner is forced to claim the block reward subsidy.   So anyone can start reducing the amount of bitcoins (and thus increasing the value of existing bitcoins) by mining (solo) but not claiming the subsidy.

Now if you are suggesting to change the protocol so that starting with the next block (or at some point in the future) there is no more block reward subsidy, you can try that right now.  You just change one line of code and release your hard-fork variant of the Bitcoin-Qt/bitcoind client and start a campaign to get the economic majority to switch to using it.

Users aren't stupid though -- they know that fees are insufficient currently to incent enough miners to protect the network.    So adopting your fork would be crypto-currency suicide.        So the limit stays at 25 BTC per block, until block 420,000 and then 12.5 BTC per block, until block 630,000 and then 6.25 per block, etc.  

Now let's say it is year 2024 and fees alone are seen as being way more than sufficient enough to support the level of hashing necessary to protect the network, so the fear of the loss of subsidy impacting hashing capacity is not a limiting factor.   However, people who hold bitcoins include people who have lent their coins out to those who have borrowed bitcoins and need to repay loans (denominated in bitcoins).    

Presumably anyone borrowing bitcoins would require a clause in the loan agreement that if the subsidy were to be reduced (change in the money supply were to occur) that their principal and/or interest would be adjusted appropriately.   If the subsidy is discontinued there would be little gain for those who have lent out their coins.  And who lends bitcoins?   The economic majority, that's who.  So it is not in the best interest of any of the economic majority to change the rules as far as the rate of Bitcoin issuance -- towards either direction up or down.

[Edited: for clarity and readability]

That's because it didn't settle at 8pm UTC.     [That was confusing.  The contract specifies 20:00 UTC.   08:00 PM UTC is 20:00 UTC.

It appears to have settled at the correct time.  I think you are seeing 08:31:58 PM UTC which was the time of Fireball's forum post and somehow are thinking that was when the settlement occurred.   I didn't have any BUH3 at settlement so I don't have a print in the log showing the timestamp for when it settled, but at a minimum at 20:29 UTC this was posted on Twitter:

- http://twitter.com/icbit_se/status/312661836484980736

I don't remember the exact 24 hour weighted average number at Mt. Gox after I saw the tweet but when I did look it was some low 47.?? number and I hadn't given it another thought.