Topics

A crude front-end: code and demo. Just discrete PM trading/betting, no forms for voting to resolve event outcomes, yet.

Slap it on top of your preferred TruthCoin back-end stack   And polish the UI/CSS theme while you're at it.

Suggestions, critiques, corrections?

Binary event LMSR is pretty easy, but continuous events are another matter. I've been trying to understand the scaled contracts spreadsheet. Just the basic scaled one for now (multi-variate scaled next time).

I annotated it with some notes and questions:



Main question is, how is the event resolved, and payouts done for a scaled contract?

The Ethereum blog has a new SchellingCoin post, its a follow-up to the first.

The core idea in the first post is this:

5. Every user who submitted a correctly submitted value between the 25th and 75th percentile gains a reward of N tokens (which we'll call "schells")

I see the core idea in TruthCoin as, basically, an extension to this. In TruthCoin, users who submitted consensus votes get a reward of N tokens ("TruthCoins" or "VoteCoins" depending on the naming scheme). With SchellingCoin, users are submitting a value (voting) of a single outcome, and the consensus is measured by taking the simple median value of all the votes. With TruthCoin, users are voting on a whole set of decisions, and the consensus is measured by taking the principal eigenvector (SVD) of the vote matrix. Taking the principal eigenvector is just a way to do dimensionality reduction on the multi-dimensional matrix of voter-decisions, the result is a multi-dimensional mean: "the first principal component corresponds to a line that passes through the multidimensional mean..."

SchellingCoin measures the consensus vote over a single decision. TruthCoin measures the consensus vote over multiple decisions. Both reward users for submitting consensus votes, and punish users for submitting outliers.


The second SchellingCoin post describes users sending a deposit along with their vote:

At the end of the epoch (or, more precisely, at the point of the first "ping" during the next epoch), everyone who submitted a value for P between the 25th and 75th percentile, weighted by deposit, gets their deposit back plus a small reward, everyone else gets their deposit minus a small penalty, and the median value is taken to be the true UScent/wei price. Everyone who failed to submit a valid value for P gets their deposit back minus a small penalty.

This deposit system introduces stake to prevent sybil attacks. TruthCoin also uses stake as a defense against sybil attacks: users have to own truthcoins in order to vote, and votes are weighted by the amount of truthcoins at stake. The difference here is that the TruthCoin "deposit" is made up-front: its just the user's purchase of some TruthCoins. In SchellingCoin, each and every vote carries its own separate deposit. TruthCoin votes are also weighted by reputation - another extension of the SchellingCoin model.

Now I'm going to repeat some things I said before:

TruthCoin is basically an extension of SchellingCoin.

"Price-pegging" by portfolio replication is totally different, would be better called price-tracking. Tokens are issued which would track the price of BTC (or USD, or any other asset) through a decentralized hedging contract, described by vbuterin in SchellingCoin.

"""Whatever helps you think about it. I think SchellingCoin makes no sense, and misuses the Schelling Point idea, which requires a completely symmetric and simultaneous game with one information set and multiple equilibria all with exactly the same payout. Nothing even close to what Vitalik wrote about."""

Well, I guess Vitalik is looking for a succinct name of the underlying principle, at risk of pedantic inaccuracy (he faced similar criticism when he distinguished the Ethereum scripting language by calling it Turing-complete).

My argument is that it is the same underlying idea behind SchellingCoin and TruthCoin, and even the bitcoin blockchain:

Thus, knowing only that the only value that other people's answers are going to be biased towards is the actual wei/UScent, the rational choice to vote for in order to maximize one's chance of being near-median is the wei/UScent itself. Hence, it's in everyone's best interests to come together and all provide their best estimate of the wei/UScent price. An interesting philosophical point is that this is also the same way that proof-of-work blockchains work, except that in that case what you are voting on is the time order of transactions instead of some particular numeric value;

Is there a better name for this than Schelling Point?

His post starts by discussing an idea of "Eigenmorality".

In an attempt to measure the players' morality, Tyler uses the eigenmorality idea from before. The extent to which player A "cooperates" with player B is simply measured by the percentage of times A cooperates. ... This then gives us a "cooperation matrix," whose (i,j) entry records the total amount of niceness that player i displayed to player j.  Diagonalizing that matrix, and taking its largest eigenvector, then gives us our morality scores.

Note that the linear algebra here, diagonalizing a matrix and taking its largest eigenvector (aka principal eigenvector), is exactly what TruthCoin does, by way of Singular Value Decomposition (SVD) on the vote-matrix. The largest eigenvector of the TruthCoin vote-matrix is the voter consensus, and that "consensus vector" is then used as the input to Reputation Based Coin Redistribution (RBCR).


After outlining Eigenmorality, his train of thought leads to linear algebra for crowdsourced democracy:

At first glance, the above definitions sound ludicrously circular—even Orwellian—but we now know that all that's needed to unravel the circularity is a principal eigenvector computation on the matrix of trust.  And the computation of such an eigenvector need be no more "Orwellian" than ... well, Google.  If enough people want it, then we have the tools today to put flesh on these definitions, to give them agency: to build a crowd-sourced deliberative democracy, one that "usually just works" in much the same way Google usually just works.

But wait, how would using linear algebra work better than relying on trusted subject-matter experts? Because, linear algebra lets us objectively distinguish liars' attempts to distort the consensus:

Now, would those with axes to grind try to subvert such a system the instant it went online?  Certainly. ... So there would arise a parallel world of trust and consensus and "expertise," mutually-reinforcing yet nearly disjoint from the world of the real.  But here's the thing: anyone would be able to see, with the click of a mouse, the extent to which this parallel world had diverged from the real one. ... The deniers and their think-tanks would be exposed to the sun; they'd lose their thin cover of legitimacy.

Here he proposes using an eigenvector as a "force of law":

But the point of an eigentrust system wouldn't be to convince everyone.  As long as I'm fantasizing, the point would be that, once people's individual decisions did give rise to a giant connected trust component, the recommendations of that component could acquire the force of law.  The formation of the giant component would be the signal that there's now enough of a consensus to warrant action, despite the continuing existence of a vocal dissenting minority—that the minority has, in effect, withdrawn itself from the main conversation and retreated into a different discourse. ... This is still democracy; it's just democracy enhanced by linear algebra.

This is what TruthCoin does. Again, the principal eigenvector of the vote-matrix becomes a "force of law" (as in the Lawrence Lessig slogan, "code is law") that awards/redistributes p2p digital coins.

The obligatory citation of Robin Hanson and futarchy:

Other people will object that, while we should use the Internet to improve the democratic process, the idea we're looking for is not eigentrust or eigenmorality but rather prediction markets.  Such markets would allow us to, as my friend Robin Hanson advocates, "vote on values but bet on beliefs."  For example, a country could vote for the conditional policy that, if business-as-usual is predicted to cause sea levels to rise at least 4 meters by the year 2200, then an aggressive emissions reduction plan will be triggered, but not otherwise.  But as for the prediction itself, that would be left to a futures market: a place where, unlike with voting, there's a serious penalty for being wrong, namely losing your shirt.  If the futures market assigned the prediction at least such-and-such a probability, then the policy tied to that prediction would become law.
...
But just like Google, whatever its flaws, works well enough for you to use it dozens of times per day, so a crowd-sourced eigendemocracy might —just might— work well enough to save civilization.

An addendum in response to the comments discussion. He asks, is there a way to incentivize people and "suss out the truth"?

Moving on to eigendemocracy, here I think the biggest problem is one pointed out by commenter Rahul.  Namely, an essential aspect of how Google is able to work so well is that people have reasons for linking to webpages other than boosting those pages' Google rank.  In other words, Google takes a link structure that already exists, independently of its ranking algorithm, and that (as the economists would put it) encodes people's "revealed preferences," and exploits that structure for its own purposes.
...
By contrast, consider an eigendemocracy, with a giant network encoding who trusts whom on what subject.  If the only reason why this trust network existed was to help make political decisions, then gaming the system would probably be rampant: people could simply decide first which political outcome they wanted, then choose the "experts" such that claiming to "trust" them would do the most for their favored outcome.  It follows that this system can only improve on ordinary democracy if the trust network has some other purpose, so that the participants have an actual incentive to reveal the truth about who they trust.  So, how would an eigendemocracy suss out the truth about who trusts whom on which subject?  I don't have a very good answer to this, and am open to suggestions.

A couple of comments already hint at the similarities to bitcoin:

That "trust" network discussion reminds me of the bitcoin network somehow...
...
(1) This seems very similar to the block chain innovation used in bitcoin.

See also: HN discussion

Purchasing reputation is a type of sybil attack (similar to ballot stuffing). This is often one of the first issues brought up as a weakness in TruthCoin's use of voters, especially when considering the possible scenario where TruthCoin might be used to adjudicate the outcomes of bets denominated in bitcoin. I'm not sure that the current docs are clear enough on how TruthCoin prevents such sybil attacks.

In particular, here is an ongoing reddit thread exemplifying the confusion:

Another problem that I have with TruthCoin though... Doesn't it assume that someone could "buy truth"? Let's say that TC's market cap is 1M ether. I could then create a contract for 2M ether, and buy enough TC to swing the vote in my favour? I'd lose my all TC because of that, and probably kill te whole TC currency, but i'd be awarded for 2M for the contract fulfillment. In oher words - Isn't TC feasible to protect a contract only up to an amount of TC's market cap?

And further down...

> TruthCoin voter decisions are not used to adjudicate the outcomes of prediction markets in other coins.

Well, this is a direct quote from the TruthCoin whitepaper. Article IV, Page 19, section (b).(i.):
"Most critically of all, this system will have to sign Withdrawal Transactions so that users can bring Bitcoin out of this system and back into their personal wallets."

Also, straight from the Abstract on Page 1:
"Bitcoin users can create PMs on any subject, or trade anonymously within any PM, and all PMs enjoy low fees and permanent market liquidity through a LMSR market maker."

So it seems that you missed something about TruthCoin

Maybe a paragraph or two can be written to address this argument in particular, and clear up the confusion? Its not the first time I've heard someone raise the same objection.

Not an art critic, but I found this to be a fascinating read: The ABC of Accelerationist Blockchain Critique

From r/ethereum

Futurecoin: a decentralized prediction market. Joseph Bonneau, Jeremy Clark, Edward Felten, Joshua Kroll, Andrew Miller and Arvind Narayanan. To appear, WEIS 2014. June 2014.  from Andrew Miller's page

Probably this paper: On Decentralizing Prediction Markets and Order Books. It cites TruthCoin, but says this about using a voting system for outcome judgement:

... assuming a market with a clear outcome, this system produces an iterated game of chicken between coalitions of voters holding shares in each outcome. If either coalition is able to convince the other that they are absolutely going to spend their N/2 votes on their preferred outcome, the other side is incentivized to back down and concede to prevent losing their bond. It is only be repeated play, in which participants have a reputation to maintain that will be damaged if they vote for a patently incorrect outcome, that this game can be avoided. Thus we think this approach is less desirable as it requires tracking reputations for all participants in the market and not just a small number of adjudicators.

This started out as a response to "The case for building on bitshares_toolkit", but I got a bit carried away and ended up with the epic wall of text you see below. I'm going to cross-post it to r/ethereum, but I hope here to spark a discussion specifically about TruthCoin, and the advantages that a TruthCoin DApp on Ethereum would have over a special-purpose alt-chain.

======

* Bitcoin and Alt-coins are Special-Purpose Chains
What's the difference between a general-purpose blockchain and a special-purpose blockchain? Let's start with bitcoin, the original special-purpose chain for computing and comparing sha256 hashes. Bitcoin users started the chain by mining on generic x86 (general-purpose) CPUs. But because sha256 hashing is a specific computation, btc mining is now dominated by Application Specific Integrated Circuit (ASIC) hardware. Litecoin is another special-purpose chain, except it computes scrypt hashes (some manufacturers are already started shipping scrypt ASIC miners). There's also a Primecoin for computing prime numbers, and a bunch of other special-purpose chains commonly known as alt-coins.

* Special-Purpose Chains: Backend and User Perspective
How does it work when we want to use the services provided by separate special-purpose chains? Let's look at the granddaddy of alt-coins, namecoin, which like bitcoin uses sha256 hashes. Additionally, it also provides some standard namecoin script opcodes for associating plaintext pseudonyms with unique addresses (public/private keypairs), so namecoin addresses can register and "own" domain names or identities/handles. Let's say you want to use bitcoins to purchase a namecoin .bit domain that its owner is selling. What does it take to get these two special-purpose blockchains (bitcoin and namecoin) to interact with each other? The immediate option (and the only one available today) is a centralized service running a web server in front of both p2p daemons (as nodes of their respective networks, bitcoind and namecoind). That centralized service is a BTC/NMC exchange, and maybe it has an interface allowing you to register "dot-bit" names (otherwise you'd have to open up two separate wallets - one for each coin). The centralized exchange is a trusted third-party that holds in escrow the BTC and NMC of each user (whose coins could be stolen by a dishonest exchange operator).

* A General-Purpose Chain: Backend and User Perspective
So how is using a unified general-purpose chain different from a special-purpose one? On the Ethereum general-purpose chain, each service is provided by some "DApp" (distributed app "hosted" by all ethereum miners). A DApp is an interface to a specific "contract", running at some address on the blockchain. For instance, to register a name, you would open the EtherNames DApp in the ethereum client's built-in browser, type in the name you want to register, and "send" the registration as a transaction with data. There's no need to copy and paste addresses since the Ethereum client provides hooks for seamless wallet access inside every DApp. The registration transaction is sent to the EtherName DApp's contract address, which is running some variant of the namecoin contract code. A specific contract gets initialized at a particular address by some untrusted third-party individual/entity (the DApp author). The contract author is *not trusted*, all the author does is upload the contract code and pay the initial "gas" fee. The contract code is independently executed and verified by each ethereum miner as part of a single atomic transaction. Atomicity means that the ledger database updates are all-or-nothing, so no user has to worry about the risk of having to pay first because any and all transactions needed to fulfill a contract are guaranteed to occur within the same block, or the contract is broken and won't run at all. Think of Ethereum contracts as interconnected threads in a big web of complex multi-sig transactions of Ethers and contract-specific sub-currencies, all of which run atop the same unified blockchain.

* Special-Purpose Chains: Developer Perspective
From the developer's perspective, operating a service that uses two separate special-purpose chains requires maintaining both blockchains (upgrading separate software, providing enough processing power, disk space, and bandwidth for each chain). It also requires maintaining user accounts, as well as wallets on two separate chains (multiplied by the number of users). Hosting a server is needed to run both the namecoin daemon and bitcoin daemon (unless outsourced to a centralized API). The web developer will need to maintain a web server and app stack such as LAMP (Linux Apache Mysql Php) or MEAN (Mongodb Express Angular Node). Finally, the service must hold the users' deposits of bitcoins and namecoins in secure hot wallets and offline cold storage, keeping them safe from hacker thieves. Altogether, every service operator needs to independently maintain a separate full-stack system, which can be a herculean effort.

* A General-Purpose Chain: Developer Perspective
A service operating on Ethereum has a DApp backend hosted right on the blockchain, maintained by miners (who earn gas fees). A developer simply authors the contract code and pays the gas fee to initialize it on the blockchain, which is much easier than forking an alt-coin to start yet another genesis block. DApp's do not need a separate API for access and integration by other developers; authors just name functions inside a contract, directly exposing an API (with optional fee-per-use) that enables message calls from any other Ethereum DApp. Also, DApp authors do not need to maintain user accounts, since the users interact with the DApp directly on the blockchain through their ethereum addresses. Nor do DApp authors need to maintain user wallets since private keys stay private in a decentralized system. Unlike the current convention where coins are deposited to a wallet address controlled by some third-party, in a truly decentralized system private keys are only used for signing transactions as inputs to contracts.

* Meta-Coins as Feature Specs
Meta-coin protocol extensions like Colored Coins, MasterCoin, and CounterParty work by organizing a group of users who agree to interpret bitcoin transaction data according to some metadata specification, supplementing the base rules of the bitcoin protocol. For example, MasterCoin specifies creating multisig 1-of-n bitcoin transactions and encoding data in the n-minus-1 unused public keys. In the meta-coin approach, each feature or "contract" is specified in the meta-protocol. Two MasterCoin features are registration of a data stream and the creation of a sub-currency, these are baked into the specification and reference client alongside the other features. While you can register new data streams and sub-currencies, if you want to create a new contract that is some kind of a hybrid between a data stream and a sub-currency, such as a call/put option or a Contract For Difference (CFD), it would need to be implemented directly in the reference client, and unlocked as a feature at some future block number. Implementing new features in a meta-coin protocol that doesn't have a scripting language requires specifying them directly in the protocol and must be effected at the organizational level.

* Scripts and DApps vs Forks and Features
Embedding a scripting language into a crypto-currency gives it the same kind of extensibility that gamers crave in video games. Scripts empower players to create "mods" and customize their game-world with new levels, characters, and maps. In the crypto-currency world, scripting allows for the extension of a plethora of decentralized features such as trading, lotteries, and ecommerce, all atop a shared, compatible platform. Bitcoin has a scripting language, but with severe limitations including: lack of loops, binary state variables limited to spent or unspent transaction outputs, and blockchain blindness. The difficulty of using bitcoin script has in effect given rise to a landscape of competing alt-coins and meta-coins with incompatible protocols. The preferable route, and vision of Ethereum, is to foster a fully-featured ecosystem of compatible, interacting DApps. Providing a Turing-complete scripting language on a general-purpose blockchain with message calls between contracts stimulates adoption of Ethereum as a shared decentralized Operating System and kernel.

* Decentralized House, Decentralized Dealer
Consider the concept of a decentralized lottery. In a semi-decentralized lottery that is merely provably fair, although the operator is not capable of altering any particular dice outcome, he can simply shut down the service immediately after a big winning bet comes in, scamming the user of his money and winnings. But in a fully decentralized lottery, the mechanism for distributing the winnings is written into the contract itself (open-source and audited by users), so no central operator is needed. While writing such a contract in bitcoin script is theoretically possible (see pages 12-15), to my knowledge none has been implemented. In practice, it is easier to create a LottoCoin as a special-purpose alt-chain. In contrast, writing a script on the Ethereum platform for a fully decentralized lottery is not only feasible but relatively easy.

* Conclusion
The limitations and difficulties of using bitcoin script to implement decentralized features natively on the bitcoin blockchain has resulted in a fragmented ecosystem of incompatible, competing alt-chains and meta-coins. While it is theoretically possible to use bitcoin script for complex contracts like cross-chain atomic trading, practical implementations of such features have yet to be achieved (to my knowledge). On the other hand, Ethereum focuses on providing an easy-to-use scripting language for implementing advanced contracts on a general-purpose blockchain. Ethereum's extensible platform enables the realization of advanced decentralized features that previously were inaccessible.