Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Topics - gamey

Pages: 1 2 3 4 5 6 [7]
91
Random Discussion / Youtube going to integrate a donation system ?
« on: May 24, 2014, 07:38:08 pm »
http://www.pcmag.com/article2/0,2817,2458540,00.asp

So Youtube is going in the direction of hooking up donation payments to their system.  Perhaps not that relevant, but it definitely makes the youtube world more DAC like.  Perhaps they were seeing too many btc addresses posted in descriptions.

92
EDIT -  I misunderstood the attack.  While a person can punish a pool by withholding a block, they can not then submit that hash elsehwere for the block.  Toast was right.  Good to know you Bitshares guys are on top of things.  I should have reread a relevant thread again. I just got all excited. ;)  If any mod wants to delete this, feel free as it serves no purpose but clutter IMO.  My apologies.












Let me explain the exploit.  I wish I had the original thread from bitcointalk, but it was a conversation I just had that led me to these conclusions. 

Basically any miner of a pool can withhold blocks from the pool and submit them via a regular solomining setup.  This doubles your expectation if no one else is doing it with no real downside except it is basic thievery.

BTCGuild is supposedly running quite under expectation.  Hmmm..

This exploit will introduce some form of private pools that rely on a reputation system.  Even that would be a hard sell.  So outside of private pools, it forces people to go back to solo mining or to lose a lot of expectation due to being cheated. 

Solo mining doesn't work so well and will discourage a LOT of small time miners when they run bad for months or longer. 

The end result is the guys who don't have enough hashing power to solo mine without really high variance will be forced to use pools which are likely exploited or they give up in frustration.

So will this lead to centralization or decentralization?  After playing out the scenarios to me, I think it will lead to decentralization as pools just simply can not be as large as they once were.  They'll fragment as people form pools around some form of trust systems.  By necessity the pools will be smaller.  So we will have smaller pools and less people mining.  These trust systems could utilize historic data from a pool's accounts and their blocking vs hashing rates.  (You still would not have enough data IMO for most users with BTC)

Whether this is more or less decentralized is not 100% clear, but I tend to go with being more decentralized as pools themselves really are a security issue.

I suspect whatever the outcome is, POW is going to come out not looking so great.  :)

Thoughts ?  Is gamey confused again ?  If someone knows some threads with better explanations please post them. 

I did not read a reasonable way to work around this either. Multipools around scrypt/gpus are a different thing and not near as exploitable. However I really think BTC is stuck with this exploit and all the repercussions. 

Frankly I fear I am confused or I simply don't understand why this hasn't already become a huge problem.  Nice guy miners?

93
General Discussion / Dac proposal - collaborative documentation.
« on: May 05, 2014, 10:34:23 pm »
Basic idea here is that someone or a group puts up a certain amount of capital and request or specs out documentation.  The original spec could be broken down by chapters. Each person who contributes to it would be paid a portion of the funds put up for the project.

The dac would also pay for smaller edits to incentivize further edits.

This would all be taken care of by the dacs funders voting on each contribution.

2 issues I see.  A person could start the dac and fund it for a large amount. After someone puts labor into the documentation, the person who started the DAC could put all their votes into their own irrelavent contributions.  Thus robbing the true contributors.  I just realized this issue as I was composing this and do not have a solution to guarantee fairness

The other issue is the voting system would need to allow proportional votes.  There is a need to allocate funds proportional to effort.  This means the voting system needs to allow proportional votes.  Otherwise it would be real hard to insure that small contribution get paid fairly.

The dac would also need to timeout after a certain period and payout whatever work has been done.  That way the payment would not just be openended to the person who contributed and could expect to be paid by a certain date.

Bitshares could use this dac to generate all of their documentation.  This could have a synergistic effect in multiple ways.  It would be a simple demonstration of the power of dacs.

Thoughts ?

