v4.7.3 is so old.  I don't even remember what "arrow both in and out" would refer to. [Edit: That number of confirmations is what shows on your client, correct?  And that corresponds to the number of confirmations that show on Blockchain.info, correct?
 - http://blockchain.info/tx-index/58464860/e7fcb782ce3d36e5d33858ac112a1c29ce118f65a4f8ed25ee641e11050b6a8d
]

What is clear is that the blockchain shows those amounts spent and confirmed (in e7fcb782ce3d36e5d33858ac112a1c29ce118f65a4f8ed25ee641e11050b6a8d ), however the addresses those funds were spent from still have balances available for spending.

I'm not sure your familiarity with Bitcoin so let me describe something basic, in case you weren't aware.   You didn't have to spend 0.04516 anywhere for there to be a 0.04516 spend from your wallet.  The transaction in which those amounts were spent was for an amount of either 2.0 BTC or 0.01293025 BTC with the other one likely being change returned.

So if you didn't make that spend transaction on March 5th, 2013 then somehow somewhere your private keys are being used to spend, which could possibly mean a compromised wallet.dat or computer system (or both).   I've no idea if that's what happened but if you are saying you didn't spend either 2.0 BTC or 0.01293025 BTC on March 5th, 2013 then you should presume your system is not secure at this point.   [And the response to that is to use a different system that is secure, generate a Bitcoin address .. like using Blockchain.info/EWallet, and from your suspect system send your remaining funds to that address until you can rule out any chance that you have a wallet and/or system that is not secure.]

Since the value of a Casascius physical bitcoin is not in the metal but instead hidden under the (easy to counterfeit) hologram, I would make the argument that for that reason alone these are not intended for use as current money. A rational person wouldn't accept these in trade unless you trust the person with whon you are trading.   Therefore, these aren't are form of current money.

I didn't try until just now, but I can access the site.

Generally, when verifying if a site is down, there are tools to confirm that it is not just you:
 - http://www.downforeveryoneorjustme.com/virwox.com

And wrong, since bitcoin isn't "capital".

Total Dollar Valuation (TDV) would probably be the correct term.  It represents the purchasing power at the current market rate.

You are not being screwed by PayPal, you bought something that wasn't delivered.  You made the assumption that you were protected by PayPal but they are avoiding that using technicality (by saying you bought a digital good).

How did you pay for your purchase, from a PayPal balance, or with credit card?   If you paid with credit card, you can charge back through your credit card issuer. 

That's probably something whose root cause should be understood (and not just overlooked).

It most certainly did.  The OKPay double spend was an intentional double spend (performed by manually constructing and broadcasting a transaction that re-spent previously spent funds) and was successful due to a combination of factors.

There still are even more double spends that can be performed (as they are still unconfirmed and not yet spent) but simply haven't (yet):

And if the ring is stolen the funds could be transferred (assuming he has a backup copy of the key) before any cracking attempt could solve it.

But yes, he might have said "there's only a few bitcoins, the metal is worth more than the bitcoins" or something like that so as to not incent those who might consider the possibilities.

You've had the ability to load directly to a mobile # (without the refill code method) and you've been holding out?

I personally tend to prefer the method that protects privacy but simplicity (load directly) trumps privacy concerns for most.

From a mobile, not having to go the refill code route would be preferable and easier for most.  If you can offer that, it probably should be the default even (and refill code as the optional method).

There's a reason bitcoins exchange for a lower rate on BTC-e than elsewhere, and that difference is partly because of the difficulty in transferring funds there.

AurumXChange will let you transfer VouchX USD vouchers as well as a few other redeemable codes (including Mt. Gox USD codes) into BTC-e vouchers.

Might want to describe the problem you are solving.  For instance, I wasn't aware of the term "wedding social".  In some cultures, these either go by other names or are not necessarily fundraisers but instead are just for the purpose of entertainment.

Or if you too a GPG fingerprint I'ld do that instead.   But now that you offer GPG encryption, that's how I prefer to receive my mobile wireless refill code.  And sometimes I will be placing that order from my mobile.   I might not redeem (after decrypting the message) from my mobile, but I'll likely be placing the order using it.

In denmark you can do a domestic DKK transfer through Bitcoin Nordic:
 - http://www.BitcoinNordic.com

BIPS.me sells bitcoins and accepts DKK:
 - https://bips.me

There might be other methods that work for you.  For instance, if you can send SEPA (EUR), then BITSTAMP is one of a half dozen exchanges that you can send SEPA payments to:
 - http://en.bitcoin.it/wiki/Buying_bitcoins

You could even try CurrencyFair where you transfer DKK by bank to them, then convert there to different funds and wire from there.  That's another method to go from DKK to EUR to send to BITSTAMP:
 - http://www.CurrencyFair.com

