Receiver-pays transaction fees required to handle expired demurrage transactions

[maaku]

The transaction-generating code adds a fee to compensate for expected demurrage until the block is confirmed. Currently it adds 12 blocks of demurrage, but that could be reduced to just a few blocks if a mechanism is put in place for including "expired" transactions.

I propose that mechanism be receiver-pays transactions: if a tx expires (nValueIn < nValueOut due to continuing demurrage), then one of the receivers may issue a transaction claiming those funds and adding additional fees to cover the loss for the miner. As a consequence, negative-fee transactions may make it into the block chain, which is currently a big no-no but should be acceptable so long as there are sufficient fees covering the loss.

[mhredmond21]

I have to say this is a brilliant solution. It would provide a major incentive to always be holding at least some freicoin. As attractive as it is it may be too technically difficult for the moment.

[maaku]

Well I don't think it's crazy-impossible. It's just not as easy a change as some of the stuff we've done so far.

Incidentally, this is a great feature to back-port to bitcoin, where it would be useful for speeding confirmation of zero-fee transactions.

[maaku]

Steps forward for this one:

1. We need to inventory locations in the code where nValueIn is compared with nValueOut. This is known to occur more than once due to redundant checks and for other purposes.
2. We need to remove those checks that reject transactions if nValueIn < nValueOut, make sure that the reported fee for such transactions is negative, and add a check that rejects blocks if nSubsidy + nFees is negative.
3. We need to setup a proactive service that monitors for expired transactions with outputs owned by the wallet and generate claiming transactions.

[maaku]

I'm marking this as pre-release. For the beta it will be sufficient to implement demurrage-payback addresses.

[maaku]

This is getting pushed to Someday/Maybe. The new system of proportional demurrage-payback pretty much eliminates the special need for receiver-pays in most use cases. It is still a valuable concept to implement, but for the different use case of letting receivers pay more in fees to have their transaction processed quicker. Such functionality won't be needed until such time as transaction fees are required in order to get on the block chain.

It is likely that this will be implemented in bitcoin first, as they are currently dealing with these sorts of problems.

[maaku]

I can confirm that the current version of Bitcoin and Freicoin handle dependent transactions properly. However the CreateNewBlock function in main.cpp does not allow for follow-on transactions to affect the priority of their inputs. Presumably mining pools have their own transaction-selection algorithm, however, so we can consider this a problem that the free market will solve.

The only remaining issue then is one of adding a capability to the base client to "claim" funds that have laid stagnant in the mempool for too long by spending them in a transaction with a higher fee. This could be done either manually from the “Transactions” tab, or automatically according to some preference.

However this feature is not required at the moment or in the foreseeable future, so back on the Someday/Maybe pile.