Messages

I was wondering if you are going to translate it to Russian.
I assume it is hard for Russian speakers to learn about truthcoin.

At some point, truthcoin projects will start donating coins to people who translate ideas.
I heard that Augur is more popular in Chinese than English.

I have been thinking of it as a layer too.

Ideally, users would be able to both [1] use LMSR trades at the protocol layer

By "protocol layer" I am assuming you mean on-chain.
The lightning network is part of the on-chain protocol. Spending money is part of the on-chain protocol.
If a LMSR was written onto the off-chain network, that would be part of an off-chain protocol.

Creating and maintaining a line of on-chain protocol costs about 100x as much as a line of off-chain protocol, because updating the code is identical to launching a new blockchain and converting the users from the old one.

Sunk costs is a powerful and destructive force.
How does it benefit the users to put LMSR on-chain?
Can you give an example of a user who would prefer to do his betting on-chain?

It looks very good to me.
Are you translating this to a different language?

I prefer the batch-trading at uniform price method explained by Casey Detrio on Thursday at ethereum's devcon1. https://youtu.be/lmsOP1D8zNs?t=1h15m27s
He has contributed to this forum too.

The idea is that there are rounds of equal length of time, the rounds come at a regular frequency. When people make bets during the same round, the hub has to give them all the same price.

Different markets should have different frequencies. If you only check the markets once a day, it is in your interest to use markets with frequency of about 1 per day. Otherwise any open trades you leave are free options for traders who go online more frequently.
If all the traders can put their computers into the same building, then it will be more efficient to have the frequency be 10 per second or faster.

On-chain markets are limited by the speed of blocks. Ethereum is 12 seconds per block. It is possible to have markets with slower frequency, but not faster.

If your blockchain is the kind that forks (all POW blockchains, and Flying Fox, but not tendermint), then trades aren't finalized until they are enough confirmations deep. So on-chain trading is at risk of being front run by the miners.

Off-chain markets don't have these limitations. Trading can be as fast as sending messages. We can have markets at whatever frequency the customers want.
Hubs can self-impose rules that couldn't be imposed on miners.
It is possible to commit to promises in the channels. So if the hub breaks one of the self-imposed rules, then it loses all it's money in all the channels. All the rules can be wrapped in a merkle structure, so the proof that the hub broke a rule can be concise, even if the number of rules is very long.
Verifying proofs like this doesn't need turing completeness. Flying Fox's language is similar to bitcoin script.

There are many sets of off-chain rules that result in batch-trading at uniform price. One list of rules to achieve this:
* the hub agrees to include a bet in a particular round before he knows how many or the price at which the customer gambles.
* if the hub fails to include a bet that he agreed to include, then the hub and gambler both lose money.
* bets that are matched in the same round must all be at the same price.
* the off-chain state of each round must include the hash of the round before. That way we know that the rounds are ordered in time.
* if the hub signs 2 different channel states at the same round height, then he loses everything. That way the hub can't fork the market.

A benefit to off-chain markets is that we can update the list of off-chain rules that powers markets without having to modify the blockchain consensus code.

Truthcoin is partially able to stop front running at this time. It's current solution is inefficient.

The truthcoin whitepaper describes their answer to this problem on the bottom of page 40. It involves doing POW for every bet. People with the fastest computers will be able to trade faster, so this method funds the creation of miners, and encourages traders to make bets through those miners to bet faster, which means those miners will be able to see every bet before it is published.

The only solution to front running I like so far is to do a lightning bet through a hub. Some people have been incorrectly assuming that lightning bets use more liquidity than on-chain bets. This is not true.

At first, the bet does lock up extra liquidity. But later on, we can trustlessly move the bet from the indirect path to a direct path that doesn't lock up liquidity. My recent post on Martin's forum explains http://forum.groupgnosis.com/t/how-offchain-trading-will-work/63/11

Flying Fox and Groupgnosis are both being designed for lightning betting.

I also give zero authority to people who talk at these conferences. I have talked at one, I have watched a lot of talks about very bad ideas. The reason I am excited about this guy's idea is because I know the properties of merkel trees. He uses them in a creative way. If you understand merkel trees, you don't have to trust his authority. You can understand his proof.

I summarized his proof:

If someone has a block from 4 months ago in a proof of stake chain, then they should be able to prove that the block was available before other information that became available 3.8 months ago.
We can examine the merkel tree to know that order that information became available.

At DEVCON1 today in London, a guy named Jeff Coleman gave a talk explaining how we can use IPFS to make weak subjectivity secure. He calls his technique "universal hash time".

If someone has a block from 4 months ago in a proof of stake chain, then they should be able to prove that the block was available before other information that became available 3.8 months ago.
We can examine the merkel tree to know that order that information became available.

Awesome
Dominant assurance contracts work.

http://bitcoinhivemind.com/blog/chance-of-success/

You claim to give "other altcoins" a 1/10000 chance of having a majority of domain experts agree that the concept is useful in 2020. My version of truthcoin is a 100% premine altcoin. I want to bet 10 grams of my gold against 50 kilograms of your gold, which is twice as good as the odds you claim to believe.

My software: https://github.com/BumblebeeBat/FlyingFox

It is working well for me now

Does groupgnosis not have the oracle yet?
I'm sure it wouldn't be hard to re-use augur's code.
They are going to be the first to have betting off-chain it looks like.

https://groupgnosis.com/

This project is exciting. It is on ethereum like Augur. They are adding payment channels to reduce blockchain bloat.

What are you thinking of adding a second sequence number to, txs?

Right now, in bitcoin, adding a signature to a tx can change it from invalid to valid. You cannot change the amount of money that goes to each output. The only thing you can change by applying the signature is making it valid.

