Quote from: vector76 on August 10, 2011, 07:17:07 PM

How would you want to handle the problem of rounding?

Not that I think it will have a lot of financial significance, but it is possible to get into situations where multiple txouts could yield slightly different total value depending how they are spent.

I have to admit that I haven't though much about problems related with rounding errors. Can you give an example of a problem that could raise?

Quote from: vector76 on August 10, 2011, 07:17:07 PM

There is also the problem of agreeing on time, and even the time between when a transaction is issued and when it is included in the block chain could make a transaction over-spend its (now shrunken) inputs, or create other sorts of "slightly off" errors. It might make sense to define the demurrage time in terms of the block chain and not in terms of 'wall clock' time.

Like I said here I was thinking in account the demurrage by blocks instead of years. This way we take advantage of the "internal clock" of the network.

Quote from: vector76 on August 10, 2011, 07:17:07 PM

An alternative is to have the underlying implementation store non-shrinking coins as they are now, with no demurrage, and to change the user interface to map a nominal demur-coin to the underlying non-shrinking coin according to a formula. Then the underlying implementation would be represented in terms of coins-at-a-particular-point-in-time which are converted to present nominal demur-coins by a pre-determined time-dependent ratio. There is still the problem of 'slightly off' errors if someone is asking 1 DMC in payment and you make the 1 DMC payment but by the time they receive it they get only 0.99999999 DMC. If this is a human recipient it makes no difference but an automated payment processor could reject it.

Yes, the idea is to not touch the blocks once they're hashed and just interpret the balance of each output taking demurrage into account.
All the inputs less their demurrage have to be greater or equal than all the outputs for a given transaction to be valid.

I didn't saw the problem of specifying an exact amount. Even if the change (the one that goes back to the sender) takes the losses from demurrage, you have to specify what is the "change" output. You also have to specify either the block count when the transaction was created or the transaction fee explicitly if you want to ensure you pay a transaction fee.
If we consider the later option, it could be an example:
Output 1: 50 (to the recipient)
Output 2: 49.98 (your change back to you)
Output 3: 0.01 [tx fee] (to the miner)
Output 4: 0.005 [losses from demurrage] (back to you if is not all spent)
Output 5: 0.005 [tx fee] [losses from demurrage] (to the miner if is not all spent)

Probably output 5 can be removed and any input freicoins not redeemed in an output are considered a transaction fee if they're not consumed before starting to charge output 4.
If both output 4 and 5 (or frc not claimed by any output) are spent, the transaction becomes invalid and will no longer be able to appear in the chain.
The unclaimed coins are the first that are going to perish by demurrage, so if you want to ensure you add a transaction fee the indicator is needed for a special type of output (maybe just sending the coins to a null address known by the network).
To indicate what is going to be the losing output, the convention could be that it is the last output. If you want to limit the minimum change you're going to receive you can add two outputs to the same address.

This demurrage is only to be applied if the inputs are less than the outputs and until the transaction is in the chain. After that all outputs suffer from demurrage in the same proportion.

Thank you for pointing out the problem.