Transaction timestamp about catapult-rest

[Vektrat]

@evias what do you think? should this fall upon REST's hands? or SDK?

it is true that it'd be comfortable but the timestamp belongs to the block, when you fetch transactions from REST i believe you usually do it via block height, so i think it makes sense to keep it as it is

additionally, i'm unsure how "correct" it is to assign a timestamp to a transaction, i believe a transaction does not have a timestamp, it would still be the block's timestamp, wouldn't it?

[decentraliser]

When using the method getAccountTransactionsById, to list an account's transactions, the transactions are fetched from the account/publicKey endpoint.

The pagination parameter is the transaction Id

I understand the point of view of a transaction not having a timestamp as it belongs to a block.
However, on a front end development standpoint, a timestamp giving an indication of when a transaction has been included in a block is definitely needed.

Taking Etherescan's API as a reference (I am using it extensively), a timeStamp is provided in all the transactions or smart contract events objects.

Reference: https://etherscan.io/apis#accounts

[Vektrat]

I still believe the timestamp does not strictly belong to a transaction, at the same time I see how it is obviously useful, but I think maybe there should be a more user-educative way to show the timestamp, via frontend (such as show block id, with block's timestamp next to it, not sure).

If this is true, even if timestamp was returned with the transaction, it should be returned under the field blockTimestamp or similar - but again, I'm not sure if this strafes away from a RESTful server, where if you want a block property, you need to request the block data, though again: i understand that this would be comfortable ^^

Either way I'm not as fond on blockchain background as others in this matter, so maybe @Jaguar0625 or @dgarcia360 can give more input, I prefer to hear their side on this because I trust better their judgement on such decisions.

[evias]

I would actually agree that this is probably best fixed in SDK side as we probably don't want REST to "hide a request to get the block timestamp" ... and also I agree with @Vektrat that we shouldnt be speaking in Timestamp here but probably in block height.

Same as we did getEffectiveFee - there can also be getConfirmationTimestamp or something similar.

That will make it easy for you @decentraliser as you will be querying the timestamp easily, and in case we see that this is not enough we can still ask REST to implement it with some cache at some point.

[decentraliser]

This is not a problem of difficulty for me, it is a problem of performance. I just adapted the code of the browser extension and it becomes significantly slower.

If you judge this need is a common use case, I think it would be worth to run some tests.
My understanding is that if it is done at the SDK level, it will not solve this performance issue, except if the piece of code I have written can be significantly optimized.

`
accountHttp

.transactions(publicAccount, new QueryParams(pageSize, currentId))

.pipe(

    flatMap(x => x),

    concatMap(x => blockchainHttp
      .getBlockByHeight(x.transactionInfo.height.compact()).toPromise(),

    (x, res) => (
      {
        ...x,
        timestamp: res.timestamp.compact() / 1000 + timestampNemesisBlock,
      })),

    map(formatTransactions),

`

[jontey]

would adding shareReplay() help?

[decentraliser]

afaik shareReplay is useful when several elements consume the exact same data.
Here the issue is that there is one distinct call / blockNumber / tx

it would help for users that have many queries in the same block though, I'll add it

[evias]

@decentraliser how about this:

• for a list of transaction, take the first transaction and hA = transactionInfo.height.compact();
• then take the last transaction and hB = transactionInfo.height.compact();

read hA and hB from network to get timestamps of both tA, tB. From there you can take a difference of blocks diffH = hB - hA as the total blocks generated in between all the transactions of your list. Then also take the difference in timestamps diffT = tB - tA and divide it by the number of blocks blockTime = diffT / diffH.

Now you have the actual block time and for each transaction that you iterate you add blockTime x counter to tA.

That is not optimal, but will be more performant for cases where txList.length > 2 as it will reduce the HTTP calls for block data.

Unsure if this can be applied for legal data as time is actually "calculated / averaged" .. Glad to hear feedback on this.

[tinytintoy]

Hi there. I think the transaction timestamp is useful to represent the lifetime of a signed transaction, regardless of the timestamp of the block.

I have planned to make subscription service (on nem1) and timestamp parameter on a signed TX helps me to make it.

The idea of the subscription service on NEM is below.

---

1. A buyer make a new addresss, called address A, and send XEMs to it.
2. The buyer signes a bunch of TXs with future timestamp, e.g. on the 1st of the month for a year, with the private key of the address A.
3. The buyer sends TXs, as text data, to the provider of a service.
4. The provider releases a TX to the network, e.g. on the first of every month, to get paid from address A.

---

Does it make sense? This idea needs the transaction timestamp to prevent the provider from stealing the deposit.

[evias]

@tinytinboy probably you could solve this with secret locks / hash locks if you store timestamping data with block listener active.

@decentralizer i am thinking a bit more about it and what happens if SDK adds something like 'getTimestampedTransactions()' to potentially also query more than one block at a time. This would optimize quite a lot, dont think its rest issue, mind create a task in sdk with: "Add TransactionHttp.getTimedTransactions()" or something like that

[decentraliser]

@evias I just saw your comment, I think it would be nice!

would you do it with a block extrapolation as you suggested before, or call the block endpoint for each transaction?

[Vektrat]

closing this since it was already discussed that adding a hard reference to a "timestamp" is not "possible" any other discussion on how to emulate this behaviour is not REST-specific and it's been a while since this was dropped ^^