huey
January 25, 2021, 11:59pm
1
Alice and Bob want to bet on how many blocks the bitcoin network will produce in a certain period.
On 2021/01/21 12:00:00 (1579608000) at block 667016
Alice: I bet there will be 2016 blocks produced in the next 2 weeks. In other words the chaintip will be equal or higher than 669032 by 2021/02/04 (1580817600).
Bob: I believe that it will produce more than that.
Both of them agree on an amount and send funds to a 2-of-2 multisig controlled by both of them.
If Bob is right, the block height (669032) will happen before the date Alice mentioned (1580817600) so Bob gets a payout transaction sending funds from the multisig to him with a block-height-locktime of 669032 .
And Alice gets a transaction sending funds from the multisig to her with a timestamp-locktime of 1580817600.
(…)
Read more
opened 12:44PM - 21 Jan 21 UTC
closed 04:29PM - 06 Feb 21 UTC
was:rejected
a:proposal
re:features
> _This is a Bisq Network proposal. Please familiarize yourself with the [submis… sion and review process](https://docs.bisq.network/proposals.html)._
## Description
[This protocol is inspired by Jeremy Rubin's POWSWAP](https://twitter.com/JeremyRubin/status/1192958303464067072) @jeremyrubin
Alice and Bob want to bet on how many blocks the bitcoin network will produce in a certain period.
On 2021/01/21 12:00:00 (1579608000) at block 667016
Alice: I bet there will be 2016 blocks produced in the next 2 weeks. In other words the chaintip will be equal or higher than 669032 by 2021/02/04 (1580817600).
Bob: I believe that it will produce more than that.
Both of them agree on an amount and send funds to a 2-of-2 multisig controlled by both of them.
If Bob is right, the block height (669032) will happen before the date Alice mentioned (1580817600) so Bob gets a payout transaction sending funds from the multisig to him with a block-height-locktime of 669032 .
And Alice gets a transaction sending funds from the multisig to her with a timestamp-locktime of 1580817600.
It's important to note that Bob could also have taken Alice's bet on the opposite side. That there would be less blocks produced in that time. In this case Alice would get the payout transaction with the block-height-locktime and Bob the one with the timestamp-locktime. The one who believes more blocks will be produced in a given period gets the payout with block-height-locktime.
## Risks
### Bitcoin miners
The timestamp, unlike the block height, [is relatively malleable (required reading)](https://blog.bitmex.com/bitcoins-block-timestamp-protection-rules/). Which means that there should be a lower-bound time safety measure.
More on the topic:
- [Twitter thread by Rene Pickhardt](https://twitter.com/renepickhardt/status/1266478238047617038)
### Blockspace market
Given a volatile blockspace market it's important that we be careful that the [transaction depositing funds into the multisig be confirmed in a timely manner](https://github.com/bisq-network/proposals/issues/287).
## To consider
### Start simple
There are many ways to tinker with this derivative: odds, possibility to renegotiate the derivatives, time-frames for the bet, etc. We should focus on implementing the simplest version first and later consider changing it to add more aspects it.
### Broadcasting the Payout transaction
By the end of the exchange between Alice and Bob, each will have a bitcoin transaction that becomes valid after a certain point in time. We can:
- leave the responsibility of the broadcasting to them - this is simpler to implement and leaves all the responsibility to the individuals
- have Bisq provide the service for them - this require more work and puts more responsibility on the Bisq Network
### Reduce interactivity with the Bisq wallet
It'd be great to somehow reduce the time the funds would need to be controlled by Bisq's hot wallet keys. We should aim for the users to be able to fund the bet from an external wallet and get the payout in an external wallet. This would possibly increase the amounts being bet on.
### Fees
For trading Bisq, currently has a fee model with a lower bound of 5k sats per trader or a set percentage. X for offer makers and Y for offer takers where the X and Y don't change despite the trade amounts.
This may not be ideal for bets with ranging hypothetically from 0.1 btc to 100 btc.
### Reduce trade protocol to 1 single transaction
The current trade protocol involves 4 transaction:
- maker trading fee
- taker trading fee
- deposit into mulsitig
- payout
[**This may be reduced to a single transaction**](https://github.com/bisq-network/proposals/issues/279).
### How to present this
It's important that we decide on a visual language that can minimize interpretation errors. @pedromvpg