Btw this is basically the same idea presented elsewhere here but aimed at a different content producing market.  I did not mean to take credit for the other ideas.  I just see that there is a actual need for documentation often with these open source projects.

94
General Discussion / Email service DAC for the use by other DACs ?
« on: April 29, 2014, 02:18:28 pm »
 Are there any plans for an email DAC?  Basically a DAC that sells email service to other DACs.  From what little experience I've had dealing with email gateways it is a huge hassle and prone to breaking.


The problem with DAC is that they have to have an interface that relies on one of 3 things currently.

1) Web-site frontend - Extremely centralized.
2) Client app - Requires trust in app.  Somewhat centralized due to distribution channels, yet this will be defacto interface.
3) Blockchain transactions - This is the best since any wallet should allow interaction with the service.  Quite a few services can get by with this level of functionality, but it is still limited.

However there is a possible 4th which is email.  Everyone uses email.  EVERYONE.  Instructions can be sent in email.

If there is an active developer behind it, then I would say it is not that centralized.  The problem is it would need to be agile in changing the email gateways.  This requires an active dev for the life of the DAC.

Lets face it, when you use a website you rely on email for most websites of importance, or at least those that involve any form of equity.  The only other way for a DAC to give a user feedback is one of the above 3, of which only #2 is decentralized and more functional than email.

So why not just rely on the decentralized downloaded client ?  The problem is there are a lot of situations where you do not want to rely on the user to load the executable and view results.  You need a technology that pushes results TO the user.  Thats one reason why email is important.  Everyone from individuals to corporations to all manner of websites rely on email. 

Another reason is it allows you to tie things into email addresses etc.  You can promote to email addresses.  Yes, that is somewhat centralized but end users do not want to be backing up private keys and dealing with all the headaches involved.  Email is a bridge to people who might otherwise be scared (and rightfully so) of downloading a client.  You can make a website be the portal to a DAC if the DAC has email access.  Create the account with email authentication in the DAC, so if website goes away they're still inside the DAC.

This DAC simply allows other DACs to utilize this other channel of communication which is the most basic functionality of the internet.

I am not sure how to structure the functionality so it is actually "decentralized".  Dealing with possibly spammers, etc.  It is a serious job in itself to keep the DAC up and running.

This could also be done with twitter etc.

The idea here is to enable other innovative DACs.

I suppose you could have like an API based DAC.  Then individual operators could provide the email service through this API and the decentralized aspect would be the routing of the email.  With each operator charging whatever the market will bear.

Has this been hashed over yet ?


Thoughts ?

95
General Discussion / Discussion on Treechains .
« on: April 27, 2014, 08:11:40 pm »

I don't really get this.  I see Peter Todd talking about it on twitter pointing to this posting.

https://bitcointalk.org/index.php?topic=586832.0

If anyone else has other links on the discussion of this approach, please post them here.  Thoughts ?

96
General Discussion / Multipool for AGS ?
« on: April 19, 2014, 07:39:00 pm »
We have talked about the multipool for bitshares and I don't think anyone thinks it is a bad idea.

Unfortunately I'm not sure when BTS will be tradeable.

PTS is tradeable however, but what is special about PTS currently ? 

The ability to buy AGS for 90 days.

Unfortunately to acquire AGS you have to buy them from your wallet, so there is no way to "mine AGS" shares directly.

Can anyone see a solution to this ?

They could give the mining pool their private keys, but thats a horrible idea.  Outside of that, it would require manual donation to AGS and that would really hurt with the marketing angle of this.

PS - I removed and recreated this thread because I thought there was a better forum then changed my mind. sorry

97
DAC PLAY / Need for a responsive RNG server
« on: April 13, 2014, 01:15:24 am »
All gaming requires RNGs if there is any form of incomplete information.   All wagering games require incomplete information.  (Otherwise there is nothing to wager on).  If anyone is curious why you can't just use a block hash as RNG the problem is timing.  While the first random # can be used off the hash, you can't get a 2nd unknown RNG until a new hash is found.  Furthermore all player decisions must be finalized before the random number is selected.  These constraints really screw with the experience.   

