BitShares Forum

Other => Graveyard => DAC PLAY => Topic started by: bitbro on April 14, 2014, 02:45:16 pm

Title: BitShares Vegas
Post by: bitbro on April 14, 2014, 02:45:16 pm
As I was reading the DPOS white paper I also began to think this could be an excellent segway into data feeds or Delegated Data Feeds, or Delegated Proof of Event.

Once Delegated Proof of Event exists, a DAC like BitShares Vegas could be designed, and it would function similarly to bitbet.us

Thoughts?
Title: Re: BitShares Vegas
Post by: xeroc on April 14, 2014, 03:04:16 pm
Sounds profitable!!
Title: Re: BitShares Vegas
Post by: HackFisher on April 14, 2014, 04:00:41 pm
Could you explain more about Delegated Proof of Event?
Title: Re: BitShares Vegas
Post by: bitbro on April 14, 2014, 04:19:37 pm
Could you explain more about Delegated Proof of Event?

Hmmm .. maybe that's an innacurate term ... I was only brainstorming.

In BitShares Vegas it would make sense to use DPOS, but add in an extra voting feature and maybe call it Delegated proof of Event (DPOE). 

The alteration: in the blockchain insert an additonal voting mechanism so that DPOE would run paralell to DPOS and support votes for upcoming events.  On top of voting for block transactions, delegates will vote one of three possible votes:  "Event has not yet occured" "Outcome A has occured"  "Outcome B has occured".  When consensus on Outcome A or B occurs, payouts are initiated.


What do you think?

 
Title: Re: BitShares Vegas
Post by: HackFisher on April 14, 2014, 04:29:27 pm
Could you explain more about Delegated Proof of Event?

Hmmm .. maybe that's an innacurate term ... I was only brainstorming.

In BitShares Vegas it would make sense to use DPOS, but add in an extra voting feature and maybe call it Delegated proof of Event (DPOE). 

The alteration: in the blockchain insert an additonal voting mechanism so that DPOE would run paralell to DPOS and support votes for upcoming events.  On top of voting for block transactions, delegates will vote one of three possible votes:  "Event has not yet occured" "Outcome A has occured"  "Outcome B has occured".  When Outcome A or B occurs, payouts are initiated.


What do you think?

Interesting point of view, I think it is a good idea. With DPOS 100 delegates, we can use analogy of "votes" to resolve problems....

What if "votes" are failed, that is, the votes results are to close to each other, e.g. 34:33:33?
...though that should not happen if the 100 delegate are with high quality.
Title: Re: BitShares Vegas
Post by: bitbro on April 14, 2014, 08:14:40 pm
Could you explain more about Delegated Proof of Event?

Hmmm .. maybe that's an innacurate term ... I was only brainstorming.

In BitShares Vegas it would make sense to use DPOS, but add in an extra voting feature and maybe call it Delegated proof of Event (DPOE). 

The alteration: in the blockchain insert an additonal voting mechanism so that DPOE would run paralell to DPOS and support votes for upcoming events.  On top of voting for block transactions, delegates will vote one of three possible votes:  "Event has not yet occured" "Outcome A has occured"  "Outcome B has occured".  When Outcome A or B occurs, payouts are initiated.


What do you think?

Interesting point of view, I think it is a good idea. With DPOS 100 delegates, we can use analogy of "votes" to resolve problems....

What if "votes" are failed, that is, the votes results are to close to each other, e.g. 34:33:33?
...though that should not happen if the 100 delegate are with high quality.

Yes, there needs to be consensus for outcomes to be "proven".  We will need to work through this issue.

Also, to amend an earlier post, I think there will need to be four voting options: In addition to "Event has not yet started" "Outcome A has occured" and "Outcome B has occured" , there may also need to be "Event is in progress" .   If 5 % or so agree that "event is in progress", then bidding must stop.  This will allow odds to remain fair, rather than letting people bet mid-game or mid-election day with better odds.

