limitations of bitcoin lightning network

[zack]

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.

[zack]

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

[psztorc]

Hivemind does not necessarily need to use the Bitcoin lightning network. I do think it will require a newer lightning network, perhaps even a second 'sequence numbers' field or something.

[zack]

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.

[psztorc]

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

Yes.

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.

Yes, the "new tx types" of Buying and Selling are very much unlike what Bitcoin usually does. But they are just one tx, one signature, per bet.

If you added the better lightening network to truthcoin, maybe they would eventually put it into bitcoin too.

The thing is, we already reused some stuff in Truthcoin that LN actually uses. Moreover, the bets need to accumulate trading fees (and have the new tx types, and their data fields). These are small changes, but they might warrant a completely different LN. That's all I mean.

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.

Me too, not completely sure why.