So what we need is a RNG generator that can give us actionable random numbers at the requested rate. 

This can be done, but has to be done in a centralized controlled manner.

The reason is that in gaming, you simply can not let a player have any way of knowing the future random #s.  If the RNG generator is distributed, then all bets are off.   So it has to be generated in a centralized service.  The other option is to create random numbers in a distributed manner, but that requires some sort of complicated consensus protocol.  Consensus and responsive are 2 things that go against each other.  So I decided that you need a centralized RNG generator in order to move things along.

This RNG DAC does a few things.

1) Creates an auditable log of the stream of random numbers and can prove that they are indeed random.
2) Allows the request of random numbers at various intervals.
3) Is not distributed, so that players can not peak under the hood.

#2 is critical.  A lotto game that does not have as much of a timing requirement can grab a random number from the next block.  This won't work with interactive games.  And you can't send a seed # and read from it sequentially as the player would be able to then predict future numbers.  Each random number has to come from a host in an atomic manner.

I would prefer some sort of distributed RNG generator that is auditable, demonstrably random, and can service number requests with little latency.  I suspect that is a very hard problem to solve and needs some serious thought.

So until we have this cloud based RNG, this is what I am proposing and wish someone would implement. 

So here are the actors in this.
RNGHost
Gaming block chain
Client

RNGHost publishes a hash of a random number (secret key) and which block it goes with.  This has to be a valid transaction recorded on the blockchain.  When this block occurs, we use the blockhash + secret key for the seed value of the RNG.  After this every gaming random number will be requested from this server. These will be placed in a blockchain transaction for auditing/confirmation.  After a new block is chosen, the secret key is then published and a different previous secret key is chosen.

There is one attack that I am aware of and that is that the person hosting the the random number service could use it to rob the gaming services.  In that regard centralization is better because it lowers the number of actors who can steal.  In addition with 1 RNG host, it can be easily DOS'd.  Forks are also a big issue.  Even by confirming the random number genesis, it still leaves the RNG creations to be lost in a fork.  I am not sure how that is handled.  I guess the player just deals with the timewarp of their fortunes. ;)

Thoughts?  Are there plans for anything like this ?  Is my idea not going to fit into the bitshares world ?  It isn't anything brilliant, but it addresses an issue that is sorely lacking if Bitshares wants to attract a gaming market.

I'd like to see gaming blossom under Bitshares.  Due to the RNG problem I just don't see it happening.  I am not that familiar with the architecture behind Bitshares so maybe this whole idea is unworkable.

Regardless, please comment on this.

98
General Discussion / Relying on prediction markets ?
« on: April 11, 2014, 11:58:47 pm »
I watched the video on insurance bitshares.  There was talk of a prediction market (although Dan referred to is as "the market" in the video, so I am not sure) deciding the trust and legitimacy of individual actors.

That made me question if a prediction market could work in such a case?  What information do the market participants act off ?  How could they receive any sort of perceived edge to even try ?  Would the markets be large enough to actually approach accuracy ?

I then realized you could actually have prediction markets where the participants are paid by those they protect.  So in the insurance situation, the prediction market could be paid by the insurance's fund pool to keep the adjusters honest.  So instead of vig working against the market participants, it would work for them and be paid by the pool of money the prediction market participants indirectly protect.  The market participants would have to back their positions with their own money, but they would get an additional %.  This could make a healthier and more robust prediction market which would have a significantly higher chance of working.

Thoughts ? 

Has anyone talked about such a model to help protect the interests of DACs ?  I know it isn't like rocket science and I would be surprised if not brought up elsewhere..  It just seems like a significant improvement over relying on prediction market to exist with no extra incentives.  I'm sure there are other places it could be applied.

Pages: 1 2 3 4 5 6 [7]