Seems like a bad idea: adding wealth destruction to a currency that is deflationary by design. It is also unnecessary.
Take 2 addresses that you control. Send not one transaction between them, but inside a sequence. Say you want to encode a 512-bit hash, split it into 29-bit chunks. Encode each chunk as the low-order bits of the transaction value so each transaction may cost up to 1BTC.
Send each transaction from address-1 to address-2 and then back to address-1 (no net change in balance).
Treat the entire sequence as an encoding of a hash (looping transactions between addresses with values under 1BTC).
Seems like a bad idea: adding wealth destruction to a currency that is deflationary by design.
Meh, we're talking about a tiny fraction of Bitcoin. Plus since Bitcoins are essentially infinitely divisible if you destroy a Bitcoin you're essentially just increasing the value of everyone elses' Bitcoins very slightly.
Your solution requires numerous transactions, which a) bloats the blockchain unnecessarily, increasing costs for everyone else, b) also costs you Bitcoins in the form of transaction fees, c) takes a long time to complete.
The OP_RETURN Script opcode allows you to include arbitrary data in a transaction, and that's exactly what an existing solution, Proof of Existence, does: http://www.proofofexistence.com/about
So what? Worst case scenario, the attacker gets control of the BTC before the user can recover them, but that's no worse than the original proposal, where the value would always be lost
Well, how could you prove that you were the one that inserted the value into the blockchain? If anyone can have the key, anyone could have inserted it.
If any money was ever sent to the address generated by the hash of the doc, even if the current balance at that address is zero, proves that that document existed at the time money was sent.
Why care about ownership?
Take 2 addresses that you control. Send not one transaction between them, but inside a sequence. Say you want to encode a 512-bit hash, split it into 29-bit chunks. Encode each chunk as the low-order bits of the transaction value so each transaction may cost up to 1BTC.
Send each transaction from address-1 to address-2 and then back to address-1 (no net change in balance).
Treat the entire sequence as an encoding of a hash (looping transactions between addresses with values under 1BTC).