state channels

[zack]

http://forum.groupgnosis.com/t/we-need-smart-markets/113/3

a state channel is like the channels that make up the bitcoin network, but they contain arbitrary state. The 2 participants of the channel can make bets with each other without wasting space on-chain.

Before this new discovery, if there was a dispute the entire contract is published on-chain, and computed over.

With this new design, only a single word of the code gets revealed, and a single moment of state.
If the code is X words long, closing the channel involves log(X) transactions.

This new design for channel state will allow us to do more intense computations. Opening up the possibility for anti-arbitrage smart markets like koeppelmann suggests. It will be affordable to compute intense SVDs off-chain.

Maybe it is time for bitcoin hivemind to move the oracle resolution off-chain.

[psztorc]

> a state channel is like the channels that make up the bitcoin network, but they contain arbitrary state. The 2 participants of the channel can make bets with each other without wasting space on-chain.

I have a way of doing this, which I will try to publish tonight I guess.

Zack, you should be aware that I believe a few things:

1. No one involved with Ethereum knows anything useful about Bitcoin, the blockchain, or smart contracts. They are so far gone that it is pointless to even open a dialogue with them (about anything).
2. Generalized Smart Contract platforms (Ethereum/Rootstock) destroy the ability to compute an honest Oracle, making Truthcoin impossible while such systems exist. Since they provide no other benefits, Eth/Root will almost certainly not exist.
3. Moving the oracle resolution off chain is a bad idea, something akin to individuals who only pay taxes if they needed to call the police for help last year -- the result would be an underfunded police department, rampant theft, and everyone smart would move away (or avoid accumulating capital)...it would be impossible to ever raise tax money, in any way, and the town would have collapsed into violence and/or be avoided by everyone.

You are free to spend your time however you like, but it is a shame to see someone so dedicated waste so much spirit.

[zack]

I was confused before, let me clarify: We should use the technology being introduced in this thread, even if we don't use channels or smart contracts at all.
SVD is too slow when the matrix is big. If x is the size of the matrix, it takes something like O(x^2) cycles to compute the SVD. If we used this new technology we only need to use O(2*log(x)) cycles, a massive improvement.

3. Moving the oracle resolution off chain is a bad idea, something akin to individuals who only pay taxes if they needed to call the police for help last year -- the result would be an underfunded police department, rampant theft, and everyone smart would move away (or avoid accumulating capital)...it would be impossible to ever raise tax money, in any way, and the town would have collapsed into violence and/or be avoided by everyone.

Your argument against off-chain resolution reminds me of the argument against torrents:
No one will pay musicians if music is free, so we wont get new music any more.
But torrents didn't kill music. The music industry adapted to making money in different ways.
It doesn't matter what is best for musicians or music. Customers prefer to pay less. The cheapest technology wins.

When channel state changes, it usually has to go through one or more hubs. The hub collects trading fees.
The hub wants there to be lots of traders so he can collect lots of trading fees. There will only be lots of traders if there is a reliable oracle.
The hub will spend money regularly for the oracle to settle questions that are being gambled on, even though the results wont get put onto a blockchain. He publishes settlements from the oracle to prove that the oracle works as it should.

Once there are multiple hubs, they will probably share an oracle for some bets.
To fund settlement for an oracle that is shared between hubs, they could use a truthcoin dominant assurance contract.

Since they provide no other benefits, ...[generalized smart contracts] will almost certainly not exist.

What about the ability to update the SVD, or the market maker, or the order book, or the match maker?
What if we want to change from continuous trading to batch trading?
There is no way we will get this all right the first time. Smart contracts let us update later.

[psztorc]

> SVD is too slow when the matrix is big.

Reread the whitepaper. SVD can reliably handle matrices of 500 Million rows by 150,000 columns. Ours will never even come close to being that big.


> But torrents didn't kill music. The music industry adapted to making money in different ways.

More importantly, humans feel a natural compulsion to express themselves through music. Oracles are different, because they can steal money today, they will *need* to be (over)paid in the future. This is a mathematical result from the field of mechanism design, and not really up for debate.


> It doesn't matter what is best for musicians or music. Customers prefer to pay less. The cheapest technology wins.

The cheapest technology may win, but there's no knowing how much music will be destroyed in the process of winning. Reread the beginning of my "Oracles are the Real Smart Contracts" post...cancerous cells, in the human body, do indeed "win". It "doesn't matter what is best for the organ or the organism", the cancerous cells multiply anyway...until the organism dies (and the cancer cells with it).


> When channel state changes, it usually has to go through one or more hubs. The hub collects trading fees.
> The hub wants there to be lots of traders so he can collect lots of trading fees. There will only be lots of traders if there is a reliable oracle.

Again, it is like saying "the organism will only survive if he doesn't get cancer". It's perfectly true, but it doesn't help us prevent or treat cancer.


> The hub will spend money regularly for the oracle to settle questions that are being gambled on, even though the results wont get put onto a blockchain. He publishes settlements from the oracle to prove that the oracle works as it should.
> Once there are multiple hubs, they will probably share an oracle for some bets.

The more money directed to the oracle, the more likely the oracle is to work correctly. So, the best thing would be for as many hubs to share the same oracle as possible (which is the current setup because they call share one oracle).


> To fund settlement for an oracle that is shared between hubs, they could use a truthcoin dominant assurance contract.

These are highly experimental and you should probably assume that they don't exist, until we can learn more about if they ever work for anything.


> There is no way we will get this all right the first time. Smart contracts let us update later.

I think we'll get it right the first time. Updating SVD / MM / OB / MM is almost certainly not necessary, and changes to trading can arise naturally from a hub-and-spoke model. As long as the costs are correct (people pay, on blockchain, for the real life resources they consume), people will self-organize to minimize cost.

Moreover, as far as updates are concerned, "smart contracts" is entirely equivalent to a "hard fork", so there is no difference. Any C++ compiler is Turing-Complete.

[zack]

Reread the whitepaper. SVD can reliably handle matrices of 500 Million rows by 150,000 columns.

I doubt that we can compute the SVD of a 75 terabyte matrix in a reasonable time.
In bitcoin hivemind, starting a full node means re-computing the SVD of every oracle judgement ever, right?

Maybe SVD is efficient, great. But Martin's example sure isn't, and it is important too. We want to be able to completely remove the need for arbitrage between markets. The USD:GOLD, GOLD:BTC, and BTC:USD markets make a triangle, if someone buys in one, it should change the prices in all three. It is better to make one big market to hold these many types of shares.
There is no limit to the number of prices that are related. The more we can fit into a single market, the less we bleed to arbiters. 

Casey Detrio's ideas about batch based trading look like they could get computationally expensive too.

Oracles are different, because they can steal money today, they will *need* to be (over)paid in the future.

I agree that oracles need to be over-paid. They can be over-paid by hubs too. They don't need to collect trading fees to be over-paid.

Moreover, as far as updates are concerned, "smart contracts" is entirely equivalent to a "hard fork", so there is no difference. Any C++ compiler is Turing-Complete.

Will you be removing bitcoin script from bitcoinhivemind then?

I think that turing completeness in ethereum was a mistake. I prefer how bitcoin script works, it is not turing-complete.

When I use bitcoin script to write up custom multi-sig contracts, do you think it is equivalent to a hard-fork?
How come the bitcoin community is debating the 2 megabyte block update so much? Shouldn't it be "entirely equivalent" to writing up a bitcoin script contract?

FlyingFox script is not turing-complete. It is very similar to bitcoin script, with a few more opcodes added to make it easier to write stuff like oracles and markets.