I thought bitDNS would use one transaction output (with 0 value) for storing the the DNS data (the IP, the URL and whatever else is needed) and other output for "parking" some coins and "lock" the transaction, preventing it to be forgotten.
No. The 0-value output is used to store data. The other output is used to show ownership: you send this coin to transfer the domain. You also need to send the valued output for every new BitDNS command.
The valued output isn't necessary for "locking". A transaction can have just a 0-value output and still be "locked".
Our BitDNS spec wastes a lot of space because the 0-value transactions will exist forever. They can't ever be redeemed. But this is only necessary because our spec -- designed to work with current code -- writes the outputs in such a way that they are irredeemable. If script could be used freely, the 0-value outputs could both contain data
and be redeemable. This was the original design, in fact, but IsStandard was created while we were writing it.
You want 0 value outputs to be remembered until the receiver sends them out?
What is the incentive for miners to remember 0 value outputs?
Miners
must know all unspent transactions, or else they risk ending up in a situation where they need to verify a transaction but are unable to do so. If this ever happens, they will have to stop mining until they get the needed transaction, which might be difficult.
When they receive a transaction with an input that they don't know but that input doesn't add value to the transaction, they can just accept it as good.
Inputs don't state what its value is, so the miner can't know that it's a 0-value input if it can't see the associated output. It would be clear that no value is taken by the outputs, but you can't determine the fee, which is necessary for verifying blocks. (Rejecting transactions like this is also impossible for other reasons.)
Maybe they could take the risk of accepting blocks they cannot completely verify if that increases their hash rate.
Forgetting transactions will usually slow down mining somewhat, and sometimes it could cause very unprofitable things to happen.
Example:
You are using a client that forgets unspent 0-value transactions after a while. 10% of the network is also running that code. I create a block with a transaction that redeems a 0-value transaction, and most of the network builds on my block. If you reject my block, you are isolated from the network. If you reject my block initially, but start working on it later on, you've just wasted a ton of hashing work. If you accept my block blindly, and it turns out that the transaction is actually invalid later on, you've just wasted a ton of hashing work. Your best option is to immediately find the transaction being redeemed so you can verify it. First, you'll contact your peers to see if they have it. If they don't, you'll have to connect to more peers. Maybe you'll use an archiver service. This is a second or two of wasted hashing time per transaction you need to look up. An attacker might create lots of these transactions just to mess with you.
You actually end up giving up quite a bit of mining power for some disk space.
If your side has more than 50% of the network's computational power, your side can reject transactions with impunity for as long as it is in control.
