Re: Timestamp on Transactions


Definitely agree with this Richard. 
How is the width of the time-range calculated/defined? Is it sensitive to network latency, load, and server clock errors?

I'm thinking that in a leaderless multi-node notary cluster, where there isn't a single unified clock, timestamps and windows cannot be used to order transactions in a consistent way.

The premise being that in any lock-free distributed system (e.g. the notary), a unified clock, in the general case, is not possible, right? Clocks drift and no algorithm is perfect in keeping synchrony (I'm sure we all have our horror stories here). 
LAN clusters like Coherence use involved algorithms and heuristics to compensate for server clock errors, but I've seen them go wrong before. Allegedly, Google's Spanner TrueTime is an exception.

One of the earlier posters said that this doesn't matter as long as transactions can be grouped in a coarse-grained range. I wonder if the use-case is sensitive to close-to-midnight transactions.

PS Is this the moment we can invoke Special Relativity? ;)

On 9 May 2019, at 16:21, richard via Groups.Io <richard@...> wrote:

It definitely makes sense that a node should have the ability to record (for its own use) what time it thinks various things happened (eg the time it thinks it proposed, or signed, or received, a finalised transaction, et) – and that’s what I thought this discussion about database tables was about.  I does feel like a gap/oversight that we don’t currently record something useful here.  *Mike* - I think you were suggesting we’d look favourably on PRs in that area?
However, as James hints, the question of timestamps upon which _other_ parties rely is harder.  Put bluntly, a “transaction proposed” timestamp James attaches to a transaction is not actually the time he proposed it. It is the time he _claims_ he proposed it.  And it’s hard to think of many situations where anybody else on the network could or should rely on that.  And I happen to know James is a pretty honest individual……
When you take it further and work through real examples one quickly concludes that you have to delegate some of this to the notary cluster.   One particularly useful thought experiment was that of an option with an expiry time of midnight tonight.
Imagine I own that option.  If I can simply assert the time at which I exercised it then I could try to exercise it at 00:01 tomorrow (after expiry) but put a timestamp of 23:59 today.  That’s not going to work in the real world of course.   So what if we say: ‘you have to get the transaction signed by a timestamp oracle’?  Well… I could get it signed at 23:59… but then hold on to it until tomorrow…. Maybe it was out of the money today but turns out to be in the money tomorrow…. So I now reveal the transaction and you have to, say, deliver the underlying asset to me. I’ve effectively just stolen value from you.     
Follow through the logic and you end up concluding that “the act of securing a timestamp upon which other people can rely” has to be coincident with “the act of confirming the transaction”.  In other words, the notary has to be the timestamp oracle.   Hence the (weird when you first encounter it) approach of asserting a time range in a command and then inviting the notary to countersign only if the notary’s time is within that window.  Any other approach leads to opportunities for clever gameplay.
But, that all said, if you just want a local record of when various things happened from your perspective, we should definitely make it easy to do that!
Richard G Brown R3. | Chief Technology Officer
2 London Wall Place | Floor 12 | London | EC2Y 5AU
M: +44 7764 666821 | T: @gendal
From: <> on behalf of "James Brown via Groups.Io" <james.brown@...>
Reply-To: "" <>
Date: Thursday, 9 May 2019 at 16:09
To: "" <>
Subject: Re: [corda-dev] Timestamp on Transactions
Where's the integrity if the timestamp isn't part of the signature? i.e. if it's a separate column, it doesn't truly form part of the transaction because it's not signed over, righr

Join to automatically receive all group messages.