Messages

Yes. No. Authors yes, Voters no.

Confusing decisions does not imply voting random, instead all .5 (actually easier).

I appreciate your concerns, and skepticism, but I really did give this a lot of thought before publishing it. 

If the goal is to make it easier for voters to specialize when declaring an outcome, then shouldn't the PM Authors play some role in forming ballots?

They do in a way: they select the branch and maturation-time. Eg Decision: "DJIA close on Feb 18th, 2015", Branch: Votecoins_Finance, Date: March 2015, Then the Ballot that that Decision will in is the March 2015 Ballot on the Finance branch.

Read the whitepaper to learn how the Ballot is used (re: the rest of your post).

Btw, I'm looking forward to your interview on Let's Talk Bitcoin! 

I'm looking forward to being interviewed.

There is a way.

It is in the whitepaper....you should really read it very carefully, because I think it would be less work for you to plan out the programming work in advance and do it all effectively the first time.

Therefore, Factory only needs to be run once per month. The same goes for Vote-Collection. No need to have every node calculate it for every block.

ok then, how many decisions do the pool of voters need, at minimum, per voting session? What if not enough decisions are given? Should they make up a bunch of other decisions to ask themselves?
Should they have 1 round of voting every 2 weeks? Every week?

I was thinking once per month, a small discussion of this is in the newly-updated FAQ.

If there are less than 10, I would probably wait until next month, and accumulate them. 4 is probably the absolute minimum.

I think you are right: voters can make up easy decisions to ask themselves...they won't mind paying the fee as it is to themselves. Votes do more than determine reality, they cross-validate other votes so they are very important...effectiveness actually increases with scale.

Some of the variable names no longer make much sense (except to me).

The Agents section is interpreted left to right, by Voter (each row is a Voter).

"OldRep" is 'The Proportion of Votecoins a Ballot-Submitting Judge owns' and represents "This periods reputation" or "the reputation used to vote this period", people are punished rewarded, via consensus and participation, until this value becomes "RowBonus". For example, "RowBonus" of period 3 is the "OldRep" of period 4 (if everyone held their Votecoins and didnt divide/combine them).

Hopefully, the Decisions section is much clearer...it is interpreted from top to bottom (each column is a Decision). DecisionOutcome.Final is the outcome, as hopefully is clear.

When a decision is proposed to the voters, they all vote on how high the fee will be to mediate this decision.
Which function do you use to turn all the suggested prices into one price?

Branches have parameters fee1 and fee2, this fee rises to retarget as a function of 'Participation'. This is not crucial, so I'd avoid it for now. Just assume 5$ or something.

After all the votecoin holders vote on a set of decisions, a matrix is formed. Voters x Decisions. I think I know how to build this matrix.

Some of that is in 'Governance.R'

Your code transforms the matrix into a list of outcomes of each decision, and you punish/reward every votecoin holder.
Which function is used for this part?

Factory()
Check out this: https://github.com/psztorc/Truthcoin/blob/master/lib/consensus/Tests.md

Is there anywhere else I need to use Paul's code, besides the two places I specified?

Probably for Buying and Selling (within markets), to make sure the LMSR / data fields are consistent.

What if a pool of votecoin holders only gets asked 1 decision? Is it ok that the matrix is only 1 column? Will this be any less accurate?

That's not ideal at all. It probably will fail computationally when it tries to build a covariance matrix, if not earlier. And yes, it will be less secure and less accurate, and less incentive-compatible.

In whitepaper version 1.2, and the R code, you can predict continuous variables, and type in a literal number. Instead of binning to [0, .5, 1], you get a number in range(0,1) which scales up to anything you like.

Moreover, in Paper 2 (PM Types), I provide an example with the "exchange rate above (500, 1000, 1500, 2000, 2500, 3000, 3500)", but following that, I use a log scale on page 7 where I say "Did more than [10,000; 100,000; 1,000,000; 10,000,000] Americans die in 1917?".

