authenticating Real Life(tm) - rhetorical bogosity

Carskadden, Rush carskar at netsolve.net
Tue Jan 16 10:56:24 PST 2001


>From a rhetorical standpoint, this argument is completely bogus. If you want
to be reckless with logic, then you might be able to say that in a perfect
world, trust of the proof may result in implicit trust of that's proof's
application to an ideal (though this is technically flawed), but the trust
is not transitive, nor commutative. Trust of a proof may result in trust of
a proven concept, but the two are not indistinguishable. Further, the
colloquial connotation of the word trust, which seems to me to be the major
rhetorical nightmare here, appears subjective, and thus hard as hell to do
anything with from a logical standpoint. Attempting to make a shaky logical
argument about someone else's trust (in the colloquial sense) of anything
may indicate some properties of the subject's method of assigning trust with
which I am not at all comfortable. Defining trust in this sense would
require a massive amount of data from the subject, which I (for one) am
unwilling to collect. Might we, instead, ask the subject how their trust
differs between proof and protocol, and inquire about the potential
differences in trust assignments? Granted, this list is a bogon sink.

Sorry Jim, the devil made me do it.

> -----Original Message-----
> From: Tom [mailto:tom at ricardo.de]
> Sent: Tuesday, January 16, 2001 10:14 AM
> Cc: cypherpunks at einstein.ssz.com
> Subject: Re: Re: authenticating Real Life(tm)
> 
> 
> 
> Jim Choate wrote:
> > > so you trust the proof. great. if you trust the proof, 
> and the protocol
> > > has just been proven, then your trust extends to the 
> protocol. and so
> > > on. web-of-trust.
> > >
> > > please don't say you don't. because if a protocol that 
> was just proven
> > > by a prove you trust has not earned your trust by that 
> procedure, then
> > > obviously you lied when you said you'd trust the prove.
> > 
> > The 'proof' IS the 'protocol'. You act as if 'proof' and 'trust' are
> > equivalent. They're not. I 'trust' because I know the protocol won't
> > 'lie'. That is the 'trust' and the heart of the 'proof'.
> 
> I don't say trust and proof are identical. what I do say is that proof
> extends trust. if you trust the proof, then you can trust whatever it
> proves.
> i.e. if you trust that you do have some method to determine the truth
> value of anything I say, then that means if your method says "he says
> the truth" you can trust in what I have said. not because I said it or
> because you trust me, but because you trust the method which says I'm
> saying the truth.
> on a crypto level: if you have a protocol that can verify whether or
> not, say, a given coin of a given cyber-money is "ok" (not already
> spent, of the value it claims to be, etc.) then you can 
> accept said coin
> from me. even if you do not trust me in any other thing, you just
> created a trust in that single coin. your trust in the protocol just
> extended to a trust in the coin, by application of the protocol. you
> didn't trust the coin before, you trust it afterwards. proof was just
> the method. there's a lot of trust that exists without proof (some of
> which you mentioned in your last mail).
> 
> 
> 
> > For your assertion to be so you still need to prove:
> > 
> > A trust B, B trusts C, therefore A trusts C.
> 
> while I did say that, I also wrote a lengthy clarification about it.
> please refer to the full claim, not a single, selective quote 
> which has
> a significantly different meaning.
> 
> the full claim was:
> 
> ===quote start===
> if A==B and B==C then A==C
> 
> if replace == with "trust". if A trusts B and B trusts C then A can
> trust C. that's a gross oversimplification, so please don't start any
> nitpicking. I said a couple of words about trust not being 
> binary in the
> last mail. in essence, the == should read "total, complete, absolute
> trust in everything", something that I doubt you'd see 
> anywhere in real
> life. the more precise formula would be:
> 
> A trusts B (minus margin of mistrust) 
> and B trusts C (minus margin of mistrust)
> therefore A trusts C (minus (margin of mistrust AB * margin 
> of mistrust
> BC) )
> ===quote end===
> 
> now that's a slightly different thing, don't you think? the 
> mistrust in
> the AC case can be quite large, not zero as your selective quote makes
> believe.
> 
> 
> > After all, simply because you and I trust the protocol 
> still doesn't mean
> > I trust you. It only means I believe you haven't lied in 
> this particular
> > case.
> 
> that is exactly what I mean by "margin of mistrust" above. 
> you may trust
> me with taking care of your dog for a week while you don't trust me
> taking care of your wife for an afternoon - that is EXACTLY 
> what I mean
> when I say that "trust in real life is not binary".
> 
> 
> > I use the protocol not to decide my trust but to give me a 
> reason to opt
> > out of the process. Fundamentally if you have to apply any 
> of these sorts
> > of protocols to an exchange a reasonable person won't want 
> to be involved
> > in the first place. There is a fundamental lack of trust 
> already extant.
> 
> bullshit. the protocol just needs to be simple enough. returning to my
> cyber-money example above, we DO have a protocol of verification of
> physical money in real life. it's not perfect, but it works reasonably
> well. it works by having specific coins or bills for money so that by
> visual identification and verification you can accept money 
> from a total
> stranger in good faith.
> yes, forgery does exist. as I've said a couple dozen times so 
> far: there
> are no perfect protocols and no absolute trust in real life. but guess
> what, civilization works more or less ok without, unless you 
> are jim and
> apply the maximum threat model to every step of your life.
> 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/html
Size: 9537 bytes
Desc: not available
URL: <https://lists.cpunks.org/pipermail/cypherpunks-legacy/attachments/20010116/d1350d45/attachment.txt>


More information about the cypherpunks-legacy mailing list