Yeah, long-term data storage on the blockchain will never be a day-to-day backup solution, but there's a whole class of applications where the cost is worth it.
Sensitive data that should be preserved at all costs?
Yup.
Heck, I uploaded the very first computer program I ever wrote to the blockchain a few months ago.
There's a whole range of applicable programs that could be built on top of a data-neutral messaging layer. I've wondered about how a peer to peer marketplace for selling of goods and services could be done. One guy can (semi-)anonymously broadcast an "I've got a TV for sale for 4 BTC. Send me a message, here's my RSA public key."-style message. An application can take care of sorting through and searching available offers, building responses, reputation, etc. Reputation can be done with more proof-of-sacrifice sends. All really fascinating scenarios, really.
Yup. You'll probably find that at some point the fees per KB simply become too expensive, but that's just a practical consideration - figure out what parts of the system are best done on the blockchain, and what parts on a secondary system. For instance when someone has committed fraud and you want to destroy their reputation, the guaranteed wide audience of the Bitcoin blockchain may be worth the higher cost.
Nope, I just mean the txid:n pair, also known as an OutPoint. (from the COutPoint class in the reference client) That you don't need a full-weight client for, as you already know.
Anyway, if you're using the txid as an IV I think you've already met my criteria just fine!
Ah, right. I could have used the input_n in the hash, but the tx hash should be enough right?
Re-using IV's is often very bad and leads to plaintext compromise. Having said that, here we're using encryption for censorship resistance and steganography, not privacy, so the odd IV re-use isn't a disaster. Still you should avoid it, and including the input # helps. Come to think of it, including the nSequence of the first txin and the nLockTime of the whole transaction would be a good idea too as it's been
proposed to alway set nLockTime to the current blockheight to discourage fee-sniping, thus really reducing the chances of accidental IV re-use. Point being, doing that in the future may be totally normal, so a transaction that does that won't stick out, and in the meantime including them in the calculation of the IV does no harm.
Well, then you don't end up with any more data space than regular pay-to-address. Are you suggesting that pay-to-address/scripthash is better at disguising messages than a 1-of-M multisig tx? If you use the 0x04 prefix on the public keys in the multisig transaction, you wouldn't be able to tell if they're real keys or message data.
Again, the point isn't to be efficient, it's to allow the creation of "stealth" data-encoding transactions whose existence can't be proved unless you have the secret key required to decode them.
It would be interesting to see what this could actually reveal. Anyone who's really interested in protecting where the message comes from could connect to tor and broadcast through blockchain.info/pushtx.
I've got Tor support in my
dust-b-gone tool that you might find instructive.
