I agree, ultimately Coinbase will need to address the issue, but in the interim, adding the extra disclaimer (if possible, either as an intermediate screen where a user must hit "Accept Terms" or "Reject Terms", or as a popup with "Accept" or "Reject" options) can at least help and prevent users from getting super annoyed about this, because not everyone knows Coinbase's system does that, so they'd be annoyed / surprised / angry / [insert other emotional response here] and might take that out on you or the other devs (if any) that you have working with you.

And we're appreciative that you are receptive to our thoughts!  Because that's a good sign: a support team that listens to the opinions of concerned users.

Now, since it's 02:06 and i've been up since 07:30 yesterday, I'm going to try and get some sleep.  Good night! 

There is one issue, though, and I apologize for hoarding your thread for this discussion, but it is relevant for people who wish to link preexisiting coinbase accounts with their Gliphs.  Many people have coinbase accounts that were not created as part of the Gliph system, and were created previously with actual email addresses and such.

In testing, TBZ and I tested the integration feature of sending BTC via gliph, in which 0.01 BTC was sent from TBZ to me (and of course I sent it back, but that's not relevant to this discussion).  During the test, Coinbase, both on Coinbase's site's transaction log and their email notifications will reveal the preexisting account's email addresses, and with such accounts that were created outside of the Gliph system, it will continue to utilize those addresses.  TBZ and I both wanted to see how the feature worked, to make sure it correctly deposits into the bound Coinbase accounts, and we wanted to accurately test the Coinbase depositing system to see if it actually revealed any data, which it did.

I would suggest adding a disclaimer in the "Login to coinbase" option, either as a popup or additional screen, mentioning that if you bind a Coinbase account that was *not* created with Gliph, the email address and the name on the account will be revealed to whomever receives the bitcoins.  That would at least allow users who care to read to be told that there is a risk that their information will be revealed to other users when they send BTC.  This would also protect you (or, in tech lingo, the devs) if, say, someone used the system without knowing that risk, and decided to go on a rant and claim the privacy issue was caused by your application (which of course it isn't, but most people aren't going to know that).

That's just my two cents.  Again, sorry for hijacking your thread on this single point.

PM sent to ya.

---

Pulling a quote from my friend TBZ here, I agree with his assessment.  There is an email notification from Coinbase, and a listing on the coinbase TX log, of the bound account's name and email address as listed on the account.  That is exposed on the Coinbase logs, not necessarily the blockchain, however it is a valid assessment that privacy/anonymity (to a point), which one normally gets through gliph because messages aren't going to reveal email addresses or actual names unless those profile fields are shared publicly, could be an issue here by continuing to use Coinbase.

I had two of these coins on hold.  I had requested the hold privately.  This is the official "Buying them" order.  Two of these coins, please! (totals BTC0.16 without shipping costs, read on for details)

The stated BTC0.05 shipping cost is, I assume, for first-class mail.  I'm going to request that you ship it as Priority mail, which is a bit more expensive, but personally I've had more mail get to me when it's shipped as Priority mail than when sent first-class.  (It's also not as expensive as Express mail, but still more expensive than first class).

Let me know what the final cost is with shipping, as we discussed privately, and send me a BTC address to send to, and I'll send the BTC your way.  

(I sent you the shipping address privately, as well)

(Retroactive edit: With shipping costs based on gox last at the time, total BTC sent to serp was 0.219.)

This is something I've wanted in bitcoin-qt as well, and was surprised when i saw it just say "unknown".

I mean, a workaround is to just grab the transaction ID and throw it into blockchain.info's search function if you really want to know the "From" address, but...

I'm tired, forgive my fail at typing.  running 24/7 so i can, say, VPN in and get an at-a-glance balance

But so far, I'm inclined to agree that i can run thee web wallet for the donations, and then send them off to a qt client or something for safe keeping later.  Assuming I get any donations. 


Thanks!

Okay, so i was writing, and getting a response while writing meant "Time to rewrite" xD

The main wallet I use is for OTC trades on the #bitcoin-otc IRC channel, and that never has lots of coin.  It has an extremely fluid balance because I never hold coin there for long.  If there's little risk because of the fluidity of the funds, then I'll probably use that on blockchain.info indefinitely.  (although since it's a vanity address, I can import the privkey to a bitcoin-qt client at my leisure).

But, I want to be able to receive donations on one of my sites, hence wanting access to the wallet from anywhere and not needing a bitcoin-qt or similar client.  If it were *your* choice between a web wallet or a bitcoin-qt client running 24/7 for the purposes of receiving bitcoin, which would you choose for the specific case here?

***EDIT: I missed BitcoinBoss's answer when I was writing this.  But the open question still remains ***

I am pretty sure I know the answer to this, but what are the specific downsides of using a web wallet over, say, an actual client like bitcoin-qt?  I'd rather not have to spin up a bitcoin-qt client on each system I want to use bitcoins with, but if there's any blatant security risks to using a web wallet, I'd like to know about those risks.