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?