And specifically with Square it appears that as soon as they made available a "redeemable code" (gift certificate that can be redeemed by the bearer of the QR code) then they are falling under this category of being an issuer.

I was wondering if these would cause a problem.  When I pay with Square, Square draws from my credit (or debit) card account and delivers the money (less their fee) to the merchant.  I have my goods and services and the transaction is complete.   But when I buy one of these gift cards, the money is drawn from me and paid (less the fee) to the merchant right away but it could be months or longer before I redeem it to get my goods and services.  So this is like issuing credit to the merchant, who later "repays" the loan by letting me the customer make a purchase from the merchant using that gift card.  But that's not what the problem is apparently.  The problem addressed in the complaint is that the code is a method to transmit money.  It can change hands before it is redeemed, so in that manner it is like issuing a form of currency.

[Edited, the order doesn't define these codes as being currency, but does say a money transmitter license is needed to issue them.]

 BitMit?

Then you send an e-mail with a link for the download.

I was a little surprised to see that thread locked as well.  There's a difference between someone being ignorant, persistent and/or wrong versus someone abusing the forum in a way that causes harm.   The way to handle the former is called the "ignore" button.

Fantastic approach.  Kudos!

If the problem was that a payout from SatoshiDICE was using unconfirmed funds that ended up being double spends (and then disappearing), they will re-issue the payouts for all transactions that have confirmed.

If your wagers are (now) invalid due to it being a double spend, then even if SatoshiDICE did at one time send a payout they won't re-send it because they won't even know about it ... no nodes will relay your double spend transaction and thus it will never reach SatoshIDICE.

That's assuming your spend transactions are double spends.  I can't say whether they are or are not.

If you leave your client running for an hour and the transaction IDs for those transactions still don't show up on blockchain.info, then you can almost certainly assume that your transactions are invalid.

The Bitcoin-Qt client doesn't deal well with (outgoing) double spend transactions.  If that is what happened then to clear things up you need to perform wallet surgery to remove all transactions and rescan and let the wallet rebuild from there.  

Or export the keys and create a new wallet with those keys. That does the same thing.

[Edit: And just to clarify, you aren't at risk of losing anything.  You can also try to import your wallet to regain the ability to spend any coins that the existing wallet might have sitting stuck in those invalid transactions.
 
 - https://blockchain.info/wallet/import-wallet

I can confirm that I too couldn't create a new marked cash deposit transaction.

And it won't allow new "marked" cash deposits either (which I can confirm):

Is anyone else having problems with Bitme deposits?
 - http://bitcointalk.org/index.php?topic=148078

But nothing here describing it, nothing on Twitter, etc.
 - https://twitter.com/bitmexc

BitInstant currently shows that they are down for the weekend.

Your remaining methods include cash deposit methods at Bitme (deposit at Chase bank), BitFloor (deposit at Bank of America), ZigGap, (using Western Union).

You might also find luck doing a local trade:
 - http://www.LocalBitcoins.com

If the withdrawal transaction is seen on blockchain.info but has not yet confirmed, then just be patient.  There's nothing the Bitcoin-Qt client can do with it until it confirms anyway.

If it has confirmed and you still don't see it on your client, try manually launching the client and doing a -rescan.

There are currently a couple bulk sellers who will help match up large buyers with their supply.  But you are correct, if that supply is already accounted for or is insufficient to meet the buying demand there's inefficiency when one day a big buy occurs causing a spike and the next a big sell occurs causing a selloff.  When the two could have been matched (had they known about each other) that would cause better prices for each and much less of a disturbance to the market.

CoinLab is going after this:

 - http://coinlab.com/liquidity

Your Electrum client holds the private keys, not the Electrum server.  The transactions are signed by the local client, so they are never sent to any server.

What is a potential problem is that the server does inform the client of payment transactions received.  So this would be a risk in the case where you are receiving bitcoins in exchange for cash.  Your Electrum client says you received bitcoins, you hand over the cash, and only then when you try to spend those funds do you discover there was no actual payment.

A remedy could be to perform independent verification on all payments received (e.g., using Blockchain.info or other) before trusting those payment notifications.    [Edit: If Electrum does SPV (thanks btcven for point that out) then this risk does not exist as I've described it.  Perhaps someone can answer specifically as to how the client specifically is protected against a server that lies about payments received.]

Here's the Electrum Wiki page:
 - http://en.bitcoin.it/wiki/Electrum

BrainWallet is a javascript-based web application that runs in the browser.  It does not send your private key anywhere.   It can be used offline (for the generate public key from a private key part).

Correct, there is a mechanism to accommodate lost coins.  Market price.

Problem?

How so?

[Spoiler: Here come's the invalid "deflationary spiral" argument.]

How many threads are you going to create about this?


So there are
  2,100,000,000,000,000 Satoshis to go around.

Or about 300,000 Satoshis per man, woman and child on the planet today.


There is no cap.  The value of a bitcoin will rise to accommodate the level needed for use as a digital currency.

Nope, the addresses are a subset of the public  key

What Giddeon wants is the 130 char Public Key (SEC).

And as Gweedo suggested, click Private Key, paste private key, and it will generate the Public Key (SEC) for that key.

Someone with $332K USD worth of bitcoins probably should discuss secure storage methods.  That person's family will miss those coins.  Sad.



Incredibly unlikely, for sure, that there would be 21,000 people each with $332K USD worth of bitcoins and all are completely clueless and careless.

But, for the sake of argument, let's say there are 20,999 people with $332K USD worth of bitcoins who are completely clueless and careless, and just one remaining thinking individual who has proper storage of the 10,000 BTC.  These happen to be the last remaining bitcoins that exist since everyone else lost theirs.

Well, guess what. .. a single bitcoin is equal to 100,000,000 Satoshis, so that means there are still 1,000,000,000,000 Satoshis for circulation, or nearly 140 Satoshis per man, woman and child on the planet today.

Now, of course, let's assume the valuation is the same, and that person with 10,000 BTC would be sitting pretty, because at $342 million worth, the BTC/USD of each of the 10,000 BTCs would be worth $34,200.  Score!

tl;dr: Lost coins hurts the party that lost the coins.  Without those coins the value of the remaining coins will likely increase roughly at the same proportion.

Each exchange methods has unique attributes.

In the UK, you probably want to look at Transferwise and/or CurrencyFair and then look at an exchange that takes Euro.  That way you convert GBP to EUR using Transferwise or CurrencyFair, and then transfer the EUR to an exchange (e.g., BITSTAMP) and make your trades there.

Sorry to hijack your thread, ... seriously, but to interject.   

Neither party is safe in a PayPal transaction.  PayPal could reverse a transaction even if neither party reported a problem even should they suspect the funds were being used in violation of their user agreement.  (Their user agreement prohibits their payment network being used for the purchase of digital currency, specifically.)

So the people that are putting up the cautionary flag are doing so for the benefit of both buyer and seller.

Under a couple dollar's worth of bitcoins might be considered a microtransaction.   If you send an amount less than 0.01 BTC it may cause the transaction to be delayed, slightly, in getting included in a block.