Oracle Payments

[zack]

I think it is a bad idea to pay oracles trading fees since the oracles don't participate in the trading process. Instead, we should pay them a judging fee when they do their judging.
Each oracle should have a flat-rate for how much it costs to do a judgement, regardless of how popular the topic is.

In FlyingFox the oracle is paid how I recommend.
If the gamblers agree on the outcome, then the oracle never finds out that gambling took place. If the gamblers disagree on the outcome, then one of the gamblers pays the oracle to write down the outcome on his channel-block and sign it. FlyingFox oracles do their judging off-chain.

If multiple pairs of people gamble on the same thing, as soon as the oracle judges on one pair's channel, the oracle has sort-of judge over all the channels that were gambling on the same thing. The same oracle-signature can be applied over and over to each pair of gamblers. The oracle doesn't know how many people are gambling.

[psztorc]

I think it is a bad idea to pay oracles trading fees since the oracles don't participate in the trading process. Instead, we should pay them a judging fee when they do their judging.
Each oracle should have a flat-rate for how much it costs to do a judgement, regardless of how popular the topic is.

Will the Author choose the rate? If Voters must vote on everything, or lose Rep, what is to prevent the fee from being too low. Should the marketcap of VoteCoins be entirely driven by Authors? What about increasing the set of Decisions-Slots through optional slots or Branching (how will that be regulated)?

[zack]

Great questions.
I haven't completely worked out how judging should work, but I think that moving it off-chain is a good idea. if the judgement happens off-chain, then you can find out how the judge will decide your bet without publishing the bet to the blockchain. So fewer bets have to get published to the blockchain. The only time you would have to publish a bet on-chain is if your partner loses their private key.

When judging happens off-chain, it is preferable to bet on something another pair of people is already betting on, instead of making something new, because then you might not have to pay the oracle. If the other pair of people ends up paying the oracle for a judgement first, then you can free-ride on that.

You can't tell what other people are betting on by looking at the blockchain. Bets don't get published until the outcome is known, and even then they usually don't get published.

You can't prove what you are currently betting on to anyone, except your partner who you are betting with. You can prove what you and your partner bet on historically.

If you go to an order-book exchange, and look at open bets, it will be easy to find things to bet on that are so popular they will probably be freely judged.


>Will the Author choose the rate?
There is no "author" if the bets are off-chain. pairs of people with channels can bet on whatever they want.

>What prevents the fee from being too low?
I was thinking that Sztorc style oracles would have a flat-rate that they write on the blockchain. If you publish your channel on-chain, and it has a bet that needs to be judged by this oracle, then this is the minimum amount you can pay them for the service or the tx wont be valid. If you refuse to pay the price, then the judge can refuse to do judging until it is on-chain.

>marketcap of votecoins driven by authors?
authors just aren't defined in this context, im not sure how to answer...
I was thinking there would be many competing oracles, each with a separate votecoin.
A popular judge might own votecoins in multiple oracles.
If an oracle lies, then I expect the value of it's votecoin to drop.

>increasing the set of decision-slots?
I am not sure what a decision-slot is? Since FlyingFox bets are off-chain, you could bet on billions of secret things that only you and your partner know about.

>increase the set of decisions through branching?
I assume "branching" in this context means copying the distribution of coin-holders in one oracle to create new oracles.
I was planning on allowing the creation of branches with any distribution of votecoin-holders. Even distributions where one person has all the coins.

[psztorc]

I think you would be much better off "generalizing the payment channels to Lightning Network type idea", and not messing with other factors.

Each LN hub can be like the minor stock exchanges (BATS, EDGA, ISE, IEX), and publicly offer everything with a lot of server uptime and better connectivity, etc. Individuals can conduct arbitrage among hubs (same as they do now among different exchanges). So you get the large public markets, which is what everyone wants.

Isn't the LN concept awesome?

[zack]

The LN concept you describe with stock exchanges and arbitrage is what I am trying to build. I agree it is awesome.

