I don't think anyone paying for blockchain access would be functional either in a practical sense or politically given the threat of centralization and the fact that how can I pay you coins from the chain without seeing the chain?

Running stuff through the script portion of the payment address has been theoretically possible from the beginning (though not enabled in the satoshi client I don't believe). Throwing more stuff on top of it won't improve the situation any.

If you were to do anything like that it's easier just to submit the hash of the document to the blockchain and host it yourself, if you go under there's no point to the contract anyway; or just use one of several legal services setup for that sort of thing who can do it much more effectively than shoving it into the blockchain ever could.

My guess for the eventual order of clients though is a large handful (or more) of rank 0 nodes who still do it for free, possibly governments and other larger bodies. Several well distributed copies held as small chunks of the chain across a large bittorrent-like swarm, and most people using light clients that only keep track of their information and a list of all header hashes back to the genesis block or wallet services (that would likely be based on a rank 0 node).

That the world isn't revolving around him. Burnside wasn't at his beck and call to process a manual withdrawal fast enough for his tastes. Not that the information about withdrawal delay wasn't already public both here on the forums and on the site itself.

The "proof of harm" was that he wasn't able to leverage all of his cash to short BTC against USD as the price continues to slide for several days in a row. So I'm not sure why it going down more today really matters compared to the $30 drop over the past few days and I don't think I really care to hear why, though I'm all but sure I will get to hear all about it.

Any data stored in the blockchain is stored there forever, I would however argue that it's wasteful to do. There also wouldn't be any way to charge a fee for such a service except as a service to automate the task, anyone can submit a transaction and anyone can read the blockchain freely.

I've got no reason to want to see this project scrapped. I'd say there are a large number of other mining ventures but I also think KNC has some of the better mining equipment across multiple important metrics. I just think there are better ways to handle sales.

See above if you haven't already, but you're probably in line now, and there isn't anything setup for withdrawal so you'll just have to wait it out unless you can find a willing buyer, and that would likely mean a large cut taken from the price as well.

Security aside, currently it's an admin and expecting him to sit there twiddling his thumbs waiting for a manual withdrawal is unreasonable. While a case might be made for quicker response if there were a handful of people employed by BTCT, but I'm not even sure what kind of time frame you're expecting if bitcoin confirmation times are too slow for you.

On the bitcoin blockchain or on the general cryptocurrency styled blockchain? I know there's some work to get pruning into the satoshi client and other clients who don't store much of the blockchain by default. Although for bitcoin there should always be at least a handful of copies of the entire chain somewhere all the way to the genesis block, at least under the current trust model for bitcoin.

While such a combination of features would be useful, I just think that they may be impractical together.

1. I'm not sure what you mean here, if a server alters an encrypted message it (should be, depending on the encryption scheme) is rendered unreadable. It's possible to cause the message to be unreceivable, but not to alter a message after encryption during transit. If you mean MITM because of poor key exchange, then that's a fundamental problem with key distribution not PGP in particular. The same problem (having to make sure key exchange is secure) would exist in any scheme.
2. Bittorrent users derive direct benefit from storing and sharing material. On public trackers you have the perpetuated availability of material the peer wanted in the first place. On a private tracker it maintains ration in addition to the previous. While there is also altruism (which would be all I can see this relying on), it's not infinite, and given only 100mb (or any finite quantity) per peer you will still eventually run out of space. The blockchain is useful to anyone who stores it because that's how you prove what has happened and already there a large number of "light" nodes that only store the block hashes and verify things separately as needed and don't store many blocks at all as well as several implementations (including the satoshi client) that are looking to prune the spent tx data to reduce the storage requirement (pruned data would be ~120 MB right now if memory serves). For larger file storage clients like Freenet (while file storage you can just think of files as binary messages (see: Usenet file sharing)) the incentive is that you store some extra data so others will save your extra data, though no strict parity is enforced and there is a certain reliance on altruism (and for this reason I don't think this sort of project is anywhere close to impossible, just harder). Since I brought up Usenet, there are basically superpeers that act as peers with each other and central servers for end users; end users normally pay for large data storage provided by central servers.
3. PoW does help, but the higher you make it the harder (relatively) it is for a normal user to send a message, the lower you set the bar the easier it is to spam. So while there is a tradeoff but it's definitely a solid place to start; allowing a user to establish how hard it is to send them messages might work. Rejecting messages from a node may be somewhat meaningless, you want to allow new users to be able to participate reasonably quickly and there's no way to select between a new user and a new identity for a malicious node. In addition to all that routing messages through the p2p portion means the physical source node might not be important, the identity of the sending node is all you can conserve on a practical level.
4. I was thinking this was along the lines of a PM system with optional twitter-like broadcasts, but if it's twitter and includes direct messaging a few things shift priority, but overall allowing any messaging TO an identity opens up all the same problems if it's the most common behaviour or not. Sounds kind of like most of the forums on Freenet though, everyone publishes their board posts to their personal broadcast stream and based on your direct trust level or indirect trust through WoT you choose whether or not to download their messages. The expensive part of creating a new identity is bootstrapping yourself into the network and announcing your presence so other people begin to download your messages to begin with. If you wanted to apply a similar mechanic at all you could start with a heavy PoW problem to announce your identity to other peers.
5. I'm used to seeing DHT as a lookup method, but you can easily tie that to looking up where to find/who to ask about a certain message certainly. I'd say the central servers archetype evolved before p2p was necessary or practical; if you wanted to share something you hosted it, if you wanted mail you sent it to the mail server (similar to the post office I suppose) and it was also easier to manage and there was no reason for it to go away. A lot of hosted platforms (especially closed source hosted sites like google, centralized mining pools, or anything requiring any central authority or a protected/hidden database to run) are either easier or only possible inside a centralized environment. Some things can be moved easily to a decentralized setup (file sharing from FTP to Bittorrent, central mining pools to P2Pool, etc) and some things are harder to move over (Anything abusable, anything that requires strong input checking, required hidden or protected databases). I'd also say that part of the reason webmail providers have so much information they don't need to have access to is that it's easier and established. There's no established default email or text encryption standard for transmission and the default is plaintext. If you could switch everything to encrypted transmission by default the webmail providers wouldn't have anything to begin with (other than sender/receiver and timing, which is also what the NSA was collecting on phone calls and is still powerful information and not eliminated in a p2p setup) but it's harder for end users, grandma doesn't care about PGP and grandma couldn't use PGP and wouldn't be able to use email if it were the default and the only option for her would likely be a webmail provider either receiving plaintext or decrypting it for her server side which means they have the contents anyway (you could do it client side, but then grandma has to carry her private key around and she can't do that either, also it's easier server side).

