I don't think that is how timing analisis works. User can say to "entrance node" that it is also a node and that is how it can deny that it is originator. "Entrance node" doesn't know its position in a chain. Only Exit node knows its position.
I don't think that's totally true. At least, it's maybe superficially true but not in a real world sense. The entry node can see your IP by virtue of the incoming TCP connection and it's not hard to figure out if an IP is a Tor relay or not. The list of known relays is a list that you can just go and get. If it's not a relay, then it's a client, and you're the entry node.
No, this is not the timing attack I was thinking of. Your version of timing attack comes from inside tor network and that is solved by Entry Guards.
And besides you can also be Tor relay and a client.
This attacks are just bugs that are fixed.
The real timing attack that is not fixed and will not be (it is not in threat model), is when your ISP works with police (that has warrant) and gives them data. And police also controls server or exit node.
Possibly you replied to the wrong post; I don't know anything about timing attacks. My post was about whether the entry node knows that it's the entry node.
"The Tor Project suggests the perpetrator compromised the network via a "traffic confirmation attack".
This involves the attacker controlling both the first part of the circuit of nodes involved - known as the "entry relay" - as well as the exit relay.
By matching the volumes and timings of the data sent at one end of the circuit to those received at the other end, it becomes possible to reveal the Tor user's identity because the computer used as an entry relay will have logged their internet protocol (IP) address."
See my reply above, this are just bugs that are fixable.
"Timing attack" that will not be fixed is when police has warrant for your ISP, and police has ISP logs and destination server logs. (so it can compare the two)
