Is this an issue for all coins?
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.
That's about it. A new node joining the network wants to poll all unconfirmed transactions. Those transactions might be some hours old, so it has to accept those old transactions.
That means, it is not possible to distinguish between new propagated transactions and "old transactions" which are sent to nodes who are polling older data, because they just went online, right?
So when a node receives a tx from another node and the timestamp is old (a reasonable threshold will define what is old and what not), which can happen for the mentioned reasons, that receiving node should ask the other nodes quick, if they know that tx for longer or not… Or would that cost too much network performance?
Example:
- Node A sends a new transaction with an old timestamp. Node B is the first which receives it. Node B will then see that this is an old timestamp and ask "the cloud" really quick. Answer is: Nobody saw that tx yet => TX is rejected.
- Node A sends a new transaction with a current timesamp. Node B is the first which receives it. Node B will then accept it, beause it is not old. Now node C goes online 10 minutes later. Because there is a lot of spamming going on, that transaction from node A is still in the cache, so node C will receive it and see that this is an old time stamp and ask "the cloud" really quick. Anwer is: Yeah, we know it, its in the cache since 10 minutes => TX is accepted.
So when a node receives a tx from another node and the timestamp is old (a reasonable threshold will define what is old and what not), which can happen for the mentioned reasons, that receiving node should ask the other nodes quick, if they know that tx for longer or not... Or would that cost too much network performance?
Example:
- Node A sends a new transaction with an old timestamp. Node B is the first which receives it. Node B will then see that this is an old timestamp and ask "the cloud" really quick. Answer is: Nobody saw that tx yet => TX is rejected.
- Node A sends a new transaction with a current timesamp. Node B is the first which receives it. Node B will then accept it, beause it is not old. Now node C goes online 10 minutes later. Because there is a lot of spamming going on, that transaction from node A is still in the cache, so node C will receive it and see that this is an old time stamp and ask "the cloud" really quick. Anwer is: Yeah, we know it, its in the cache since 10 minutes => TX is accepted.
Every node should be able to validate these things himself. Everything else is just asking for trouble.
Well but I think we came to the conclusion that this is not possible, because a node can't know without asking "the others" if a transaction really is old (already in the cache for a longer time) or if a node has just send a new transaction with an old timestamp.
to me the time stamp isn't that big of a deal. if the money is there, it is there, and if it isn't than it isn't. basically, I don't really care about when somebody said they sent it. I only care about when I got it.
there might be some specific cases when a payment is time sensitive, and in those cases if it is time sensitive, it is the receiver's time that matters, not the senders time, at which point they can always look at the block and know exactly at what second they received it. They received it at the moment that block was formed.
if it is a really big issue in the future, I would say make two times. One time would be the time it was sent at according to the sender's time, and another time would be when it arrived according to the receiver's time.
Well but I think we came to the conclusion that this is not possible, because a node can't know without asking "the others" if a transaction really is old (already in the cache for a longer time) or if a node has just send a new transaction with an old timestamp.
I think we came to the conclusion that it's not an issue worth making validation so much more complicated over.
I think we should let the devs decide if a solution like my idea (https://forum.ournem.com/technical-discussion/sending-transactions-from-cold-wallets/msg13896/#msg13896) is possible/too complicated or not. I personally don't think it is complicated, but the question is, if that would cost too much performance.
Anyway, this thread is actually about sending from cold wallets. So let's get back to that: I still would love to see that future in NCC and would like to get more feedback on this…
Let's say there is a deadline for a letter to a court.
When the letter arrives at the court, does the court look at the date that you supplied within the letter? Certainly not! You could have put in any date in the letter itself but what counts is when it actually arrived at the court.
Let's say there is a deadline for a letter to a court.
When the letter arrives at the court, does the court look at the date that you supplied within the letter? Certainly not! You could have put in any date in the letter itself but what counts is when it actually arrived at the court.
[s]Doesn't the date count where the mail office took delivery of the letter (post office stamp on the letter)?[/s]
Wrong, BloodyRookie is right.
So that means: We just leave the timestamp feature how it is. There is no need to change that.
Good news is: We can easily implement the "send from cold wallet" idea then, right? Because it is no problem, if the timestamp from the offline NCC is a little bit in the past (the time it takes the user to create the transaction on the offline computer until it is actually send from an online node).
For all I care let's say the court looks at the post office stamp. That is an external authority too.
The point is that the court will not look at the date you supplied.
(yes, i just edited my post above)
Let's say there is a deadline for a letter to a court.
When the letter arrives at the court, does the court look at the date that you supplied within the letter? Certainly not! You could have put in any date in the letter itself but what counts is when it actually arrived at the court.
[s]Doesn't the date count where the mail office took delivery of the letter (post office stamp on the letter)?[/s]
Wrong, BloodyRookie is right.
So that means: We just leave the timestamp feature how it is. There is no need to change that.
Good news is: We can easily implement the "send from cold wallet" idea then, right? Because it is no problem, if the timestamp from the offline NCC is a little bit in the past (the time it takes the user to create the transaction on the offline computer until it is actually send from an online node).
I should think so yes.
If it takes more than a day to implement I'd put it way down on the priority list though.
That is your opinion. I think it is a big gain to offer a safe way to do transactions from cold/paper wallets. Just like having multignature accounts since launch, this is a big plus for NEM in my opinion.
Could ncc not just be programmed to display the time of the transaction as when it was received? Just for the sake of reducing confusion?
Also, I would go so far as donate towards a bounty to have this feature as soon as possible!!! I cringe knowing I have to use keys on an online computer!!
If this could be implemented by or soon after launch, I could create, and only ever use my keys on an air gapped computer and still be able to transact all I like with out putting keys anywhere near the internet… Please God implement this feature! 
Let's take a look at this example:
For all I care let's say the court looks at the post office stamp. That is an external authority too.
The point is that the court will not look at the date you supplied.
First the court:
I have to submit a document to the court by Thursday the 12th. I fill out the document on Wednesday the 11th and sign it for the same day. On Friday the 13th I remember that I didn't get the document to the court so I hurry down there. The court clerk stamps the document as received on the 13th. The judge gets it and sees it was received on Friday the 13th a day after it was due. The judge rejects it.
Now NEM:
I have to submit a payment by 2:00pm, at 2:20pm I remember that I didn't send it. I set my system time back 30 mins and send the payment. The txs gets a timestamp of 1:50pm and enters the NEM network. The NEM network doesn't stamp it when it enters the system. The person receives the txs and sees the timestamp of 1:50pm. Is it a valid txs?
You state "The point is that the court will not look at the date you supplied" which is correct, it looks at when it was received into the system.
NEM doesn't look at when it is received into the system, it takes the time you supplied.
@Kod: Yes, I would participate on the bounty.
@averagejoe: in this case "date received" from the view of the blockchain is when it was included into the blockchain.