You can't prune unspent 0-value outputs because they can be redeemed, even though this would be useless. You can't necessary prune unspent known-to-be-data outputs because the script can both contain data and be redeemable.

Detecting data transactions based on entropy would be error-prone, since true randomness has a chance of being apparently low-entropy.

Deleting redeemable outputs is dangerous, since you could end up in a situation where you need the output to verify a block, but none of your peers has it. No matter what you do with the block, you might end up on a separate chain.

If we really got stuck that badly, a new version of Bitcoin would be released that changed the difficulty rules. I doubt it will ever be necessary, since an attacker would need a ton of computational power, and the build-up of transaction fees would incentivize increased mining.

With PostgreSQL you could do this:
I don't know if that would work on MySQL.

AES-256 needs a key of exactly 256 bits (128 bits for AES-128, etc.), so you often need to lengthen the password. It's also good to make a key of random bits instead of just ASCII text. So you hash the password with SHA-128/192/256, get 128/192/256 bits of "random" data, and use that as the key. Salting prevents the use of rainbow tables, and using multiple hash iterations slows down brute force attacks against the password.

If your password is somehow already exactly key size bits of random data, then you can use that as the key directly. One example of where this is useful is when you're encrypting a swap partition on Linux: the key can come directly from /dev/urandom, since no one needs to know it.

The show could have been very good if the hosts would have moderated the discussion so that Gavin had a chance to speak. Genjix is very good at building excitement -- we just need Gavin to balance that out with some reality.

Gavin interrupted more than I would have been able to... I hate these kinds of situations.

It is considered invalid and rejected.

If we can get very high-speed Internet, count me in!

I'd use it to make more money. Probably I'd start a business or two.

I can't think of many luxury things I want, though I have always wanted an ISP-level Internet connection with a large block of IP addresses. Once I become even more rich, I might buy an island.

It's the hash of the public key, plus some other stuff. You can't create arbitrary addresses.

OPs can move their topics back if they disagree with moves. Then we can have a discussion about whether it was appropriate.

A few of kiba's recent moves were unnecessary, IMO. I try not to move topics unless almost all people would agree with my categorization.

This is also how I think the spam problem should be solved for relaying. A drop probability should be weighted by fees and priority. If the transaction is important, it will be resent.

I send transactions all the time, though I'm still using 0.3.15 on my main wallet. This doesn't have the priority requirement, and the size limit for a required fee is higher. I do manually add a 0.01/kB fee for important transactions.

Sorry. I thought I tested for stuff like that...

I added those excludes, plus some more checks:
http://pastebin.com/5aTU768g
My post is updated.

Does your algorithm easily handle increases in precision like the current system does?

I don't like that the end state would be changed. People signed up for particular rules. The end total BTC is very similar, but 132 years -> 93 years is significant.

I've never been asked to pay a fee.

They're locked, so they'll get pushed to the bottom eventually. I think it's better to create the redirection threads than to leave people confused about where the threads went.

I created subforums.

Topics will remain in the outer marketplace section if they don't fit neatly into one of the subforums. For example, an announcement of a new exchange would go in the outer section.

For people scanning the counts, the existence of so many subforums might be a clue that the count is wrong.

Here you go:
http://pastebin.com/5aTU768g

There are already MX records, though, which I believe would override the A record in mail delivery.