Truthcoin as you wrote it will not work for channel-bets, because trading fees can't be collected, so the oracle won't get paid. If we want to have LN with betting, then we need to come up with a way for the oracles to get paid.

This is related to the parasite contract problem. Every channel is like a little parasite contract.

My current proposal probably isn't optimal, but it is the only solution I have come up with so far.

[psztorc]

I'm not sure that that's right. LN's reduce transaction fees for miners, yes, but they do not eliminate them. My intuition is that there will still be transaction fees in proportion to the usefulness of each market. After all, doesn't someone need to place a big trade to "open" the market up, and buy 10 million of "Yes" and 10 million of "No", and send them to the hub, so that the Hub has them to debit/credit people? And won't multiple hubs compete, and some will do arbitrage against the actual non-Hub blockchain itself?

[psztorc]

Also, my understanding is that LN relies on incrementing the sequence number...we might, if we wanted to, force a higher trading fee as the sequence number increases.

[zack]

A channel means 2 people can give money to each other, and gamble with each other multiple times, without writing _anything_ to the blockchain.

My intuition is that there will still be transaction fees in proportion to the usefulness of each market.

Since you can't tell when people are betting in a channel, then there is no way to charge a trading fee.

A judging fee would at least ensure that the oracles get paid at all. They would get a flat rate for each judgement, regardless of popularity.

After all, doesn't someone need to place a big trade to "open" the market up, and buy 10 million of "Yes" and 10 million of "No"

Channels can be used to make order books very simply, because channels allow pairs of people to make bets with each other.
There is no way to buy yes shares in a channel, unless your partner is willing to hold the opposite position.

To make a market maker with channels is a little complex, the hub would have channels with each trader, and the hub would update all of traders simultaneously by hash locking them. That way the hub and traders never have to trust each other.
Only the hub knows the volume of trading that occurs. He could lie about it, and no one could prove otherwise. So if we charge him a fee based on his volume of trading, then he will lie and say a very small volume of trades occurred.

And won't multiple hubs compete, and some will do arbitrage against the actual non-Hub blockchain itself?

There will be arbitrage between the Hubs, but not between the blockchain and a hub.
You can't hashlock the blockchain with a channel.
Hashlocking channels is how you simultaneously adjust multiple channels to allow arbitrage without risk.
Blockchain-hub isn't arbitrage, because one of your trades might not succeed, so you are exposed to risk.
I wasn't planning on allowing open bets on the blockchain at all.

Also, my understanding is that LN relies on incrementing the sequence number...we might, if we wanted to, force a higher trading fee as the sequence number increases.

You are correct that each channel has a sequence number that increases every time you update the channel.
You are wrong in thinking that you can look at other people's sequence numbers. This number is written in the channel, and can only be seen by the 2 participants in the channel.

[psztorc]

A channel means 2 people can give money to each other, and gamble with each other multiple times, without writing _anything_ to the blockchain.

"Gambling" and "voluntarily sending money" are two different things. For starters, how do the 2 people decide who won the gamble?

Also, again, your other points assume that the channel is private, while market work better when they are public. I don't think anyone will want to use a private channel when there is a public channel.

[zack]

"Gambling" and "voluntarily sending money" are two different things. For starters, how do the 2 people decide who won the gamble?

If the gamblers agree on the outcome, then the oracle never finds out that gambling took place. If the gamblers disagree on the outcome, then one of the gamblers pays the oracle to write down the outcome on his channel-block and sign it. FlyingFox oracles do their judging off-chain.

If multiple pairs of people gamble on the same thing, as soon as the oracle judges on one pair's channel, the oracle has sort-of judge over all the channels that were gambling on the same thing. The same oracle-signature can be applied over and over to each pair of gamblers. The oracle doesn't know how many people are gambling.

Also, again, your other points assume that the channel is private, while market work better when they are public. I don't think anyone will want to use a private channel when there is a public channel.

