What's wrong with this FTL hypothetical

Lets simplify the system by reduction to three points on the blades - one at the start, one in the middle, and one at the far end, like this - fig 1. The blades are purposely further apart at the near end, because this is a model of Princhester’s contrivance - with curved blades, designed to close instantaneously along their length (as we will now demonstrate).

Fig 2 - So, force (the red arrows) is applied to the near end of the scissors, so as to close them - this does bring the blades closer together at the near end, but because they’re not infinitely rigid, the rest of the blade remains unchanged - the metal flexes as the closure force (green arrows) propagates along the blades at some speed very significantly slower than light

Fig 3 - it took some time, but the closure force has propagated along the blades and is now acting to close the middle - the near end is also still closing, the force propagates onward toward the far end at a leisurely, sub-light pace.

Eventuallly, after a long time, limited by the propagation speed of the material, the force reaches the far end of the blades - the rest of the system has been in motion all the time, but since those bits started further apart, the motion of all parts of the system coincides in such a way as to bring the whole lot to closure instantaneously. - fig 4.

If we can make the closure events of all three pieces instantaneous, then we can make the apparent movement of closure from one point to the next happen at any speed we like - set the angle a bit shallower and the closure event appears to move considerably faster than light - set the near end of the blades a bit further apart, and the closure event appears to start at the far end and travel back towards us. it can do this, because it isn’t actually moving - it’s just a sequence of events that happen to resemble each other, like the dots on a scrolling message board, or the frames of a movie.

If we want to transmit data to the far end of the blades, we can only do it in fig 1, and it takes a very long time to get there - we can’t ride the movement of the closure, because it’s not moving - it only looks like it’s moving.

OK, I’ll buy that for a dollar.

But, once again, it’s not the OP’s set of conditions.
Which is why I specified above that the blades were straight.

What in Mangetout’s illustration depended essentially on the blades being non-straight in the beginning? Just have them be straight at first, and have their flexing motion over time be such as that they eventually come into the configuration he describes, and then, evolve over time from that point on as he describes.

Even if it’s a straight blade, I think the speed of the apparent movement of the closure point isn’t limited, if we start from a position wide enough open to permit the closure force to propagate all the way along and get the whole system in motion at once - but I think it would be harder to arrange.

But the point is still this - you can’t send any information on the movement of the closure point, because it’s not moving, it’s just a bunch of dots moving in sequence, creating the illusion of movement - any data you want to transmit has to be committed when you set the system in motion, not when the closure gets underway.

Well, it’s not a “scissors” unless it’s pivoted at the “handle” end.
So once again, I don’t think this contrived case meets the OP’s requirements.

This is getting back to my two cases above…

No, when I say ‘wide open’, I mean ‘wide open’ - a pair of scissors, opened wide, then closed - the wider they are at the start, the greater the opportinuty for the force to propagate along the blades and get the whole system in motion so that closure can happen fast (at least at a greater speed than the original propagation of force).

Well, I don’t really think it’s possible (in this world) to design a pair of scissors such that they close all at once. After all, the force applied to scissors is behind the hinge, implying that the first point of closure is immediately after the hinge (for straight blades).

The longer the scissors, the faster the intersection appears to move - if you had infinitely long blades, then the far ends would be parallel as they closed. OK, that’s not possible, and ignores the questions of rigidity etc, but still, in any pair of scissors, the speed at which the intersection appears to move along the blades increases as it goes.

Maybe. But for any scissors made out of a real substance, that intersection speed never exceeds c.

Which is what I’ve been trying to explain for the last two days.

And what you’ve been wrong about. It’s spelled out very explicitly in my link. You seem to think my link has some credibility. So what do you say in response to this part of it?

Well he says it, but doesn’t go on to prove it.

I say: Prove it.

Once again, that statement (for the “scissors” case) is clearly bogus. With a pair of scissors (with straight blades), the intersection moves monotonically away from the pivot point to the end. If you start closing the scissors and turn on a beam of light at the same time, if the intersection point ever appears to be ahead of the beam, I can use that to send information FTL.

Yes, the intersection point will never appear to be ahead of the beam. That is absolutely correct, and your reasoning for it is spot-on. However, what can happen is that the POI will lag behind the beam at first by quite a bit, and then eventually jump up to being not-so-far behind the beam. That jump up will be FTL.

That the POI is able to eventually move FTL is tied to the fact that it starts off moving much slower than light. (In some people’s examples, it starts off staying perfectly still for a while, though I prefer to use an example where it starts off moving slowly).

And what, pray tell, causes this sudden speed-up?

As the blades close, the angle between them narrows -meaning the closure proceeds at increasing speed, even though the tips may be closing at a constant rate - that’s a fact of geometry.

The same thing that causes it with everyday analysis of everyday scissor intersections. It’s an artifact of the changing angle between the scissor blades, which directly affects the rate of change of the POI.

Oh it does, does it?

So that means, that if I **start out ** with a scissors already closed to this magic point, I should be able to initiate a FTL closure immediately.

Once again, if this was true, I could use this phenomenon to send information FTL.

Forget it.

I understand what you are saying.

I don’t think it’s applicable to the OP’s question, but I get the point you are trying to make.

Yes, it does.

here is a diagram of a pair of scissors, showing the blades closing by five degrees at a time. Note how each ten degrees of closure causes the intersection point to move along the blade further than the previous ten degrees. Simple geometry.

If all the points on your scissors’ blades were already set into motion, then, yes, you’d start seeing FTL movement of the POI right away (It’s like having two straight lines at a very tiny angle apart, and moving one slowly against the other; the POI moves at a very high ratio to that at which you move the straight line. Arbitrarily small angles lead to arbitrarily high ratios). The thing is, how do you get all the points on its blades into motion starting from rest? That takes time, and prevents FTL transmission of information. However, once you’ve signalled to all the points to start moving, they’ll have no trouble making the POI move arbitrarily quickly.

… but, because the point of intersection can’t reach the end until the blades actually close there, and because this is limited by the material of construction, it is true to say, I think, that the average speed of the apparent movement of the intersection, across the whole journey (including the time you took to get everything moving), will be significantly slower than c. It just starts off slow and gets unreasonably fast at the very end. But the transaction as a whole can’t transmit information across the whole distance faster than c.

And you also can’t hover at the point where the intersection starts appearing to move at c, and input your data there, because you’re no longer in control of the events that are making it happen.