Blockchain for building upon

[zack]

######## edit
This very popular thread has a lot of links in it that point to unmaintained code.
My efforts to build truthcoin are happening here now: https://github.com/BumblebeeBat/FlyingFox

I used what I learned from slasher when I built FlyingFox. slasher was a prototype.
########

https://github.com/zack-bitcoin/slasher

I made this small cryptocurrency specifically for building things like truthcoin out of it. It is a pure POS currency like blackcoin, but does not use any bitcoin code. It is all python that I wrote.

New transaction types can be quickly added by editing the transactions.py file.
I am trying to figure out all the transactions for implementing truthcoin, here is what I have so far:

1) create a jury.
Creates some money. The holders of this money collectively vote on decisions. If they vote well, the money grows, if they vote bad, it shrinks. Juries might specialize for topic. Maybe one group of jurors only does basketball games, another deals with politics, etc. They can all have different fees as well.

2) offer a decision to the jury.
Decisions have text explaining "Obama will win the presidential election" and a date that it expires, like 2 weeks after the election. When it expires, the jury comes to consensus about the outcome.

3) jury votes to accept a decision, or to reject it.
Juries don't want to deal with vague sounding decisions that are hard to decide on. They don't want to have to drive far, or waste much time learning something new.

4) juries vote on the outcome of a decision after it expires.

5) anyone can create a new prediction market.
(in ethereum speak, a prediction market is a type of "contract")
The prediction market depends on a bunch of undecided decisions that juries have agreed to.
The PM sells at least 2 types of tokens, one type will eventually be declared a winner, and it will be worth 1 truthcoin. all the other types go to zero.
Each PM only accepts one type of money. Either truthcoins, or one type of token.

6) anyone can buy tokens from any prediction market.

7) anyone can sell tokens to the prediction market they purchased it from.
*not always true. The author of a PM can choose to disallow this feature. disallowing the selling of tokens is useful in the case of funding public goods.

the ability to spend truthcoins, to spend the tokens that you buy from PMs, and to spend the juror money.

Does this seem like sufficient transaction types for the entire truthcoin? or am I missing something?

[psztorc]

I'm currently in the process of fleshing this out a little more:
https://github.com/psztorc/Truthcoin/tree/master/docs/Development%20Plans

"1) create a jury" sounds like "create a branch", that's good because I haven't updated that part on my page, as branching may get a little more confusing.

7) anyone can sell tokens to the prediction market they purchased it from.
*not always true. The author of a PM can choose to disallow this feature. disallowing the selling of tokens is useful in the case of funding public goods.

Thank you for actually reading the papers...

The PM sells at least 2 types of tokens, one type will eventually be declared a winner, and it will be worth 1 truthcoin. all the other types go to zero.
Each PM only accepts one type of money. Either truthcoins, or one type of token.

This doesn't seem right to me. You might want to check my excel sheet demoing the market scoring rules, someone has already tried this in Etherium: http://www.mintchalk.com/c/37101

[zack]

For example, if we had a token which says "This token is worth 1 truthcoin is BTC/USD is between 600 and 630 tomorrow".

You could use that token as input for a market which sells these 2 types of tokens:
1) "This token is worth 1 truthcoin is BTC/USD is between 600 and 615 tomorrow"
2) "This token is worth 1 truthcoin is BTC/USD is between 615 and 630 tomorrow"

Every market's token possibility must be mutually exclusive. The sum of the token possibilities is the input possibility.

[zack]

http://blog.oddhead.com/2006/10/30/implementing-hansons-market-maker/

I have been using this explanation of LMSR.

If there were 5 possibilities, then the initial investment is B*ln(5) and the cost function=B*ln(e^(x_1/B)+e^(x_2/b)+...+e^(x_5/b))

[psztorc]

Oh, yes, you are correct. Where I got confused is where you said "worth 1 Truthcoin". Truthcoin were originally the 'shares' and not the 'coins'.

There's going to be severe confusion unless I do something...I'll have to think about this.

[zack]

Yeah, I am pretty bad with nomenclature.
If we can get some defined terms somewhere, I will try to stick to them.

[psztorc]

No one has ever understood the terms, so even though it is a major risk to swap out definitions, I think this will be manageable: http://forum.truthcoin.info/index.php/topic,15.0.html

[zack]

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.

[psztorc]

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

[zack]

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?

[psztorc]

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.

[zack]

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.

[psztorc]

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.

[zack]

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.

[psztorc]

This mostly looks good. Remember that I have a few of my own here: https://github.com/psztorc/Truthcoin/tree/master/docs/Development%20Plans

Also, I would check the "Timeline" on page 6. You are right that, in the Altcoin-version, preceding this there will need to be a 'create branch'.

Between 2 and 3, there is "propose a market", and of course "buy" and "sell".

3) I was thinking would go like:

Using {Pub1, Priv1}, where Pub1 owns some Votecoins.

By default (by not submitting anything), they have submitted a Ballot completely of NAs (or nan's).

1. input Ballot info: [0, 0, 1, 0.5, 1, 1, 0]
2. generate new keypair: (Pub2, Priv2)
3. unsigned_Ballot = { [0, 0, 1, 0.5, 1, 1, 0], Pub2 }
4. Encrypt the ballot
5. Sign the Encrypted Ballot
6. Broadcast the Ballot.
7. Upon inclusion, Pub1 has essentially "spent" their Votecoins (which they will get back later [this is 'RowBonus']), they can no longer be transferred anywhere.
8. The chain's participation scalar increases by the quantity of Votecoins (essentially, they have been 'sent' here).


Then step 4:
After a number of blocks have passed, the 'vote broadcast' phase is over. If you didn't vote, you're stuck having submit a Ballot of NAs.
Voters reveal Priv1.
If you don't reveal, you are stuck with a Ballot of NA.

Then, the 'RowBonus' from Factory, transfers those new Votecoin coin-values to each Voter's Pub2.

Items 3) and 4) are where I would most appreciate the input/critique of a Diehard Skeptic like gmaxwell (if anyone knows him). We should perhaps not waste his time until there is something more specific to audit, though.