Re: key rotation, ssl listI haven't yet understood the purpose of this scheme. For precisely the reasons you stated before, it's "protecting against an attack that does not, and cannot, exist." What additional value does this scheme provide except to grossly complicate an elegant solution (green addresses)?

I just donated, but it's not much fun getting a unique anonymous address. The public donation history is part of the motivation in any fund-raising campaign!

I'd suggest flattening the directory. Just one page of logos, short descriptions, and links. You could have ten times as many associated merchants and I'd still think the flat presentation would be cleaner.

I just made a donation by way of your service. After I sent coins to the address provide your service states: "This bitcoin address can be reused as you like." I think that's a little ambiguous. Perhaps you should instead state: "This bitcoin address can be reused to send to the same entity as you like."

Minor UX: A user can click on the "about" menu to see a page (with no links), but that same menu title displays a sub-menu of two entries. That's a no-no. Either the top menu links to a section page which contains links (and description) to the sub-items, or the "menu" button does nothing and only the sub-menu items are active.

Anyway, your changes today give me confidence, even if your legalese makes no liability guarantees, at least you're up front about it. I wish you the best of luck, security, and look forward to seeing your new features and inevitable success.

http://www.blockchain.info is perfect!

By the way, I got the impression that your service could track relayed transactions even when not locked into a block (0/unconfirmed). I removed transaction fees from main.h and sent a tiny (0.005 BTC) transaction. The fact that I can't see it means what? 1. you won't display the transaction until it's in a block, 2. no other nodes have relayed the transaction, 3. nodes have actively rejected it (somehow), 4. or....?

Hey Gavin et al,

Congratulations with this RC1. My comments are mostly superficial as the plumbing seems to 'just work'. With Qt, this is the first time I've successfully compiled from HEAD for months. That's a huge bonus in my world.

The incoming transaction notifications are subtle but informative. The client looks nice and lays out well full screen in xmonad 1280x800. UX failure begins in width <570px and height <226px; It needs scrollbars in small windows. Ambiguous dates (xx/xx/year) are unacceptable in an international product without localization, otherwise ISO 8601 (YYYY-MM-DD HH:mm:ss) UTC should be used.

The splash-screen wallet is cute but annoying. It does not play nice with my window manager. I can't hide it, move it, nor redirect it to another workspace. So I've got this box blocking whatever I'm doing for several seconds dead center screen.

I can guess, but not sure what the three icons indicate in the bottom right of the client; They could use some hover tool tips. mBTC and μBTC are clever if not hopeful as kBTC would be more realistic today . The dynamic 'clock' unconfirmed and 'check' status are perfectly informative. I can not see the sending address in my transaction history when receiving (from unknown?). Address book, meh.

In the future, I would like to see options such as import/export and more control/visibility of transactions, even if these features are deactivated by default.

The message "This transaction is over the size limit.  You can still send it for a fee of 0.0005 BTC, which goes to the nodes that process your transaction and helps to support the network.  Do you want to pay the fee?" is confusing, particularly if/when the user is sending a small amount (to him value IS the transaction). I would recommend "The network is congested" or really get into the sum(value * confirmations)/(bytes) with a "help"/"more info" link.

Aside from the fact that this is confusing, it's annoying that the user has no recourse, this 'feature' makes micro-payments less realistic. I would much prefer the message warned me that miners may decide not to send such a measly amount of money without paying a fee. Would I like to send it anyway YES or no? Bitcoin is a FREE market experiment after all. A suggested transaction with vague/estimated delays might be appropriate.

If the client asks for a passphrase on send, there is no need to also ask if he really intends to send coins. For small transactions, the user is unnecessarily replying yes three times before sending a coin.

IFF the client must ask me if I want to send a measly amount of money to which I may decline paying a fee and thus abort, it would be better to ask for the passphrase after I've fully confirmed my intention to send (including any fees) or at the same time.

Aside from my stalled micro-transaction ( Thank Satoshi for main.h ), everything looks and works very well! Thanks again for your hard work to produce a great client,
Netrin

These guys are cool: http://www.npr.org/blogs/money/2011/06/29/137478762/the-tuesday-podcast-libertarian-summer-camp

Perhaps you could be up front about the charges. "We rape you 1% on the spread while the telecom rapes us both 50%"

Hi Ira,

Your service and open nature here in the forums seems positive. We all look forward to a reliable, trust worthy and free ewallet service. Considering a large email distribution using your service this week, I would like to get the community's feeling about your service and give you an opportunity to comment on a few constructive critiques.

Two of your pages return 404 (Privacy and Terms of service). Your forum and directories could use a some love. There is no identifying information on your site, though your whois appears to be legit: Irenaeus Miller (i...m... at gmail.com) Broomfield, CO, USA. No description of your security measures, insurance, nor legal/financial plans should you be successfully attacked.

Cheers.

EDIT: Ira responded to me directly and addressed my most pressing concerns to my satisfaction.

Thanks Bitrick.

+3.141592653589793238462643383279502884197169399375105820974944592307816406286208998628

Jeg er enig med dig.

We hope that Mt. Gox hasn't botched the algorithm and that a private key can not be derived from the public key nor messages (and timing and other side-channel attacks are highly unlikely unless the attacker... I won't even go there). I think we can agree with brilliant mathematicians that elliptic keys are secure and there is no concern that "bad people" will guess the private key.

Since no one can guess the private key, there is no reason to protect against it.

And how would we protect against a compromised private key anyway? If one private key could be compromised, then all of them could be compromised, and our bitcoins would be as valuable as the gold from which they were forged.


That's 7 words, but in a simple word 'no'.

Lige præcis. Når du vågner op fra din tømmermænd, skal du blive velsignet med en AH HA øjeblik!

You're completely missing the point. The 'solution' 'solves' the 'problem' of cryptographic failure. If the cryptography fails in a cryptographic currency, it's game over.

No, green addresses are great. Tux is concerned that someone will derive the private key from the public elliptic key, transaction messages, or some side-channel attack. In order to minimize the damage, he's transferring coins as input and output of the same address/block. However, if a private key can be derived, losing a few coins will be the least of our worries. The entire bitcoin network and several other systems will be destroyed.

A condom to protect against meteors. Awkward, inadequate, unlikely.

I think the A->B->C transactions within a single block is an interesting thought and practical experiment, but it seems to be a sub-optimal solution to a non-extant problem. It's a bit like wearing a condom to protect against a meteor impact; Awkward protection from a highly unlikely but otherwise catastrophic event.

It's a nice setup, but I'm afraid your rates are exorbitant.

Is a private key attack a realistic concern? If so, the implications for your business and our entire economy are devastating.

谢谢

bitebi.com (bitcoin in pinyin) seems up for sale.

I wasn't previously aware of Kiva, though I think micro-loans are a wonderful concept. I would definitely offer bitcoin credit and would be willing to cover the transaction/exchange spread.

Yes, I suppose that's true, an unconfirmed bitcoin transaction from a known address is functionally equivalent if not better than for example a PGP signed IOU.