Where are these public-channels described? That sounds like an oxymoron to me. Like a hot-cold thing. "channel" means off-blockchain, and "public" means verifiable.
or are you saying "public channel" to mean "publishing tx to the blockchain like normal"?
If you do that, it can't scale as well. It will be slower to download, have higher fees, require more powerful computers for a full node, higher minimum bandwidth requirements for full nodes, so that it can be used in less places around the world.

[psztorc]

I simply mean a lightning network with a MSR, that is publicly usable (that anyone can open a channel with). Then most trades might take place off-chain.

[zack]

I simply mean a lightning network with a MSR, that is publicly usable (that anyone can open a channel with). Then most trades might take place off-chain.

That is exactly what I am building. I have discovered some limitations that we need to be aware of, since we are to move bets off-chain:
1) The person operating the MSR can lie about the volume of trades.
If we charge him a fee based on volume, he will lie downward to shrink the fee. If we don't charge a fee based on volume, he will lie upward to look more popular.
2) The MSR is a parasite contract. There is no way to force him to pay a volume based fee to the oracle because we cannot measure the volume of bets. so the oracle is not being paid.

So, If we really want to do betting in channels, we need to change how the oracle gets paid.
I think the solution is to pay the oracle for providing judgement, instead of paying it based on volume of trade.
If a pair of traders can't agree on the outcome of the MSR, then they pay the oracle to write the result on their contract and sign it. Like a dispute resolution.
Another elegant thing about doing it this way, is that, even the act of judging is off-chain.

I think it would be a lot easier to update bitcoin to support off-chain judging instead of on-chain judging.
2 of 3 multisigs are used for contract-for-differences on bitcoin already at companies like Hedgy. You just need to make the 3rd signature require the Sztorc consensus process to sign.
The signature seems to be the part of bitcoin they are most comfortable modifying. Like when they made all the custom scripts into pay-to-script-hash, that solved half of the off-chain problems right there.

[psztorc]

That is exactly what I am building. I have discovered some limitations that we need to be aware of, since we are to move bets off-chain:
1) The person operating the MSR can lie about the volume of trades.
If we charge him a fee based on volume, he will lie downward to shrink the fee. If we don't charge a fee based on volume, he will lie upward to look more popular.
2) The MSR is a parasite contract. There is no way to force him to pay a volume based fee to the oracle because we cannot measure the volume of bets. so the oracle is not being paid.

Why do you use language like "there is no way"? Have you investigated and disproved my sequence numbers suggestion:

Also, my understanding is that LN relies on incrementing the sequence number...we might, if we wanted to, force a higher trading fee as the sequence number increases.

I suggest you provide the proof, before you make claims of that strength. If you don't have the proof, you should really throw in more "I think that..." 's or people reading this will misunderstand your self-interpretation of the strength of your argument.

[zack]

Also, my understanding is that LN relies on incrementing the sequence number...we might, if we wanted to, force a higher trading fee as the sequence number increases.

Have you investigated and disproved my sequence numbers suggestion...

I suggest you provide the proof, before you make claims of that strength. If you don't have the proof, you should really throw in more "I think that..." 's or people reading this will misunderstand your self-interpretation of the strength of your argument.

You are right, I wasn't thinking of sequence numbers enough. Thank you.

The channel needs an additional sequence number for each oracle it is connected to. Inside the channel is the bet-state. It contains the hash of the english explanation of the bet, and the amounts of money each side is wagering. Changing the bet-state involves incrementing the sequence number associated with the oracle who decides the outcome of that bet and getting the new bet-state signed by the oracle. That way the oracle always knows what bet sequence number you are on, so he can slash you if you try publishing an expired channel-state.
Changing any part of the channel involves incrementing the main sequence number, so the main sequence number will be higher than any of the bet sequence numbers.

[zack]

Unfortunately, charging any type of trading fees, whether off-chain or on-chain, is still vulnerable to parasite contracts.

Only judging fees are safe from parasite contracts.