It was today, I have been able to set my system time back for at least the last three betas. Usually I just set it back a couple of mins but after reading BloodyRookies post about the timeframe I tried the 1hr timeframe and it worked.
Interesting.
Interesting.
Here is the hash: d09d65fe1c89f6d2b59017a0a424eb08c6ef3261c01489b75343454293bf6484
It was today, I have been able to set my system time back for at least the last three betas. Usually I just set it back a couple of mins but after reading BloodyRookies post about the timeframe I tried the 1hr timeframe and it worked.
Interesting.
It was 9:42 my time then I set my system time batck 1hr and sent some txs.
EDIT:
Here is the hash of a txs i sent just before i turned my system time back 1 hr 79f4d83bf0a763dbe372b3d24623ab5af72882d603c040fff514d256b0cc7dce
You can see they are in the same block but the timestamp shows them about 1 hr apart
Here is the hash: d09d65fe1c89f6d2b59017a0a424eb08c6ef3261c01489b75343454293bf6484
It was today, I have been able to set my system time back for at least the last three betas. Usually I just set it back a couple of mins but after reading BloodyRookies post about the timeframe I tried the 1hr timeframe and it worked.
Interesting.
It was 9:42 my time then I set my system time batck 1hr and sent some txs.
EDIT:
Here is the hash of a txs i sent just before i turned my system time back 1 hr 79f4d83bf0a763dbe372b3d24623ab5af72882d603c040fff514d256b0cc7dce
You can see they are in the same block but the timestamp shows them about 1 hr apart
I know that happens with Bitcoin too. I have seen a later block with an earlier time stamp. I asked about it and they said the time stamp of the machine makes the time stamp but the important thing is when it is included in blocks. Setting one's computer back an hour doesn't somehow insert one's transaction in a block that happened an hour ago. So time stamps are to not be taken as completely accurate in Bitcoin.
Not sure how it works in NEM though.
It's not about the blocks it's about txs timestamp. Timestamp of txs are very important for payment processing, if the time can be adjust then the system isn't valid.
It's not about the blocks it's about txs timestamp. Timestamp of txs are very important for payment processing, if the time can be adjust then the system isn't valid.
It can only be adjusted backwards though. You can't send anything into the future and you can't extend your deadline that way.
However I'm totally without that it isn't ideal. In fact I've told the devs multiple times that NIS should calculate that timestamp because it would also make the API much more userfriendly. It would still be modifiable since NIS will be open-source at some point but the dude that can compile that thing without the devs help is yet to be born xD
This is my line of thinking: Let's say there is a time deadline of 2:00 pm to make a payment for some event, at 2:20 pm you haven't made a payment yet so you set your system time back an hr or more, make the payment then once the payment is in the block you send the payment hash to show that you made the payment on time. It's easy enough to blame the network for delaying the payment, as far as i can tell besides the txs timestamp there is no way to tell when the payment was sent.
You might be on to something about having NIS make the timestamp.
- When you set your system time into the future for more than 10 seconds your transaction will not be accepted by the network. Future transactions are thus not allowed and that is validated.
2) You can set your computer back an hour and the transaction will go through if the deadline is not exceeded. So what? You can supply any timestamp for the transaction when using a script, you don't even need to adjust your computer time. The timestamp of a transaction has no meaning other than checking if has already expired. The relevant thing when it comes to payment or any deadline given by an external entity is when it was included in a block.
Block time is the time of entry into the ledger. In my opinion it should be the official record of data entry, not the machine time. Anything else should not be considered true unless and until it is entered into the block chain.
When the checkbox is ticked, NCC will just use local system time. Easy as that...
...
Pretty sure that's not how it works.
Not now, but hopefully in the future...
No I mean I'm pretty sure it wouldn't be reliable. If I'm not mistaken that would result in different timewindows for people in different timezones.
NCC will of course use UTC time. I think there is no OS which is not able to do that^^ So, all the user has to do is: Set the time (and timezone of course) right. No big deal...
1) When you set your system time into the future for more than 10 seconds your transaction will not be accepted by the network. Future transactions are thus not allowed and that is validated.
2) You can set your computer back an hour and the transaction will go through if the deadline is not exceeded. So what? You can supply any timestamp for the transaction when using a script, you don't even need to adjust your computer time. The timestamp of a transaction has no meaning other than checking if has already expired. The relevant thing when it comes to payment or any deadline given by an external entity is when it was included in a block.
i know for a fact that users will go by the time stamp and not the block it was included in.. "hey guys, payment due by 10pm".. user: "shit im late..." *sets time back*.. organiser: "all tx's seem to be valid, prize money for competition paid out" < cos he goes by the clock time... other user: "hey that dudes tx wasnt included until an hour after the deadline.. why does it say the time was valid and why does he get to enter the competition,.. nem is broken"
doesnt make any sense to allow users to manipulate the timestamp like that... :/ is there any reason why they should be allowed to manipulate the time stamp like that? what would be a use case for allowing this? if theres no use case, it will most likely cause more issues than provided benefits..
1) When you set your system time into the future for more than 10 seconds your transaction will not be accepted by the network. Future transactions are thus not allowed and that is validated.
2) You can set your computer back an hour and the transaction will go through if the deadline is not exceeded. So what? You can supply any timestamp for the transaction when using a script, you don't even need to adjust your computer time. The timestamp of a transaction has no meaning other than checking if has already expired. The relevant thing when it comes to payment or any deadline given by an external entity is when it was included in a block.
i know for a fact that users will go by the time stamp and not the block it was included in.. "hey guys, payment due by 10pm".. user: "shit im late..." *sets time back*.. organiser: "all tx's seem to be valid, prize money for competition paid out" < cos he goes by the clock time... other user: "hey that dudes tx wasnt included until an hour after the deadline.. why does it say the time was valid and why does he get to enter the competition,.. nem is broken"
doesnt make any sense to allow users to manipulate the timestamp like that... :/ is there any reason why they should be allowed to manipulate the time stamp like that? what would be a use case for allowing this? if theres no use case, it will most likely cause more issues than provided benefits..
then the organiser is a moron. If the network is under heavy load then it can take some time for the tx to go through which is why he should be looking at the time of the first confirmation not the time the tx was supposedly sent (unless he want's to be lenient).
I agree though that if it doesn't have to be like that it shouldn't be.
doesnt make any sense to allow users to manipulate the timestamp like that... :/ is there any reason why they should be allowed to manipulate the time stamp like that? what would be a use case for allowing this? if theres no use case, it will most likely cause more issues than provided benefits..
How do you distinguish between a transaction that has a "manipulated" creation time (say the time is set one hour back in time) and a transaction that was created an hour earlier with a valid timestamp but now is one hour old?
BloodyRookie the issue is about being able to manipulate the system, the above gave a very likely situation which could happen. It has been pointed out that there are no positives and lots of negatives to this and your replies to this matter is very disheartening.
The average person will have a hard enough time figuring out crypto as it is, now you expect them to figure out what block numbers and confirmations mean and how they work together? It will take awhile before people reach this point.
Instead of using local time, use nis synchronised time… Then off set the timezone locally so you can only move the time around locally on your ncc settings. As for signing of timestamp on tx, is there any technical reason why txs can't be timestamped using nis synch time and that time just displayed differently based on local settings?
Hello
In my opinion transaction time should be same as the time of the 1st confirmation or the block time.
Even if there is not manipulation involved under heavy load the transactions could go into the queue so that means
transaction crated at 10:00 am could sit there maybe for 2 hours while
the "game" could be already over or the auction offer could be already expired.
In case of auction for example this scenario could be used to manipulate the results by creating transaction at later
time by changin the system clock while the acution results are already known and to send the transaction to outbid
the best offer.
So in case there are no (there won't or can't be) any changes to this part of the code in NEM
it should be clearly documented in the API or wiki for other developers to know that they should themselves implement the correctly the transaction verification process by using the time of the 1st tx confirmation or the block time.
Instead of using local time, use nis synchronised time... Then off set the timezone locally so you can only move the time around locally on your ncc settings. As for signing of timestamp on tx, is there any technical reason why txs can't be timestamped using nis synch time and that time just displayed differently based on local settings?
This would just make it harder to tamper with the timestamp. Once NIS is open-source anyone could change that behaviour or even befor that you could just change the data before going over the wire.
Yes, but nodes could start to reject transactions with a timestamp far in the past or future… Or am I missing something?
Yes, but nodes could start to reject transactions with a timestamp far in the past or future... Or am I missing something?
More than 10s into the future is being rejected already.
The past is problematic because under heavyload (which admitedly we won't see for quite some time) a tx might linger on the network a little so it might actually be a bit in the past without the timestamp being tampered.
If a node comes online and a tx has been lingering for an hour and that node rejects that tx it's prob only a matter of time until a fork is building since the other nodes that recieved the tx in time accepted it.
Ok I think we have to make clear how it actually works to understand the problems and possible solutions.
How I understood it:
A user sends a transaction. What happens is: His NCC will use a NIS to propagate that transaction to other nodes and the nodes will propagate it even to more nodes etc. Then finally any node will calculate a new block and the transaction is a) included in that block or b) not included in that block because there are to many transactions so the transaction has to wait for future blocks.
So, if the timestamp of the transaction, that is propagated from the origin, has a wrong timestamp (too far in past or future), other nodes will not propagate it.
That is what I meant. But maybe I am missing something…
Ok I think we have to make clear how it actually works to understand the problems and possible solutions.
How I understood it:
A user sends a transaction. What happens is: His NCC will use a NIS to propagate that transaction to other nodes and the nodes will propagate it even to more nodes etc. Then finally any node will calculate a new block and the transaction is a) included in that block or b) not included in that block because there are to many transactions so the transaction has to wait for future blocks.
So, if the timestamp of the transaction, that is propagated from the origin, has a wrong timestamp (too far in past or future), other nodes will not propagate it.
That is what I meant. But maybe I am missing something...
We're getting into very specific details that only the devs really know but my impression is that nodes will re-propagate valid tx to new nodes. So say I have a valid tx in my cache and I see a new node I'll be sure to tell him about that tx.
So what I meant was that such a tx could be lingering there for a while and the new node might have come online at a time where that tx should be rejected already based on timestamp. This would cause a dissagreement among the nodes.
I do recall this being an issue once (nodes were bouncing txs back and forth) so this behaviour might not exist anymore or i understood it wrong in the first place so don't take this for granted.