So we need to keep an array of the outcomes of every decision that this pool of voters has ever voted on?

No, just those maturing this period. I attempt to explain this on page 8 of Whitepaper 1.2, section "Operationalized Coordination Using SVD". Also, there is a discussion here (https://bitcointalk.org/index.php?topic=475054.0;all) among a few people who seem to get the idea.

I am working on implementing truthcoin full-time.

Cool! This part (the consensus mechanism) is that magic that makes it all possible (where it wasn't possible before), so please ask as many questions as you need. However, the FAQ and whitepaper are the best reference.

VotesUM is "unmasked" and sets up for the masked array which stores the votes.

not voting = nan
yes = 1
no = 0
undecided ("unresolvable") = .5

I've done almost no testing of the python version, vs. the R version. Also, only the R version can handle continuous outcomes.

Sorry, I like my full time job a lot! Also, this beautiful weather makes it hard to code.

I did not use clever statistics. Probably someone else has a much better way of doing this.
I fear that my code is going to be undecipherable, so I will give a short explanation here.

When the pool of votecoin holders is created, a number 'x' is defined. It is between 0 and 1.
When the votecoin holders are voting on whether or not to accept a potential decision. holders sign either to accept, or deny, one at a time. We keep a running total of how much of the votecoins want it either way. If at any time ((the amount of votecoins that accept the decision)-(amount of votecoins that deny the decision))/(total number of votecoins in the pool) > x, then the decision is accepted into the pool of decisions.

Alternatively, if that fraction was <-x, the decision is thrown out, or if 40% of votecoin holders want to get rid of it, then it is thrown out.

voting to decide on the outcome of the decision works identically, and with the same constant x.

Are you aware that in https://github.com/psztorc/Truthcoin/tree/master/pylib I have python versions of many of the functions?

The latest versions are in R/S+ which are here https://github.com/psztorc/Truthcoin/tree/master/lib

Yes, if it were better.

Regarding the paper you've found:

One caveat is that, unlike LMSR, BMM is not loss bounded. Another is that it is not as simple to extend BMM to combinatorial markets.

Those seem like major drawbacks, don't they?

[the principle of building a network (and building network effects)]

I'm only giving the coins to miners as they mine in the future. The rest of the coins are going to Bitcoin owners.

Satoshi solved the allocation problem by distributing the coins not to whoever he thought deserved them, but to anyone interested enough in Bitcoin to prove that interest by CPU mining. The point was that he didn't make it about himself, or his preferences (because there are a lot of people in the world, who could have copied Bitcoin and made it about themselves or their preferences), but instead made it on the principle of building a network (and building network effects). That is what I am trying to emulate.

Its not about copying Bitcoin because Bitcoin is good, its about plugging into the best network.

[because this type of currency is very good for testing purposes]

The implementation of truthcoin that I am working on is based off of slasher, because this type of currency is very good for testing purposes.

I don't know all the details of how merged-mining works. I want to build something that works ASAP, and not waste time learning merged-mining.

I think that's fantastic. I didn't see my comments as applying to developers who are testing mining-independent functions.

Now that I understand better: "Truthcoins" should be allocated to whatever you decide is most "fair" or marketable - like bitcoin airdrop. "Votecoins", the things that earn income from the network's operation, should drop on AGS/PTS/proto-truthcoin(fundraiser)/premine, etc

Don't you think that, if we Bitcoin airdrop'd, the Votecoins would themselves become extraordinarily valuable? I do. Bitcoiners who didn't want the airdrop'd-Truthcoins might sell them (kick-starting external exchange liquidity), but they might also do a bunch of frivolous trading (akin to "gambling"). Moreover, no one can claim that we are challenging Bitcoin's value. I think the potential is worth considering for a very long time.

Its a complex question, though. I hope you can help by communicating with the Bitshares community to see what would be acceptable.