Again we assume that there is a well-known (i.e., authenticated)
public key for B. When A signs up for B's click-through payment
program, B generates a large, unpredictable number s, applies a
one-way hash function (e.g., [SHA95]) f to it k times to
produce , digitally signs the pair
,and sends
and the signature to A. Note that all of
this takes place when A registers for the click-through program, not
on the critical path of referrals. Once this is set up, rather than
passing a digital signature back to A during a referral, B simply
passes back the pair
to A, where
, for the i-th referral (
) that A gives it. B can pass
the pair
to A using techniques like those of
Section 4.1. A can verify the
correctness of this pair by verifying that
. In
the event of a dispute, A need only present the digitally signed
pair
and a pair
where
to convince a third party that B received at least i
referrals from A.
This scheme has some disadvantages in comparison to that of
Section 4.2.1. The main disadvantage is that B
can later repudiate the user's IP address in this scheme. In payment
programs that pay only for ``unique'' referrals, A's inability to
record the user IP address in a way that prevents B from later
repudiating it could leave A at a disadvantage in a dispute. An
agreement that B returns a referral record (i.e., a new pair ) only for unique referrals may restore the balance, but
only if A is prepared to verify, when B refuses to return a
referral record, that the referred user was a repeat user. A second
disadvantage of this scheme is that it must periodically be
``refreshed''; i.e., once k referrals from A to B have been
made, then A must obtain a new signed pair
from B.