nwh

There's good reason to run a fully validating client. SPV clients have quite a nice usability but really fall down in the security and privacy departments. As it currently stands people using Multibit have next to no privacy for a variety of reasons. Bitcoin Core is the most secure of wallets for a number of reasons, and possibly the most private when used correctly.

You make them sound casual, bitcoin has has really only had one hard forking change to enable pay-to-script transactions.

Trivial to solve with OCR though, which sort of defeats the purpose entirely. I'm fairly certain the letters would just be in plaintext in the SWF anyway, so it's probably breakable for a malicious person at no cost. Hard for the user, easy for criminals, smells like DRM to me.

I've shocked myself badly a few times and to me at least, I'd much rather wallow in self pity for a while than do it again.

Probably the worst was one I didn't expect, I slipped when opening a plastic case and caught my fingers over a fully charged high capacity 350v capacitor. The initial hit makes every muscle in your body hurt, then a wave of panic when you realize you could have died from the moment of stupidity.

I'd just love them to fix iMessage so that it works in something approaching a sane way. Messages "don't send" but appear on other devices, messages that are "delivered" never left my device, you still can't search your messages without a third party tool, attachments are deleted on file but not on disk..

It really hasn't been lowered. Most users aren't running the latest code, so you would struggle to ever get your transaction into a block that way.

Sort of fuzzy in some countries. In Australia categorising data is something not protected by copyright, say a phone books listings of numbers, because there's only one way to do that and there's no creative process involved. Some code could probably be argued to fit into that as well.

Neat idea, but that website needs some serious contrast. Almost unreadable when scaled.

Prolexic hosts this site which has for some reason kills connections from my entire IP address range (residential DSL).

Wonder what one of my IPv4 neighbors did to piss them off.

That's sort of nonsense, CoinJar beat them to it.

Something tells me you don't want the lithium in your batteries reacting with the water in the air.

> Assuming you mean "ditch the huge, thick coax connector", yes.

Whoops, lost a bit of meaning when I revised that sentence and didn't look over it.

I'm not really sure what to think of the whole "watch" thing, even if it is a real thing that going to happen I can't see it being anything like people expect it to be. Having headphones plugged in would be a little weird, I just tried it then by taping my headphones plug to my wrist and found it got tangled in almost everything I tried to do.

> I don't see much of an upside doing this.

Well you ditch the huge, thick lightning connector for starters. That's why the MacBook Pro doesn't have ethernet anymore, it's just too thick for the case.

From a practical view the original authors were anonymous, would they really shed that to sue somebody forking their code against the license? Probably not.

bitcointalk.org is spending millions on their new forum system that's being written from scratch. Hopefully that will be one to look out for when it's complete.

One of the core developers lost over 330 BTC to Mt Gox. Tell me they are not technical experts.

No, it's just why exchanges don't needlessly segregate wallets.

Segregated wallets doesn't work, that would mean every single trade would be a transaction on the block chain. It would absolutely flood the network and result in massive fees. It literally can't be done that way.

What the hell? When did I suggest that? Client side validation wasn't even a part of this, the rules are clearly enforced at the server as well.

> By the way, I made mention that perhaps they're encrypting the string, and not hashing it.

Encryption is the same, it's content agnostic. 20 characters doesn't make any sense with the size of a block cipher.

You've utterly missed the point of this.

If they hashed the user input, it wouldn't matter what the client gave them in terms of password requirements. Spaces, special characters, arbitrary lengths up to tens of thousands of characters would all be fine with a cryptographic hash, there's no way the resulting hash would be anything but a fixed length of n bytes. Nothing "evil" can make it through being hashed.

The password requirements Flickr has set show that they are not using a cryptographic hash, the limitations on length and character set imply that they are being stored incorrectly, either in plain text or a space delimited format. There's no reason to have these limitations if this were not the case.

Which begs the question why I was downvoted heavily and posted to @shit_HN_says for making the comment.

I'm very much aware of that. I'm saying that because they're disallowing the submission of spaces, they aren't hashing their passwords when they get to the server.

> they're checking the string server-side, before hashing and storing the hash to their persistent data store.

But why? People don't just add a rule because they feel like it, I'm suggesting that they are storing it in a stupid way that is not hashed and does not allow spaces.

> part of me would like to guess that the reason spaces might be forbidden in passwords (and pass phrases) would be to prevent frequency analysis.

The output of a cryptographic hash is completely random, you can't do any sort of analysis except for determining H(a) == H(b). You don't even know if H(b) was the same input as H(a) or just a collision against it.

No spaces in passwords? Obviously not hashing them.

Solution: http://archive.today/IvjNH

QR codes aren't the sort of thing anybody has been trained to click though, there's no other cue to even begin to suggest that it might initiate a payment request. To me that would just be a QR code of a Bitcoin address that is in plaintext to the right of it. Showing me this page I would have said there's no payment request support at all.

That UI stinks. Who would know to click on the QR code to open a payment request? A payment request doesn't even involve addresses that are visible to the user, it makes no sense that it is under "send to address".

No, the cost is due to scale. Producing ASIC chips involves millions of dollars of setup.

Bitcoin miners can not be re-purposed. They take a header input and output only nonces, not hash results.

Nothing. People make this mistake when doing legitimate things too. You're meant to make a new address for every single client. The response could be that they only send to unique TXID that haven't been used before, but you can always race it out by sending the email first.

Is there anything to suggest this is real? Classic scam would be to just sell a bunch of random data, people tried that when Mt Gox was compromised. People apparently provided "samples" on IRC with either random data or data from other leaks presented as being from the Bitcoin exchange.

A quick google search shows

• http://pastebin.com/L7CYznfK

• http://pastebin.com/4YRgEwPb

that have the same message with different bitcoin addresses.