Block Validation and incorporation of TX timestamp as part of block validation(Double-spent) #8893

Currently, all new blocks are handled as an absolute truth should the requirements be met as is. I propose we add one more validation method. Using the transaction in my nodes memory and there related timestamps. Ensure that this new block didn't accept any older TX that shouldn't be there.

Expected behavior

Tell us what should happen: The block shouldn't be accepted as it's malicious, regarding "double - spending."

Actual behavior

Tell us what happens instead The Block gets accepted "as is." Even if the current node(your node) has the original and first TX.

Proposal: Validate timestamps of all transactions in a given block before accepting the block.

Transactions do not have timestamps, and there is no way in a decentralized network to unambiguously determine the first seen time of transactions. In fact, if there were, we wouldn't need a blockchain at all.

The Block gets accepted "as is." Even if the current node(your node) has the original and first TX.

As mentioned by @sipa there is no way to determine which is the "original and first TX" for the whole network.

Closing, as this is the wrong place to start discussing consensus changes.

Is it possible to allow the original node that broadcast the TX to send and hash the time along with the transaction. This would then be used across the decentralized network as elementary proof of the time the original server accepted the TX. So should my Node in say, Africa, only accept the transaction after 30sec( a long time) the original time would be passed along with the TX. And we would still need the BTC blokchain to validate the TX.
Edit: Consensus should play an role. Also their is no need to keep all tx's in Volatile memory.

Is it possible to allow the original node that broadcast the TX to send and hash the time along with the transaction.

And nothing prevents you from just backdating your TX. You'd need something like OpenTimestamps... But OpenTimestamps depends on the block chain, so you can just use it directly "as is", instead of walking in circles.

I did note that a while ago. Like when a sibling would try and convince you of time-travel. And as This is such a simplistic yet hard problem. Could it be that a solution is staring you in the face? Such as authentications of nodes? Don't allow nodes with wrong times to connect to your node. Hence if your node is wrong it would simply not be able to connect to any other node. Effectively eliminating itself. Using a cluster of approved ntp-servers could then form part of node validation on the network. I understand that some countries does have high latency and that some idea/s like this is the only feasible manner to address the this issue. Or some how "Lock" the transaction but this would require all miners to accept this. Any miner could still generate blocks as is and would still be accepted. And as not all the nodes on the network are core nodes. The original problem remains. Or I have simply explained the system as it functions today...

Please move this discussion to stackexchange or IRC, or the mailing list if you have a concrete proposal.