I don't suppose you can reduce the limits based on ignores?  I'd reduce the number of PMs per hour by the number of ignores the user has earned.  Of course, it would be less harsh to reduce their effective activity by the number of ignores.

Have a link for that?  I tried a bunch of searches looking for the technical details, but all I could find was ways to enable it on my gmail account and get SMS, so I assumed the worst.

Just another scammer inflating their post count to circumvent the PM sending limits.

By now, there are so many threads on quantum computers that to have missed them all is simply impossible.  Just typing the word "quantum" into the search box gives 28 pages of results.

We need a time out corner.

Perhaps you should ask mtgox for support.

Fuck this, and fuck google.

First, you don't ever leak security state information to attackers unless you really must.  Second, for a forum devoted to private money, there sure are a lot of people in this thread very eager to tell google their every move.

Read the text.  TN has an income tax on interest and dividends, not wages.

EC math is magic. 

You don't really embed the secret number, you provide the product of the random number * G.  You may recognize that as the same operation that produces your public keys from your private keys.

Which would make sense, if the sender had some control over the timestamps.

I know that you've been around long enough to know how to search.  Are you really going to make us list all of the reasons why this is a bad idea yet again?

Replace that txid with the txid you want to see.

Basically, you look up the transaction you want to see.  Loop through the vouts and add up the values.  Then, loop through the vins and do another lookup on each of them, add up those values.*  Subtract the second value from the first value, and you have the fee.

* When something is a vin here, it was a vout in a previous transaction.  You look up that previous transaction by txid using the same call as above, then just ignore everything except the vout that you need.

I have visions of sysadmins frantically purchasing new drive after new drive to add to their servers, all sitting empty.

Hint: with the current block size limit, a 1 TB drive will die of old age long before it fills up in 2032 (at the soonest).

The device you are talking about sure sounds hackable to me.

Also, biometrics are not useful here.  Or, at best, they are of very limited value.

Probably.  You can embed a certificate fingerprint in namecoin's database.

The problem is the client.  There is a whole big chain of trust that needs to be managed between the client validating the certificates, and the authority for them.

Also, note that namecoin is going to be absolutely terrible at mapping namespaces to real world entities.  If there is a big real world entity that you know about, odds are very good that someone else owns most variations on that entity's name and trademarks.

And then there is typo squatting/phishing.  We end up in a situation where users must be very carefully compare the namecoin token to be sure they are fetching the right fingerprint.  This is a rather modest improvement over carefully comparing the fingerprint itself.

PKI sucks, and key management in particular.  Anyone else remember the late 90s, when encryption was reclassified from "munition, not for export" to not-munition?  Real security depends not only on good math, but also on good practices.  Perhaps someone in the NSA realized that we had no hope of developing good practices, so they decided to let us distract ourselves with good math.

I use old school command line torrent programs for this stuff.  They don't understand magnets.

But I'm not sure why you'd need a magnet anyway.  Are you having problems downloading the .torrent file?

0.6.4 has been released.  The initial post has been updated with a link to the torrent, and 2 seeders are already active.

It includes bitcoind 0.8.3 for lower latency, p2pool 13.0 for the new hardfork, and bfgminer 3.1.1 for better PGA/ASIC support.

I've been running mine with ASICMiner USB sticks since Friday, and it works great.

*sigh*

You need some way to authenticate the payment blocks.  Despite their many, many flaws, the SSL CA system is still by far the best way we have to do that.  You can still use self-signed certificates if you want to.  Personally, I'm hoping that the growing public awareness of CA abuse will spur people to finally develop a better system.

No, this is not a protocol extension.  The payment system exists outside of the bitcoin network.

The information in the payment protocol (such as the return address) is not included in the block.

The payment protocol is the API for signed messages containing metadata about transactions.

The requests will only be public if one side or the other publishes them.

Pruning has not been delayed "over and over" in favor of trivialities.  There are prerequisites that needed to be followed.  The Ultra-prune branch in git, for example, didn't actually do pruning, it was a collection of work that needed to be done before pruning could be implemented.

I'm sure you could puzzle it out by using the raw transaction decoder.

But why would you do that?  Unless you are also the miner of the block that included that transaction, you don't care about the fee: It isn't yours.

Heh.  I never said that it was supposed to happen.  I was just pointing out the workaround used all around the world by people with unreliable power.

Maybe we should make a sticky at the top for bug reporting best practices.

Decentralized means "no one can stop you", not "everyone is doing it".