From: Jim McCoy <mccoy@ccwf.cc.utexas.edu>
Date: Sun, 10 Oct 93 21:36:09 PDT
To: cypherpunks@toad.com
Subject: Re: DC-Net proposal,  comments requested
In-Reply-To: <9310100127.AA23557@illuminati.IO.COM>
Message-ID: <199310110432.AA15221@tramp.cc.utexas.edu>
MIME-Version: 1.0
Content-Type: text


cman@IO.COM (Douglas Barnes) writes:
> [dc nets stuff]
> 
> One head scratcher I've been considering is whether it would be better
> to simulate a token-passing scheme, or to have comparisons broadcast
> to all participants. [...]

Doug has already heard a lot of this over dinner discussions we have had on
dc nets and networking, but here are a few more things I have been thinking
about in regards to this.

The idea we hashed around in the token passing realm was that members of
the net would begin by knowing only thier partners (I will assume people
are being honest in the network for the moment...)  Each person will pass
packets to the left, the person they share thier data with in the dc setup
(i.e. the person whose menu they look behind and whose coin they compare
thier toss with.)  The "packets" will have two sizes, the small one for
token negotiation and a large one for data transmission.  Token-sized
packets are passed until someone suceeds in transmitting the "i speak"
token, then a data packet, and then token negotiation begins again.

Everyone prepares two random numbers, one for the data sharing that is part
of the dc net and another to use in the communications ring.  When people
have checked thier neighbors and are ready to transmit, they send thier
second random number (and a random signed token so they know when they see
thier token come back to them) to the person on thier left.  When a packet
is recieved, each number is incremented or not for the "same/different"
message and passed to the next member.  When your token finally gets back
to you it is possible to check for the message sent by the net, you know
your original random number and the number of passes necessary for you to
get your token back tell you how many people are participating.

Doug and I thought that perhaps if the broadcast signal was something like
"1111(rand 8 bits)1111" and people backed down when they sensed collision,
so that unless the 16 bits ended with 1111 people would know there was no
token in that round (0 is the default message, when people colliding stop
trying to send the negotiotion falls to zero for that round) and they would
try again.  Eventually someone would be able to transmit the sequence and
because the number in the middle is random only they would know that they
have the send token.  Then people communicate for the preset length of the
data packet and begin negotiating for the token again.

As far as breaking up and reforming the network I am still looking for
ideas, but have been reading some old crypto proceedings and I am going to
play around with some ideas and see if Chaum's blind signature stuff
coupled with a ZNP for proving identity might work (it happens to be the
article I was reading on the way over to work and it has gotten me
thinking...)

> Also, I have thought of some ways of dealing with "slacker" processes
> or folks who suddenly drop out that work better with a broadcast approach,
> but there's probably a way to deal with them in the token-based scheme.

Yes and no.  The internet is not a connection-oriented medium and it is
impossible to know whether or not a particular packet made it through.
"Broadcasting" is also tricky for the same reason.  The designers of the
net have worked out several schemes for getting around these problems, it
makes no sense not to lift a few good ideas for this...  


jim