Topic: fair coin toss with no extortion and no need to trust a third party - page 5. (Read 15664 times)

The loser could do this if they're not using iddo's protocol.

The point is that if they use iddo's protocol, the loser can't hold up because he has more tied up (which he'll lose if communications stop) than he has riding on the bet.

If you've found a flaw in the protocol, please share.

As you note, the later to release could hold up if they see that they would lose.

I can see ways of compensating for this where disclosures happen one bit at a time so that one party never has more than 1 bit of knoweldge advantage, but those don't result in compact release scripts due to the need to structure the proof as a bit commitment list to prevent unfaithful execution during the reveal.

e.g. your commitment would need to be  H(...H(bit||H(bit||H(bit||nonce)))...)

Though even then it means that a party with a substantial computational advantage could still bias the outcome.


One possibility would be to bond the bet thusly (warning: this protocol is a freeking mess)

Alice and bob one to do a no-renig coinflip.

First alice and bob commit to secrets by sharing hashes of their secrets.

Alice writes a transaction which pays to multisig alice and bob
.. but before announcing, writes two refund transactions:
  One is lock-timed 100 blocks from now, and pays alice's coin to bob.
  The other is not lock-timed, but requires both alice's signature and the preimage to redeem.
After bob signs both of these alice announces the payment into the escrow.

Likewise, bob does the same with the roles reversed.

Now alice and bob do your coinflip transaction, with it's own refund, but the refund is locktimed 300 blocks from now.

If they do not release their secret in time to beat the refund they lose their starting bond.

bump

I tried to convince Meni that it cannot easily be done if the party that learns the outcome first can abort and hence bias the result, though it can still be done via gradual release techniques.

So, any comments on this Bitcoin-based coin toss scheme? Anyone?

I think that "fair coin toss" undersells what this is. You can easily do a fair coin toss, the problem this solves is having the loser pay a predetermined amount to the winner without possibility of reneging.

bump

Similarly to atomic cross-chain trading (link), I think that a fair coin toss (without the possibility of extortion) can be implemented by selecting the winner via the least significant bit of two committed secrets, as follows:

Edit: Adam Back's protocol in post #37 supersedes this protocol (see also post #49).

1. Alice and Bob wish to do a fair coin toss where each of them inputs X coins and the winner gets the 2X coins.

2. Alice picks some secret A1 and reveals to Bob the value A2=SHA256(A1), and Bob picks some secret B1 and reveals to Alice the value B2=SHA256(B1)

3. Alice creates a "bet" transaction that takes Alice's input of X coins and Bob's input of X coins, and can be spent by ((Alice's signature + Bob's signature) OR (LSB of (A1 xor B1) is 0, and Alice's signature) OR (LSB of (A1 xor B1) is 1, and Bob's signature)), I mean here that this "bet" transaction has A2 and B2 hardcoded in it, and (A1 xor B1) is computed using OP_SHA256 when the script is executed with the needed preimages.

4. Alice signs the refund transaction that spends those 2X coins back to addresses of Alice and Bob (so each gets X coins back), and has locktime of (say) 300 blocks into the future, and asks Bob to sign this refund transaction.

5. After Bob signs the refund transaction, Alice asks Bob to sign the "bet" transaction and broadcast the "bet" transaction to the Bitcoin network.

6. Alice creates a "Reveal1" transaction that takes as input (say) 3X of her own coins, and can be spent by ((Alice's signature + Bob's signature) OR (revealing some B that satisfies OP_SHA256(B)==B2, and Bob's signature))

7. Alice asks Bob to sign a refund transaction for "Reveal1" with locktime of (say) 100 blocks into the future.

8. Bob creates a "Reveal2" transaction that takes as input (say) 3X of his own coins, and can be spent by ((Alice's signature + Bob's signature) OR (revealing some A that satisfies OP_SHA256(A)==A2 and revealing some B that satisfies OP_SHA256(B)==B2, and Alice's signature))

9. Bob asks Alice to sign a refund transaction for "Reveal2" with locktime of (say) 200 blocks into the future.

10. Bob broadcasts his "Reveal2" transaction, and when Alice is confident enough that "Reveal2" will be mined into the blockchain she broadcasts her "Reveal1" transaction. Depending on the amount X of the bet, Alice can choose the appropriate confidence threshold. For example. if Alice doesn't wait for at least 1-confirmation then it might be risky because Bob could try to broadcast a conflicting transaction (after Alice broadcasts "Reveal1") with a higher fee that spends the 3X coins input of "Reveal2" to an address that he controls.

11. If Bob spends Alices's 3X coins via the transaction "Reveal1" in the next 100 blocks then he reveals his preimage B1

12. Now Alice can spend the transaction "Reveal2" in the next (at least) 100 blocks and thereby reveal her preimage A1, to get back the 3X coins that she lost.

13. Now the winner of the bet can spend the 2X coins to an address of his choice, in the next (at least) 100 blocks.


We can of course replace this 300 locktime number with a smaller number like 6 or whatever. If the client implements this protocol without a need for human intervention then short locktime numbers should be fine. Alice and Bob can broadcast all those transactions before any new blocks are mined, therefore if neither of them is malicious then the winner of the bet will be revealed instantly.

So, is it true that this protocol gives a fair coin toss with no possibilities for extortion and no need to trust a third party, or could someone spot any defects in it?
Maybe someone could come up with a more simple protocol that accomplishes the same goal?