All told you've definitely addressed a lot of things, I'm having to insert a fair amount of qualifiers to things now, and a lot of problems can be considered corner cases (that I'd still personally like to see addressed in an active implementation, now is too soon for some of them before larger details are finalized). The biggest problem I still have is storage, I'm not sure the balance between indefinite holding and total potential storage is there yet, at some point it just runs out. Though I don't know that a two day window is enough for everyone either :-) If nothing else I can keep playing devil's advocate at least if you want to try to flesh things out more.

Thank god they don't give you the blink tag or we'd all have seizures. This just makes you look like an ass who hasn't read a thing, least of which the blatant information on the site you threw money at because you saw "+10%." Shut up, sit down, and if you feel like this was a mistake on your part then learn from it (if you don't, realize you're wrong and it was a mistake on your part and learn from it).

All ASIC deposits are queued until they can be filled with available hardware. I think all current deposits are set to ASIC deposits because of planned deployment in a short time-frame (or maybe even lack of additional FPGA hardware, I expect the former). You may be near the end of the ASIC queue, although I'm not sure how much of the ASIC queue will or won't be filled once all the hardware comes online, but I know Pyramining has said that the hardware won't all come on overnight at the same time so there will likely be at least a few additional days of delay after the first ASICs come online, more if your spot in the queue isn't filled with the original hardware.

Is there any reason not to broadcast the transactions without fees? I don't personally care if Deepbit mines my payment or someone else does it. It would also avoid the transaction not showing up relatively quickly for people looking for instant gratification and there's still no fee unless the pool wants to pay it. If no one else picks it up Deepbit can still mine it too so no lack of control. If the transaction hash is generated at the same time payment is requested the coins are already sitting there ready to pay out. So what's the downside? Or what's the rationale for this even? Maybe some brownie points and looking cool while it was a big pool, but waiting "several hours" before the transaction is even visible is a bit of a pain.

Most other companies aren't mining with as much of their own hardware. For example BFL is selling most if not all their units, and I expect the same of KNC and any other large group. The other problem is that mining has had an extremely high profit margin for a while (I would guess partially because of ASIC preorders and lack of new GPU/FPGA miners previously, which isn't the case as other companies begin to deliver more ASIC miners. Again, purely speculation though.) and if that is reduced revenue will decrease. A lot of where things get messy is can AM keep up with all the other players that are finally getting things together at scale. BFL just recently started shipping units en mass and is still clearing their backorder, KNC isn't shipping yet (and looks to have some of the most efficient hardware in GH/J on 28nm), and AM generally beat everyone else to the punch. They also only get money from a hardware sale once, after that they're adding mining competitors even if hardware sales is a parallel and viable business plan it's a different one from what they're currently doing.

They're still profitable and I have no reason to expect them not to be for a good while, but their margins, and returns, almost certainly will shrink within the foreseeable future. The big question left is how much and when?

