Fees in BitDNS confusion

A bunch of the current debate about including BitDNS or BitX makes assumptions that miners will include transactions or not based on some rather fine-grained conditions, while none of the standard code includes any sort of implementation that allows non-programmers to make decisions like that.  How will I, the user, figure out what sort of fees have to go into a transaction?

It would be nice if there was some way that using the standard client you might be able to adjust the fee schedule for your own purposes and set "policies" for mining blocks and including transactions.  I think that is a source of confusion here as no such user interface is currently provided for doing that.

Much of this is all theoretical at the moment because it is possible to make transactions "for free" and generally get them included in the next block at the moment.  I don't see that is going to be sustainable in the long run, but we'll see how that goes.  At the moment, it is important that most people using Bitcoins are simply hoping that the currency succeeds at all and aren't interested in making a killing or even a modest profit at it, which is why transaction fees are still mostly non-existent on the network.

Yes, although I don't think the canceled transaction protocol is necessarily complete in terms of its current implementation.

See also: http://www.bitcoin.org/wiki/doku.php?id=bitcoins_draft_spec_0_0_1#tx

The "version" field allows somebody to send out a new transaction that effectively replaces an existing transaction with perhaps some new data.  As long as the transaction hasn't been accepted into a block, in theory you can "recall" the transaction and modify the transaction in any way.  Like I said, this is incomplete and the exact protocol to pull that off hasn't been included into Bitcoin yet.  But it certainly is a possibility and may be a feature in a future version of Bitcoin.

Certainly the ability to "recall" a transaction hasn't been implemented yet in the UI, and once the transaction has been accepted into a block the only hope to really kill a transaction after that is to hope that the block doesn't get accepted into the main block chain.  Then again, if the transaction has been accepted into a block without fees it shouldn't be a problem in terms of recalling the transaction for adding fees either as the issue is moot at that point.

Not locktime.

There's a possible design for far in the future:

You intentionally write a double-spend.  You write it with the same inputs and outputs, but this time with a fee.  When your double-spend gets into a block, the first spend becomes invalid.  The payee does not really notice, because at the moment the new transaction becomes valid, the old one becomes invalid, and the new transaction simply takes its place.

It's easier said than implemented.  There would be a fair amount of work to make a client that correctly writes the double-spend, manages the two versions in the wallet until one is chosen, handles all the corner cases.  Every assumption in the existing code is that you're not trying to write double-spends.

There would need to be some changes on the Bitcoin Miner side also, to make the possibility to accept a double-spend into the transaction pool, but only strictly if the inputs and outputs match and the transaction fee is higher.  Currently, double-spends are never accepted into the transaction pool, so every node bears witness to which transaction it saw first by working to put it into a block.