Consensus Actions in Cipherspace?

[Ray Dillinger]

On Fri, 12 Jan 2001, David Honig wrote:

>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?  

Actually, no.  That creates a single priveleged machine, which is 
also a point of failure, which is also a point of attack, which is 
also subject to subpeonas or outright theft.  Ideally, this is 
something that runs on the distributed machines of the participants.
I think that's the only way to be safe from the "lawsuit attack".


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


For example, consider a robo-moderated mailing list formed by 
cat owners.  They have a "posting protocol" that requires you 
to submit a digital coin worth a dollar or two along with your 
letter.  If enough people click on the "this is spam" button, 
the group agents donate the coin to an animal shelter and you 
can't spend it. Otherwise, you get your coin back when your 
message expires.  

The posting protocols etc. are wrapped in scripts, of course; 
on your end you get a message box that says "Are you willing 
to post a two-dollar bond that says most of the people on the 
list don't think this is spam?"  and yes/no buttons.  The 
subscribers just have another little button on their mail 
reader - So it goes Next message, delete, reply, reply all, 
spam.

I'd really like it if somebody has figured out a way for a 
group to form consensus and act on that consensus as though 
it were a single individual -- capable of participating in 
general protocols.  

But individual solutions to problems like the above would 
be a great start. 

				Bear




>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."
>
>
>(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?  
>
>
>
>
> 
>
>
>
>
>
>
>  
>
>
>
>
>