Author Topic: BitShares Vegas  (Read 4195 times)

0 Members and 1 Guest are viewing this topic.

Offline Gentso1

  • Hero Member
  • *****
  • Posts: 931
    • View Profile
  • BitShares: gentso
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/ 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).   

Offline fuzzy

Could there be "delegate betting" for various DACs so they can see how they size up compared to one another? 
WhaleShares==DKP; BitShares is our Community! 
ShareBits and WhaleShares = Love :D

Offline luckybit

  • Hero Member
  • *****
  • Posts: 2921
    • View Profile
  • BitShares: Luckybit
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.
« Last Edit: July 20, 2014, 08:31:05 pm by luckybit »
https://metaexchange.info | Bitcoin<->Altcoin exchange | Instant | Safe | Low spreads

Offline bytemaster

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.

For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

bitbro

  • Guest
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

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
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.
Weibo:http://weibo.com/zhangweis

bitbro

  • Guest
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? 

Offline bytemaster

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.
For the latest updates checkout my blog: http://bytemaster.bitshares.org
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

bitbro

  • Guest
Maybe this helps explain some part of the concept:



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

Thanks.

bitbro

  • Guest
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?

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
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.
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

bitbro

  • Guest
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?

 
« Last Edit: April 14, 2014, 04:25:52 pm by bitbro »

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Could you explain more about Delegated Proof of Event?
Anything said on these forums does not constitute an intent to create a legal obligation or contract between myself and anyone else.   These are merely my opinions and I reserve the right to change them at any time.

Offline xeroc

  • Board Moderator
  • Hero Member
  • *****
  • Posts: 12922
  • ChainSquad GmbH
    • View Profile
    • ChainSquad GmbH
  • BitShares: xeroc
  • GitHub: xeroc
Sounds profitable!!

bitbro

  • Guest
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?