I didn't have any BUH3 myself so I don't have a log entry.   At a minimum it settled before 20:29 UTC when the Tweet was sent.  And before 20:39 UTC which is the timestamp when Fireball's forum was posted here.

I did personally see open buys and sells for it right up before 20:00.

So I don't know how externally one could verify the exact millisecond the settlement numbers were reported.  The settlement price though is as-of exactly 20:00 UTC.   There is evidence that this settlement price was obtained between 20:00 UTC (when trading for it was no longer possible) and 20:29 UTC (the time of the tweet), and other traders have reported this timestamp in their logs:


as well as mutliple traders confirming that at the time of settlement (or minutes after) the 24 hour VWAP price from Mt. Gox was at that 47.0764 level, including:



[Edit:  OK, maybe I'm overlooking something basic and am missing your point entirely.  Are you instead asking for the link that shows when settlement happens?

- https://icbit.se/futures  ]

A pattern that repeats is for a person to build up trust and then once enough trust has been reached use that to scam and then abandon that profile.  Anonymity makes that cheap and easy to do.

Even knowing the person's real-life identity isn't protection -- as we know from pirateat40's ponzi scam.

The Bitcoin-OTC Web of Trust (WoT) is also vulnerable to that however it can be longer in duration and can span communities.

When dealing with non-reversible forms of payment, essentially there are no guarantees and limited recourse.  That's the nature of these instruments.

Some effort can be made to make it clear your counterparty is not in it to cut and run.  Here's an article that explains how this is nothing new:
 - http://theumlaut.com/2013/02/27/bitcoin-and-bank-architecture/

And here are some resources:
 - http://en.bitcoin.it/wiki/Secure_Trading
 - http://wiki.bitcoin-otc.com/wiki/Using_bitcoin-otc#Risk_of_fraud

You are probably describing how in your Bitcoin-Qt client is a spend transaction that still shows 0/unconfirmed.

If so, then what most likely is the situation is that the transaction uses funds that you had received and spent.   The stock Bitcoin-Qt/bitcoind client doesn't let you spend any funds until they have at least one confirmation.   So what can happen is that payment you received showed a confirmation, you spent it, and then it reverted back to having no confirmations.

Looking at it now then, your client has an invalid transaction -- it wants to spend funds that you never really had and don't have today.  You have a transaction that is no longer valid.  Worse, if your transaction also attempted to spend any other funds which were valid, it will reserve those for this transaction which will never confirm.

The Bitcoin-Qt/bitcoind client doesn't handle these outgoing double spends nicely.    In fact, unless you are technical they become quite a pain.

The easiest resolution for some is to import their wallet into another client that can handle this scenario better, or to export your private keys from your Bitcon-Qt, create a new, empty wallet and import the private keys so that you end up with exactly what you just had, less the offending transaction.

The easiest way for some is to import the wallet.dat to a new blockchain.info/wallet and spend the funds from there.
 - https://blockchain.info/wallet/import-wallet

Otherwise, the Bitcoin-Qt client has a Debug console in which you can export your private keys.  The:
  listaddressgroupings
command will give you all the addresses in your wallet, and from there you can do a:
 dumpprivkey [BitcoinAddress]
on  each address. 

Then if you are creating a new wallet, then to import the keys:
 importprivkey [PrivateKey]

For more info on importing:
 - http://en.bitcoin.it/wiki/How_to_import_private_keys

 - Received Dwolla?  Ding.  U.S.
 - Submitted ID and it says U.S?   Ding.  U.S.  (or submitted Canadian,  CAN)
 - Access via U.S. or Canadian IP address?    Ding.  U.S. or Canada.

It's 80% of Mt. Gox's customer base (not sure if that is by number or by value of accounts).

If you ever import private keys, those won't be able to be recreated from the seeds.

Fast forward 12 months:  Do you remember when we thought a 11 Thash/s spike was something notable?

A (24 hour) volume weighted adjusted price is just that -- the VWAP for the trailing (24-hour) period.  It can be any 24 hour period of time.  The contract doesn't say 00:00 to 23:59 UTC of settlement day, it says the "volume weighted average price", and the settlement occurs at 20:00 UTC.   So the 24 hour WAP goes from 20:00 on the day prior settlement day through 19:59 of settlement day.   [Update: Since the contract doesn't actually say "24 hour", it could be ambiguous as to which VWAP was intended ...  24 hour, monthly, or what?  Previous BTC/USD contracts were using the 24 hour VWAP.]

Now I suppose a script can be run to check the numbers, but settlement happens in real-time.  There's no ability to go pull the raw trade data to come up with the WAP in real-time.   If that computation is done later and comes up with a different number, then it needs to be analyzed why that is.

I can see the potential for a problem though.  If Mt. Gox exchange were to misreport the weighted average, possibly from a staff member trying to manipulate the ICBIT settlement price, then it would be hard to prove what value was showing.   I can see the need to have a separate computation performed later against the raw trade data for verification purposes.