Thanks for the welcome. Had I read more of the old messages before
making my first post, I would have seen some of what you thoughtfully
laid out in our reply to my Q. Thank you.

The more I look at this idea of futarchy, the more intriguing it seems
- yet the more I realize I lack the training to dig into it deeply.



--- In futarchy_discuss@yahoogroups.com, "Tom Breton (Tehom)"
<tehom@...> wrote:
>
> Hi, Paul. Welcome to the list.
>
> >
> > Tom,
> >
> > This is not my area of expertise at all, so if the question I am
about
> > to propose is foolish I apologize in advance.
> >
> > Why can't we simply design the rules of futarchy to minimize such
> > issues such as those posed in your post below? I am guessing you
> > picked an extreme example to make your point -
>
> That's a discussion I was trying to have and mostly didn't get. So
> thank you. But I'm going to answer your next bit first.
>
> > but if my memory serves
> > correctly the original Futarchy whitepaper described a variety of
> > potential safeguards that seem to be well equipped to handle
issues
> > like this, yes?
>
> I've read it (them, actually). I'm skeptical. The first paper was
> what led to me defining the opacity problem. I don't recall any
> safeguard in either paper that struck me as bearing on it, and in
> discussion, Robin did not point to any.
>
> I would be interested in hearing what safeguard you believe defeats
> the opacity problem and why.
>
>
> [Again]
> > Why can't we simply design the rules of futarchy to minimize such
> > issues such as those posed in your post below? I am guessing you
> > picked an extreme example to make your point
>
> Yes. I did it in order to distinguish clearly between two
> separate issues:
>
> * Can a proposer in fact make an opaque proposal?
> * Furthermore, can he do it in such a way that it can't be
> mechanically singled out to be rejected or placed at a
> disadvantage? That was the discussion I wanted and never got.
> * Given that an opaque proposal be made, can it succeed in the
> market?
>
> My positions are as follows:
>
> * "Can a proposer in fact make an opaque proposal?" Yes.
> * "Can he do it in such a way that it can't be mechanically
singled
> out to be rejected or placed at a disadvantage?"
> * Under obvious fixes like forbidding crypto, still yes. Opacity
> is plentiful. People are very creative at inventing new ways
to
> obfuscate.
> * Under any rules whatsover? Maybe not, and therein lies the
hope.
> I've proposed two complementary approaches:
> * Controlled language
> * Market rules that disadvantage opaque proposals, where
opacity
> is measured by market behavior.
> * "Can it succeed in the market?" Yes, by mixing opaque clones and
> opaque gimmes and revealing them at certain times.
>
>
> I'm not entirely sure what you are proposing with "simply design the
> rules". Can you be more specific?
>
> As a preliminary answer I'm going to quickly rehash a bit of old
> stuff:
>
> I draw a distinction between a decision market and an advisory
market.
> The distinction is where the final decision power resides. For an
> advisory market, it lies outside the market. For a true decision
> market, it lies in market behavior, mediated by predetermined rules.
>
> Proposals along the lines of "someone vetoes the crazy ones" belong
to
> advisory markets. The natural comeback is, "Then why not have only
> advisory markets?" Answer: because your vetoer can still exploit
the
> Opacity Problem. You prevent the man in the street from exploiting
> his gimme proposals, because your vetoer will presumably want to
veto
> other people's gimmes them whether they are opaque to him or not.
But
> your vetoer can still make his own opaque proposal to give himself
$1
> billion and not veto it. If you must trust him to not do that, then
> you are simply trusting him - I'd call that monarchy (for
simplicity;
> adapt the term to whatever person or group holds the veto).
>
> This holds no matter who the vetoer is, barring extreme approaches
> like imprisoning him incommunicado so that he can't propose anything
> even by proxy. Even distributed veto mechanisms like mass voting
are
> susceptible to this exploit.
>
> Tom Breton (Tehom)
>