search

bisq-network / proposals

@bisq-network improvement proposals
https://bisq.wiki/Proposals
44 stars 16 forks source link

Implement Hashrate Derivatives #298

Closed huey735 closed 3 years ago

huey735 commented 3 years ago

This is a Bisq Network proposal. Please familiarize yourself with the submission and review process.

## 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
chimp1984 commented 3 years ago

What should be the use case for such a scheme? It might be useful for miners for some sort of hedge (have not thought about how it makes sense for them, but I can imagine there might be some use case) but the risks involved from the rules how time stamps are regulated in Bitcoin are way too high IMO that miners would consider it a fair contest. For abusing their power to set the timestamp in their favor the larger miners would gain benefit over smaller miners. Any other serious use case beside pure Casino gambling?

huey735 commented 3 years ago

Any other serious use case beside pure Casino gambling?

No.

For abusing their power to set the timestamp in their favor the larger miners would gain benefit over smaller miners.

I believe this can be protected against with enough time between the bet and the times the traders get to broadcast their payout. And it'd require most miners to actively attack the network in this manner for it be a serious threat. I haven't run the numbers for the above (not sure I am able to) so I may be greatly undermining the threats.

chimp1984 commented 3 years ago

I believe this can be protected against with enough time between the bet and the times the traders get to broadcast their payout. And it'd require most miners to actively attack the network in this manner for it be a serious threat. I haven't run the numbers for the above (not sure I am able to) so I may be greatly undermining the threats.

The winning chances are directly proportional to the mining hashrate power of a miner. So big miners have advantage over smaller ones. I doubt that would be a interesting use case/reason to engage for them anyway, but I don't see any serious hedge use case.

chimp1984 commented 3 years ago

Alternative idea: Hedge on miner fees. Make a bet that average miner fees of last 100 blocks at given block is bigger or smaller as a certain value. Again not safe once miners enters the game... but might have some use case for ppl who spend much money on miner fees and it depends on blockchain data only.

huey735 commented 3 years ago

I'm attracted to the idea of having the bitcoin network act as an oracle for the bet being made. That reduces greatly the responsibilities of the Bisq network and software. Any data other than blockheight and timestamp would require Bisq or other third party to arbitrate.

huey735 commented 3 years ago

There seems to be little interest in this proposal. The few comments that were made to me (outside this issue) were mostly negative:

i can't understand why we would confuse, obfuscate, intermingle, (some other adjective i can't think of) Bisq with betting. Bisq is a trading platform. Whyy are we talking about gambling?

I'm on the side that adding betting isn't a good idea. It wouldn't be a true betting thing anyway where you could bet on many events, sports etc., but only one pretty obscure thing, so wouldn't bring much to the table, however it could be detrimental, betting isn't seen in a positive way by many after all.

sqrrm commented 3 years ago

I think it's an interesting idea but I don't really feel it aligns with where bisq is right now. At some point it might be more reasonable to look at these kinds of contracts.

There is value in being able to hedge hash rate, and many other things, so I don't consider it to be gambling. This proposal is particularly nice in that the resolution is on chain so it's an atomic operation with no need for arbitration. I would let users handle the broadcast themselves, either through bisq or through some other means.

It's tricky to limit the handling of BTC by bisq since an offer needs to be available to be taken and automatically fund the 2of2 tx. If both sides have to take a manual funding step during the offer take process it's much less likely to succeed.

huey735 commented 3 years ago

@sqrrm I don't fully understand what you mean by:

It's tricky to limit the handling of BTC by bisq since an offer needs to be available to be taken and automatically fund the 2of2 tx. If both sides have to take a manual funding step during the offer take process it's much less likely to succeed.

So pardon if the following is misguided. At an ideal case I'm imagining something like JoinMarket's maker-taker model. The makers wallet remains online and will sign transactions if they fit a set of rules. As maker you don't have to pay fees to make your funds available. The taker comes and proposes a transaction and the makers sign it automatically as long as it fits the rules.

sqrrm commented 3 years ago

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.

So pardon if the following is misguided. At an ideal case I'm imagining something like JoinMarket's maker-taker model. The makers wallet remains online and will sign transactions if they fit a set of rules. As maker you don't have to pay fees to make your funds available. The taker comes and proposes a transaction and the makers sign it automatically as long as it fits the rules.

I was commenting on allowing funding of these transactions from an external wallet. It's not obvious to me how that could be done on the maker side avoiding having it handled by a hot wallet, in this case the bisq client. On the taker side it might be doable but even there the signing on the cold wallet side would have to follow the bisq protocol to setup the 2of2 tx, that is also tricky.

nyxnor commented 3 years ago

There is value in being able to hedge hash rate, and many other things, so I don't consider it to be gambling. This proposal is particularly nice in that the resolution is on chain so it's an atomic operation with no need for arbitration. I would let users handle the broadcast themselves, either through bisq or through some other means.

I was commenting on allowing funding of these transactions from an external wallet. It's not obvious to me how that could be done on the maker side avoiding having it handled by a hot wallet, in this case the bisq client. On the taker side it might be doable but even there the signing on the cold wallet side would have to follow the bisq protocol to setup the 2of2 tx, that is also tricky.

I´m not very familiarized with this topic, so this is gonna be a brief commentary. I think sqmrr better described here (quoted above), not different from the author's first post. Based on bisq telegram, they arent commenting here, but they think its not very detailed the benefits or it is just gambling. But back to the referenced above, the contracts can be done by who wants, I one doesnt want, there is no need to discorauge. Yes, the risks of assembling the contract by both parties following the protocol to the transaction be signed.

Conza88 commented 3 years ago

Great work on the ideas. However, a "no" for me, for now.

Reason: other priorities should take precedence = Bisq focusing on improving general trading/exchanges.

What's involved in that?

huey735 commented 3 years ago

@MwithM I'm closing this issue given that lack of interest.

Summary

Overall negative sentiment