Nearly 1.5 years ago Paul Sztorc proposed prediction markets (also called "futarchy") as a way of solving the block size governance issue - have a prediction market where people can bet on what the price of Bitcoin would be if event X happens and what the price would be if event X doesn't happen, and if the price on the "X happens" market is higher, then X gets implemented.

With Ethereum, the ingredients are actually here to implement all of this today, and in fact, unlike Paul Sztorc's proposals, you can do this fully trustlessly - no curators and no consortiums involved (though there are a few ways that the resulting designs are suboptimal if you don't rely on such things; I'll get into both approaches later).

The two key ingredients are as follows. First, decentralized prediction markets. We have augur and gnosis, though in this case the more suitable model would probably be the TRUMPY and TRUMPN tokens that have been traded on etherdelta. In general, prediction markets have been run on ethereum a few times and basically work as expected. The second ingredient is trustlessly reading the Bitcoin blockchain inside Ethereum. This also exists today, in the form of btcrelay, a Bitcoin "light client" that sits inside of an Ethereum smart contract and verifies block headers' proof of work to determine the longest chain (as well as being able to verify transactions against the chain via merkle proofs). In Blockstream's sidechains paper, Blockstream defines a sidechain as "a blockchain that validates data from other blockchains"; thanks to this very broad definition, we sometimes proudly market btcrelay as the world's first production sidechain, however it is important to note that while btcrelay can read the Bitcoin blockchain, it can't write to it, so the second part of the two-way-peg isn't solved, unless you're willing to accept a scheme that relies on ether deposits with large safety margins; then you can fake it with cryptoeconomic incentives - and some of our schemes will do just that.

What is the goal?

In its purest form, we can technically describe the most commonly proposed form of coin futarchy as follows. On some chain, there exists some primary token T (think T = bitcoin), and a reference token R (think R = the US dollar). If there is an event X that must be voted on, then a feature emerges where any T holder can split their T into T-X and T-no-X, and any R holders can split their R into R-x and R-no-X. If X is implemented, then a T-X token can be converted into a T and an R-X can be converted into an R; if X is rejected, then the same is the case but with T-no-X and R-no-X. We then look at the price of T-X denominated in R-X and the price of T-no-X denominated in R-no-X; if one is higher than the other for a sufficient time period, then that side is declared the winner.

There are two ways to view how this works. One is through the lens of markets, where T-X / R-X is viewed as the price prediction if X wins, and T-no-X / R-no-X is viewed as the price prediction if X loses; whatever decision the market thinks will lead to a more favorable price wins. The other way to view this is through the lens of voting: you can view the act of taking one's T, splitting it, and then selling a bit of T-no-X and using the proceeds to buy a bit of T-X as being a vote, where the vote has the force of action: the vote means "I am willing to increase my degree of membership in this community if X is implemented".

How would this be implemented?

On Ethereum, we can have the reference token be ether, but that's arguably a bad idea, as it would drive outcomes that try to increase BTC / ETH, ie. trying to benefit bitcoin at the expense of ethereum rather than benefitting the two together. A simple way out is to have the reference token be Digix gold, but that introduces a centralized party, Digix. This is arguably not that bad, as if Digix defaults then the results could be ignored, though you could make the case that it would invite attempts at manipulation by making false rumors saying "Digix will not honor their commitements to redeem their gold tokens if Segwit is adopted" (thereby pushing R-SEGWIT down and hence pushing T-SEGWIT / R-SEGWIT up, manipulating the market in favor of Segwit); it's up to each individual to determine how serious a problem this would be in practice.

What about the T side? BTC cannot be directly represented on Ethereum, but what we can do is have a fake sidechain via collateral. The design would work as follows. A contract would store 200 * n ETH and issue n E-BTC coins as well as n E-ANTI-BTC coins. By submitting a real bitcoin into the bitcoin address stored into the contract, and submitting a btcrelay proof that you did this together with an E-ANTI-BTC coin, you can claim 200 ETH. The price of an E-ANTI-BTC coin is thus equal to 200 ETH minus 1 BTC. E-BTC coins give you the right to a share of the remaining ether. Note that this scheme as written cannot survive BTC going above 200 ETH; you can either push the deposit requirements higher (say, to 1000 ETH), or add a mechanism that forces the ETH depositors to deposit more ETH when the BTC prices go high enough, though without proper 2-way convertibility the scheme certainly is not perfect (note that the collateral doesn't need to be ETH; it could also be digix gold or whatever else).

If you want to do something a bit cleaner, you could go for difficulty futures - have the R token be ether, and have the T token be an asset that releases X ETH, where X equals the bitcoin mining difficulty divided by some constant. Difficulty correlates with price, and so using mining difficulty as a proxy for price is quite reasonable, and mining difficulty also has the advantage that using btcrelay to verify the difficulty of the main chain is very easy.

In the case of Segwit and Unlimited, we can actually try out one or more or all of these models. Verifying that a >1MB hard fork was carried out with btcrelay is not too difficult: prove, one branch at a time, the total size of a block that was committed to in the main chain, and return 1 if the sum of the transaction sizes exceeds one megabyte. There are ways to optimize this further if interactive verification is allowed. Alternatively, you could take the even easier path and instead of verifying the consensus rules, just verify the signalling rule - return 1 as soon as 95% of the blocks in a given blockspan vote for Segwit, or 75% of the blocks in a given blockspan signal for some hard-forking max block size increase. If someone wants to code this, the tools are all there.