I have been writing the specifications, and I noticed a problem and then found a solution. I would appreciate some feed back to make sure my solution is good.
The problem
The value tangle needs timestamps so we can have a below max depth rule: the difference between two messages is less than Delta. We do not want to vote on timestamps on this layer, and so we would like the timestamp of a value object to be the same as its containing message. But this is not well defined since a value object can be reattached in multiple messages all with different timestamps.
The original solution was to always take the timestamp to be the smallest timestamp of the messages containing it. This seems to work fine, except for the following:
- Suppose a new value object v references u and the difference in timestamps is greater than Delta. Then v fails the below max depth criterion. But, if u is reattached, I need to recheck the validity of v.
- Any application that uses timestamps has to work though all these uniqueness problems, and make sure nothing bad happens. This adds complexity to the protocol.
My solution
Have each value object contain a timestamp, but require the timestamp to be the same as the containing message, otherwise (that attachment of) the value object is deemed invalid.
Pros
- Simple: easy to understand and implement
- The timestamps are completely unambiguous
- The timestamps on both tangles behave in the same way
Cons
- Value objects are a little bit bigger.
- A value object can only be reattached in messages with a bad timestamp. In particular, after time w, the value object cannot be reattached. However, the transaction contained in the value object can always be reattached in a different value object message pair, and so (unless I am missing something) this does not seem to be a problem.
- The message creator is complicated. Ideally, a message can be created completely separately from its payload. However, with this solution the timestamp would have to be the same. Moreover, the timestamp of a message is changes as the proof of work is done. Thus the payload of a value message would have to also change as the proof of work is done.
Alternative
Value objects which violate the below max depth criterion are sent to a buffer, which we periodically check if they become good.