> And you're still ignoring that the entire point of the lock being discussed is that traditional lockpicking methods wouldn't work.
I am not ignoring it: I was bringing a point on terminology, not on this particular lock or lock-picking methods.
You seem to be unable to accept that people tend to and do use different terminology for same things, or same terminology for different things.
> Yet, when presented with an option to defeat the lock in less than 4 hours, your reaction was to repeatedly state that it doesn't even count as lockpicking. I don't know what else to say.
You need not say anything else, because I like to consider this a design idea, rather than a lock on a non-existent doors.
What would be the effect on the time to "lockpick" exactly the same type of lock but with two more or double the number of pins (as an obvious counter measure)?
Remember that this is a proof of concept lock and there are no doors it protects, so any actual implementation should be able to easily apply obvious extensions where higher security is needed. Again, it's not about this particular lock, but if there is an obvious scalability to the design, a lockpicking method only works if it scales linearly (like with regular pins, where you only test each pin individually).
Yeah, I don't accept your terminology, and you don't accept mine (no matter how you try to stretch it how it being half on average is reducing the problem space when it's not: that's rudimentary math, and when you reduce the problem space in a smart way, it applies to each method: eg. testing individual pins, you'll find them on average in half the attempts...).
I do struggle to understand why are you so keen to convince others how your use of terminology is the only acceptable use: it's ok to agree to disagree.