Messages

Having reflected on the whitepaper more deeply, I will once again try to derive the set of transaction types for the consensus mechanism.

1) create pool of votecoin holders
* a list of public keys, and how many votecoins is allocated to each public key.
* how often do we vote on decisions

2) propose a decision
* which pool of votecoin holders are you proposing to
* text of the decision
* Which set of decisions will this be included with? This is the expiration date.

3) votecoin holder vote
there are many decisions, looks something like: [0, 0, 1, 0.5, 1, 1, 0]
This makes votecoins temporarily disappear. (to stop people from voting and spending simultaneously.)
* sha256([0, 0, 1, 0.5, 1, 1, 0] + secret nonce)

4) reveal votecoin holder's vote
Voters cannot reveal until the expiration is passed.
Once the first person reveals, it is no longer possible to vote.
* [0, 0, 1, 0.5, 1, 1, 0]
* secret nonce

5) SVD consensus
This cannot happen until the proper time. Every voter needs enough time to reveal.
One person submits this transaction once per set of decisions.
uses R factory function to compute the results from the Decisions-Voters matrix. After this transaction is buried deep enough in the blockchain, people downloading the chain will not have to re-compute SVD.
The votecoin holders get their votecoins back (including votecoin holders who never decrypted their votes??)
* consensus results of each decision.
* New allocation of votecoins.

So everyone who is unsure of a decision puts 0.5 instead of a 1 or 0?
Having a whole row of 0.5's wont mess anything up? Aren't they punished for putting 0.5?

What if I asked a bunch of bad decisions to confuse people, and it was so confusing that voting ended up more-or-less random.
It becomes a guessing game to figure out how everyone else will vote, but everyone is trying to trick each other into voting wrong?

When a decision is asked, $5 must be paid to the pool of voters.
but what if the decision is poorly worded, or based off of opinion rather than fact? example: "Will it be hot out on Thursday?"

The votecoin holders need a way to throw out bad questions like this, right?

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?

Myths show up for a reason. Often it is a concealed threat.
Prometheus was greatly punished for giving fire to humanity.

A lot of powerful people will be harmed by the creation of truthcoin.
Will they take it out on the creators?

I figured out how to run R code from python. I have access to all the functions, but I don't know when to use which one...

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?

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

(just talking about consensus mechanism and votecoin holders now. Not yet caring about PMs or shares.)
Is there anywhere else I need to use Paul's code, besides the two places I specified?

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?

people will want to prediction the future exchange rate between all sorts of things.

If there are 1000 possibilities, the initial liquidity has to be bigger than when there are only 2 possibilities.  ln(1000)/ln(2)=~10, so it has to be about 10 times bigger.
The initial deposit grows with log base 2 of the number of possible outcomes.

The number of decisions required to reach consensus on a number can also scale by the log.
instead of this list of questions:
"is BTC/USD bigger than 600"
"is BTC/USD bigger than 601"...

We ask this set of questions:
"is BTC/USD modulus 2 equal to 1"
"is BTC/USD modulus 4 equal to 1"
"is BTC/USD modulus 8 equal to 1"....

So the number of decisions necessary to build the market grows by log base 2 of the number of possible outcomes.

So we need to keep an array of the outcomes of every decision that this pool of voters has ever voted on?
What happens when I send my votecoins to someone else? My old entries in the matrix are weighted by how much money I had before, and new entries are weighted by how much money I have now?

Do we need to recompute old balances in the blockchain, or record every balance of every user in every block?

I am working on implementing truthcoin full-time.

In the consensus.py file, you have a matrix called VotesUM.
What information is being stored in this matrix?

When I am finding consensus, there are many people with votecoins, and each person can vote in 4 ways:
1) not voting
2) yes
3) no
4) undecided

your matrix only holds 1's and 0's, so I guess it isn't storing the votes?

https://github.com/zack-bitcoin/truthcoin #### edit, work is happening here now: https://github.com/BumblebeeBat/FlyingFox ####

I implemented the 4 of the 8 transactions. Haven't done any testing, or added the new transactions to the gui.

The part I tried writing has to do with giving out votecoins to a group of people, and giving them decisions, and having them vote to accept decisions, and having them vote to reach consensus on the outcomes of these decisions.

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.

It looks like there are a lot of different kinds of market makers. Would there ever be a reason to implement a Bayesian version of truthcoin? Or some other type of market maker?

this caught my attention http://www.cse.wustl.edu/~allenlavoie/papers/bmm.pdf

If a developer were to create a POS version of truthcoin first, it would take little effort to modify it into a merge-mined POW currency.
Based off the number of bitcoin forks in existence, I am expecting multiple PM-coins in every flavour imaginable.

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. Instead of waiting a random amount of time for more blocks, there is a button to pay for the creation of the next block at any time. I don't waste any cycles mining blocks.

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 the increase in accuracy of knowledge will be reward in itself more often than not. People dying of cancer REALLY want to be able to increase beta to save their life.

In the implementation I am working on, one of the transactions is called "prediction_market".
If you use a new marketID, then this creates a new market. If you reuse an old marketID, then this increases beta of the existing market.

The prediction_market transaction can have multiple buy_shares transactions within it, allowing the creator of the transaction to move the price simultaneously with increasing beta.

ok, I understand now. I think that changing beta this way is a good thing. Maybe we should allow them to simultaneously purchase shares, so that they get first chance at the new reduced price.

What if it automatically purchased the correct amount of shares to keep the price at the same level?

So if you add 10 truthcoins to beta, the software automatically divides it up, and adds maybe only 2 coins to beta, and purchases 8 coins worth of shares so that the price stays the same as before you did this.

When a market is created, the creator should be able to guess at the initial price.
If his initial guess is fairly accurate, then he can reduce the cost of financing the market.

For instance... maybe 4 coins will be flipped in the future, and the market is deciding whether all 4 will land on heads, or if at least one will land on tails.
If he starts the market price at 0.50, then smart investors will quickly push the price to 0.0525, and they will probably take almost the entire beta*ln(2) deposit.

The creator of the market could have started the price at 0.0525, and then he would have made a profit instead of losing money.