1. This is a given for any private messaging system, it's also generally a more easily solved issue given existing systems like PGP or more generally with most modern asymmetric crypto.
2. An admirable trait, but to avoid storing it locally while keeping it accessible means that it still needs to be stored somewhere. Generally this is easiest when done by a central server or something of the sort, but to keep it decentralized means that someone else has to store their messages, your messages, as well as everyone elses. Not only that but since you want to be fault tolerant of a single peer leaving it has to be stored across multiple peers. All this storage also has to be pushed onto people that derive no inherent benefit from storing your unreadable messages. And how long is indefinitely? Until the account is inactive for a certain period (this also opens the can of worms that everyone has to know if the identity is active), until the account asks to be removed (if ever?), until someone runs out of storage space (highly random)? This is likely a large portion of the reason that bitmessage only keeps things for 2 days.
3. Spam is the bane of any messaging system, but to allow for number 1 anyone with your key must be able to message you. Generally publicly publishing your private key is the simplest way to allow others to communicate with you. To preserve secrecy of identity they have to be able to send it without disclosing too much information about who they are until you receive their message. All these together (and with number 2) mean that you're open to several different DDoS attacks (sending a large number of messages for you to decrypt and check if they're worth receiving, even if all you end up doing is running against a spam filter. Storing spam mail. Manually tuning a spam filter of some sort. Transmitting spam for yourself and others. And I would guess several others not mentioned here).
4. This generally sounds like a useful feature, but be care has to be taken with implementation to avoid possible abuses. Very possible though.
5. This just makes all the rest of it more difficult as you have to make sure other people are willing to volunteer the resources, requires certain tolerances to peers leaving the swarm, and means that you can't depend on a lot of the nice features a central server allows you (while avoiding the problems a central server creates of course).

All that said, you may want to see if an existing setup would work just as well, throwing the blockchain idea at everything doesn't always help anything at all. One existing setup that you may want to have a look at is Freenet (a P2P censorship resistant, data storage network where data can include text messages of course) and the various forum implementations therein (FMS, Freetalk, Frost, and the email-like plugin that I forget the name of). They're all fairly different but may help you skip past past issues they've already encountered and build upon areas they've had success in. Some of the things in particular to take away are tradeoffs in storage, availability, duration of messages, and privacy. Web of trust may also be a useful thing to look at, and is featured in most of the forums.

Naysaying aside, good luck if you go forward.

Without knowing future difficulty it's impossible to say that dividends will always increase. With reinvestment (either DRIP, manual purchase of additional shares, or reinvestment by the security itself) you can increase your stake and total hash speed. Any reinvestment strategy will increase total dividend (sum, not rate) at the expense of greater total investment in the company itself.

Kind of my thoughts, not quite pleasant, but not that big of a problem.

Any way to setup auto-deposit from an address, this was a handy feature for me. Perhaps as a feature request on Inputs? Addresses available that automatically pay another account upon deposit.

Sorry to all affected, my account got hacked and someone was posting alongside me normally so I never noticed it. Please do not run anything previously posted as it probably is a virus or at best not something you want running on your computer.

I think 7z is more popular on Windows because it works well there and the tools work as well or better than anything else (including bzip/gzip/etc) on Windows, I don't have any experience with the Linux/Unix version though.

On another note, there's already a BIP that might help (standard, not sure if there's a PHP implementation) BIP 32, it allows for generation of public keys in a predictable manner without knowing anything about the private key, even for freshly generated keys. The receiving wallet doesn't need to communicate with the server or vice versa at all. Even if the server is compromised all the attacker should be able to learn is what public keys belong to you; normally there is no way to correlate these public keys to each other (like generating a large number of random keys).

Maybe not the simplest thing to add, but is there a way to add an extra page after normal login (instead of redirecting to /portfolio or elsewhere) that could force extra auth, then allow users to adjust their own security (as is currently done for 2FA). Alice doesn't care and just uses a password and no heuristics. Bob uses 2FA and wants a second form of 2FA to be required if his country/browser/OS leave some predetermined list (usual or manually set). Might also be a way to separate login and normal 2FA similar to some two-step logins that are touted as more secure (I know my bank uses it, remembers my username and it shows as "btha******" then asks for password on the next screen), though I've never understood why it's supposed to help if there's no extra steps beyond the normal password.

I am not selling shares (I don't even own shares), someone is attempting to use my account to scam though and I apologise. DO NOT SEND ME MONEY. Thanks.

Hacked account, my apologies to all. I do not have and am not selling any AM shares.

If the exchange requires 6 confirmations then an hour on average is way too long for most arbitrage, one confirmation would probably be too long for a lot of quick trades. Confining everything to a few centralized servers (Exchange 1, Transfer Site, Exchange 2) could be faster than sending a transaction through the network; of course if you could get the exchanges to connect directly to each other or through very few hops that would help, but then they have to trust each other as well.