Any ideas on how to guarantee consensus on the outcome of an event?
Title: Re: BitShares Vegas
Post by: bitbro on April 14, 2014, 11:20:33 pm
Maybe this helps explain some part of the concept:

(http://s1.postimg.org/6rkyy60un/Untitled.jpg)

mhmm... where it says BTC it should say BTS.

Thanks.
Title: Re: BitShares Vegas
Post by: bytemaster on April 15, 2014, 02:34:02 am
The challenge is efficiently collecting the votes... far better to have a trusted feed with profit motive for providing accurate data... then have all bets reference the feed.  Risk of cheating would be priced in and bets could reference 3 feeds if they do not trust one feed... at 3x the cost.

Voting is inefficient and slow.  Avoid as much as possible.
Title: Re: BitShares Vegas
Post by: bitbro on April 15, 2014, 02:43:55 am
The challenge is efficiently collecting the votes... far better to have a trusted feed with profit motive for providing accurate data... then have all bets reference the feed.  Risk of cheating would be priced in and bets could reference 3 feeds if they do not trust one feed... at 3x the cost.

Voting is inefficient and slow.  Avoid as much as possible.

How do you think a feed would operate?  Would it be based on reputation of one person? 
Title: Re: BitShares Vegas
Post by: zhangweis on April 15, 2014, 08:27:38 am
The challenge is efficiently collecting the votes... far better to have a trusted feed with profit motive for providing accurate data... then have all bets reference the feed.  Risk of cheating would be priced in and bets could reference 3 feeds if they do not trust one feed... at 3x the cost.

Voting is inefficient and slow.  Avoid as much as possible.

The votes come only from board of directors and they're motivated to vote. You can refer to https://bitsharestalk.org/index.php?topic=4176.0 for my idea. Basically the DAC can run just like http://bitbet.us/. It runs like below:
1. Any shareholder (maybe with at least 0.01% of share) can start a bet with some description.
2. Delegates vote whether the bet is clearly stated and can be judged when the event happens.
3. Delegates vote on the result when the vent happens. Multiple delegates can vote on the same bet and will split some portion of the bet's payout.
4. Shareholders can view their delegates' vote from wallet and can vote against them if they cheat.
Title: BitShares Vegas
Post by: bitbro on April 15, 2014, 01:54:43 pm
The challenge is efficiently collecting the votes... far better to have a trusted feed with profit motive for providing accurate data... then have all bets reference the feed.  Risk of cheating would be priced in and bets could reference 3 feeds if they do not trust one feed... at 3x the cost.

Voting is inefficient and slow.  Avoid as much as possible.

The votes come only from board of directors and they're motivated to vote. You can refer to https://bitsharestalk.org/index.php?topic=4176.0 for my idea. Basically the DAC can run just like http://bitbet.us/. It runs like below:
1. Any shareholder (maybe with at least 0.01% of share) can start a bet with some description.
2. Delegates vote whether the bet is clearly stated and can be judged when the event happens.
3. Delegates vote on the result when the vent happens. Multiple delegates can vote on the same bet and will split some portion of the bet's payout.
4. Shareholders can view their delegates' vote from wallet and can vote against them if they cheat.

How many delegates would you want on the BOD? If 100, the process may be slow, to BM's point.  If 10, voting my be faster, but incentive to cheat would be greater.

I do see the value in using delegates and DPOE in combination with DPOS, however if speed and consensus (there are at least 4 voting options) are an issue, they will hinder the system; DPOE may be overly complex and cumbersome for BTS Vegas.

However, The trusted data feeds would speed up the process, but they would also be responsible for accepting or denying proposed bets based on their clarity, so they would essentially be bookies, which might be illegal.  This is why, like you, I like DPOE.


Sent from my iPhone using Tapatalk
Title: Re: BitShares Vegas
Post by: bytemaster on April 15, 2014, 09:24:30 pm
The challenge is efficiently collecting the votes... far better to have a trusted feed with profit motive for providing accurate data... then have all bets reference the feed.  Risk of cheating would be priced in and bets could reference 3 feeds if they do not trust one feed... at 3x the cost.

Voting is inefficient and slow.  Avoid as much as possible.

The votes come only from board of directors and they're motivated to vote. You can refer to https://bitsharestalk.org/index.php?topic=4176.0 for my idea. Basically the DAC can run just like http://bitbet.us/. It runs like below:
1. Any shareholder (maybe with at least 0.01% of share) can start a bet with some description.
2. Delegates vote whether the bet is clearly stated and can be judged when the event happens.
3. Delegates vote on the result when the vent happens. Multiple delegates can vote on the same bet and will split some portion of the bet's payout.
4. Shareholders can view their delegates' vote from wallet and can vote against them if they cheat.

How many delegates would you want on the BOD? If 100, the process may be slow, to BM's point.  If 10, voting my be faster, but incentive to cheat would be greater.

I do see the value in using delegates and DPOE in combination with DPOS, however if speed and consensus (there are at least 4 voting options) are an issue, they will hinder the system; DPOE may be overly complex and cumbersome for BTS Vegas.

However, The trusted data feeds would speed up the process, but they would also be responsible for accepting or denying proposed bets based on their clarity, so they would essentially be bookies, which might be illegal.  This is why, like you, I like DPOE.


Sent from my iPhone using Tapatalk

Actually, there is nothing illegal with producing a signed statement of fact.  Placing bets on that may be illegal, but simply producing the statement should be perfectly safe.

Title: Re: BitShares Vegas
Post by: luckybit on July 20, 2014, 08:21:50 pm
The challenge is efficiently collecting the votes... far better to have a trusted feed with profit motive for providing accurate data... then have all bets reference the feed.  Risk of cheating would be priced in and bets could reference 3 feeds if they do not trust one feed... at 3x the cost.

Voting is inefficient and slow.  Avoid as much as possible.

Could a distributed oracle work for this? I've been reading up on zk-SNARK and distributed oracles. It might be able to be much more automated than voting.

A sporting event for example if it's on television will produce different signals depending on which team wins for example. Again maybe it's too soon to discuss zk-SNARK in conjunction with distributed oracles but that could be a way to go.

Imagine an app could be run on the machine which sees the sporting event from the perspective of the user. Suppose the sporting event were on Youtube and you run the app in the background and when it hears voices in the video reflecting the score it snapshots the event and sends up to a blockchain.

Scale up and the more people who do this the more accuracy it will have. The app would simply look for a signal within the video stream itself which indicates team a or team b as the winner. Visual or pattern recognition, voice recognition, any of these would work just fine. A human being wouldn't even be necessary if a sensor were smart enough to see an event and send the result to the blockchain.

The AI would hear the scores, voice recognition would detect the signals, it would be sent to the blockchain. No humans involved and completely automated. The AI would see the result along with the text on the screen, it would take a snapshot, and send it to the blockchain. Could even work as an app for Google Glass.

If necessary to make sure we have redundancy the app could capture and store an image or audio clip, encrypt it, and if there is any dispute over the result (if people don't trust the accuracy of the AI) then the audio and video clip can be reviewed by humans with voting.
Title: Re: BitShares Vegas
Post by: fuzzy on August 13, 2014, 05:53:27 am
Could there be "delegate betting" for various DACs so they can see how they size up compared to one another? 
Title: Re: BitShares Vegas
Post by: Gentso1 on August 13, 2014, 02:07:02 pm
The challenge is efficiently collecting the votes... far better to have a trusted feed with profit motive for providing accurate data... then have all bets reference the feed.  Risk of cheating would be priced in and bets could reference 3 feeds if they do not trust one feed... at 3x the cost.

Voting is inefficient and slow.  Avoid as much as possible.

How do you think a feed would operate?  Would it be based on reputation of one person?
Why not use a site like the following that http://www.bovada.lv/ (http://www.bovada.lv/) or even better perhaps a group of sites and then take a average of the odds placed on each site. This would give you multiple feeds from places that also have a stake in producing accurate odds(because they are producing bets themselves).