Consensus Actions in Cipherspace?

[David Honig]

At 06:01 PM 1/12/01 -0500, Ray Dillinger wrote:
>
>Crucial facts about a protocol that does the right thing would be: 
>
>1) DOES NOT create any single priveleged user or machine. 
>
>2) Resistant to denial-of-service attacks and attempts to 
>   "stack the vote." (Requires user authentication)
>
>3) No altered versions of the agent ought to be able to gather
>   enough information to force an action as long as at least 
>   the majority of agents are unaltered.
>
>4) Once a consensus is reached, a majority of the agents acting
>   together should be able to take whatever action is found
>   even if the dissenters' agents don't cooperate with them.
>   (a consensus reassembles a key?  But then that key can't 
>   be used again, what's the next key?)
>

Interesting idea.  Starting with 1 user who can admit (by virtue 
of having 100% of the vote) and then letting the users vote
to add others.  

I don't think reassembling the key is the final stage.  I think
the server could simply use a voting protocol to get (or timeout) 
permission to do proposed actions.  We are assuming that the server
is trusted, right?  

The server could send signed PGP-encrypted email to all members saying: 
"The following script has been proposed to be run by GroupServer for your
Group.. to vote yes or no, sign a yes or no message and encrypt and send it
to GroupServer.  This vote closes in 3 days, and votes are acknowleged
immediately."


Perhaps I'm not clear on what constitutes an action that could
be distributed without relying on a trusted actor (server).  

(Thinking out loud) Maybe the actions require access to a distributed
N-of-M database?   How do you prevent someone from reusing the
reconstructed database?  Or uncooperatives refusing to update their slice
of the DB?