Some txs require signatures from multiple people. Once such a tx is part way signed, if you want to edit the contents of the tx, you have to have everyone re-sign the tx.

So if there are 5 things we are betting on, and I want you to commit to paying me if I win, then there are (5^2) - 1 different transactions you need to sign.

Maybe you are proposing that Hivemind will have a version of bitcoin script where adding a signature can change the amount of money that goes to each output, which would be a very radical change to bitcoin.

In Flying Fox I use 3 signatures when closing a channel.
BobOrAliceSigns(BobSigns(AliceSigns(ChannelTx)), BetResults)
The final 3rd signature wraps up the results of each bet into the tx.
Without the 3rd signature, it would be possible for miners to remove some of the BetResults before processing your Tx, and then the right person wouldn't win the bet.

Bitcoin scripting would look pretty different if you made the 3rd signature process possible. Bitcoin has an opcode for checking signatures, but the opcode expects the entire transaction to be signed in the normal way. What we need is to check a separate signature for each bet in the BetResults, and make sure that the signatures in BetResults is from the judges specified in ChannelTx, and make sure that the final balances are correctly summed from all the validator's judgements.

so you need an opcode that expects all this on the stack: [Sig1 Sig2 Bets SequenceNumber BetResults Sig3]
and the opcode will check that sig2 and sig1 sign over bets and SequenceNumber,
and that betresults is a valid result from bets,
and that sig3 is over betResults,
And that sig3 is from one of the 2 participants.

Bets would need to be a lists of merkle roots of things being bet on, paired with the amount bet on it.
BetResults uses the merkle root to show the pubkey of the oracles, and it has a signature from the oracle that is over: the hash of the bet, and the outcome.

When spending from this tx, to calculate the value of the unspent outputs, you need to look in the outcomes in BetResults.

As well as being a part of the scriptpubkey of the tx that closes channels, BetResults  needs to be in the scriptsig. That way, if Bob tries to provide counter-evidence, we have something to compare his evidence against.
We need a way to enforce that the same BetResults are used in both the scriptsig and scriptpubkey.
Since BetResults is the biggest part, it is especially unfortunate if we have to write it out twice on each tx.

We need a timer stopping spending from the channel Alice closed, that way Bob has a chance to provide more evidence about the channel's history.
nlocktime is no good in this situation, because Bob needs to be able to spend from the tx to provide evidence.
We would need the behaviour of nlocktime in an opcode, so that we can use a conditional so the nlocktime only applies to taking the money from the channel, and not to updating it's history. I think an opcode that gives the current blockheight would be the perfect addition.
We would need a way to tell if Bob provided any evidence that Alice failed to reveal. Bitcoin script doesn't have looping, so this needs to be a new opcode.

Have you written much bitcoin script before?
Can you tell the outputs from these?
01 02 01 02 93
01 01 64 01 02 67 01 03 68 01 02 87 64 01 07 68

If you added the better lightening network to truthcoin, maybe they would eventually put it into bitcoin too.
Bitcoin tx are currently limited to 10k bytes.
A single bet's space takes: hash of the bet, oracle's pubkey, 3 signatures, which would be around 100-150 bytes once we optimized.
So we could fit around 60 to 100 simultaneous bets into a channel made in this way, even more if we change tx size limit.


The forum is really buggy for me lately. I have to use my browser memory to find long URLs that point to this website, just to see the page.

My friend wrote up a simplified explanation of channels in Flying Fox.
I am helping to put these high quality channels into Tendermint too.

https://gist.github.com/jtremback/058daafe1116435b6a2e

How can truthcoin possibly be written on top of bitcoin source? The incompatibilities are big.

Bitcoin channels are NOT designed for betting. You can't bet at all yet. Space and time requirements increase exponentially as you hash-lock or bet on more things.

I had been imagining hubs in the network making a profit by taking part in bets for arbitrage.
If the cost of adding a bet to a channel is too high, then it wont be possible to do arbitrage as often.

Bets in channels will work like hash-locked transactions.
In the bitcoin lightning network, as far as I can tell, to make a hash-locked transaction, you create 2 nearly identical copies of a channel tx at different nonce-heights. Each tx needs to be valid, so it needs to be signed over and contain all the same pieces redundantly.
One tx is valid if the secret is never revealed.
The other tx is valid once the secret becomes revealed.

So what if there are 3 payments in progress, each with a different secret? Any of the secrets could end up staying un-revealed. So there are 2^3=8 different possible outcomes to prepare for. You and your partner need to make a channel-block for each of the 8 situations ahead of time, otherwise you would have to trust your partner.

Betting is a lot like hash-locks, except it takes longer for the outcome to be known, so you need to have many more of them in parallel. Each bitcoin transaction takes around 300 bytes. Assuming you had a gigabyte of space for storing bets, and you were willing to send a gigabyte to your partner back and forth over the wire, and you were willing to sign 33 million times to update, you could have 25 bets simultaneously per channel. Each signature takes 0.003 seconds on my machine, so it would take 29 hours for my computer to do my half of the signatures to update the channel once.

If I was limited to the more reasonable 10 bets per channel, it would take my computer 5 seconds to make the signatures to update the channel once, and it would only take 300 kilobytes of space.

The version of Truthcoin I am working on will have sane channels. You only need 2 copies of the channel at a time, even if you are betting on multiple things. https://github.com/BumblebeeBat/FlyingFox
In Flying Fox, adding an extra bet to your channel takes 32 bytes for the hash, plus ~2 more bytes of formatting.
You can update a channel of 300 bets by making a single signature in 0.003 seconds, and it would only take 20 kilobytes of space in total.