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.


Messages - HackFisher

Pages: 1 ... 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 ... 59
256
General Discussion / Re: Dry Run 12: Call Me Maybe
« on: August 09, 2014, 04:01:51 am »
I need 4 million.
XTS5TpccJBKr5qpebZWDMTiQzoTya9eDeR9TChYc6g2yGnxZTEQFB

257
DAC PLAY / Re: Vote for the name you want Bitshares Lotto rename to?
« on: August 09, 2014, 03:56:33 am »
Bitshares Chance

The DAC after rename will not limited to chance game, our target is integrate with game assets. If one day, games like Heartstone or Second Life can embed our asset in their game, that would be interesting.

258
按北美习惯叫casino是中文开始了的谐音。100多年前中国铁路工人晚上开赌前都是这样叫“开始囖,开始囖”,所以北美的赌场都叫casino

更名后的DAC不局限于机会类游戏

261
中文 (Chinese) / Re: 求助:注册子账户报错
« on: August 08, 2014, 10:49:12 pm »
错误提示: RPC server error  In method "wallet_account_register": account key already in use  (32008)

使用一个不同的public_key,而不是注册过的.

262
General Discussion / Re: BitShares X Market Rules - DRAFT
« on: August 08, 2014, 07:45:56 pm »
When someone shorts USD then a BitUSD is lent to them, right? But the idea is they do this to sell the USD for XTS and buy it back later, right? If so my only question is this: is the BitUSD paid to that person for them to sell on the market themselves or does the process involve it being automatically sold for them?

I think if that person need to hold the BitUSD for a while and sell on the market themselves. He can achieve this by placing short orders and ask orders the same time, you need to double collaterals to create BitUSD at current market price anyway.

263
Eureka!

Wow, what's that?
I think I've got it, but not sure what I want to do with it yet.

You can tell me secretly, I won't tell others.  :D
Maybe I have things to do with it.

265
where can i find something about RNG DPOS? would like to think about it.

would it not possible to let 101 delegate draw the numbers and everydelagte will produce a random number betwenn 1 and 101 the average number is the delegate which numbers are used?


Here is a draft white paper:
https://docs.google.com/document/d/1KkaAnuM0a_YU2yMaeDSDiyNUv96c9TrYrCjKadC01yA/edit

We need deterministic way to reach consensus, otherwise the consensus might be broken. With DPOS, I realized that there always will be one guy who can affect the random result before the last second.

The first time I was try to resolve this, I have a idea that one block is from two source delegate:

Quote
There are two independent queue of delegates, each have 101 delegates with the same 10s interval steps.
In every delegate slot, two delegates from two source list, need to produce and broadcast two blocks (one is normal  block data like now with secret and transactions, another one block data contains only secret ).

The other normal client will receive both of these two different block and merged them into one block before inserting to the final shared chain.

After I wrote the last sentence, I found that one of the two source delegate could be bad, and choose to receive  another source broadcast block to it first, which means, competing for the last position of random chain factors, and then attack intentionally by missing blocks, this is why I have to give up this approach, and call it ""Last Delegate being Evil Problem""

266
I prefer  change   evil to selfish
In fact, as a normal user of DAC, we believe that every delegate is selfish
we believe every delegate would choose to miss block if they can profit.
we need set rules to  punish  miss block if possible.

yes, not blaming the evil, so we need to resolve it mathematically within consensus.
The ultimate of this solution can effectively reduce minimum ticket draw time from 101 blocks to 3 blocks and no one will choose to be evil intentionally.

267
In some sense, this have something in common with shuffle.

If the delegate can not predict the draw block, his attack cost is always larger than attack return from the perspective of probability

268
DAC PLAY / The way to resolve "The Last Evil Delegate Problem" in DPOS
« on: August 08, 2014, 02:24:07 am »
In DPOS RNG algorithm, an evil delegate can only choose to throw away an unfavorable random result by intentionally missing block on his slot turn.

This could only be a problem, when the ticket draw interval is less than 101 blocks, because delegate can predict which block he will produce. Then he can choose to buy ticket which will draw in that block.

If the ticket draw interval is larger than 101 blocks, which means there will be at least one shuffle in that period, then the evil delegate can not predict which block he will produce. Then his only strategy is to guess or put tickets in each of the 101 blocks. If guess, his chance is 1/101, the *expect* return he can get back by attacking is the price of that ticket when he lose, because the delegate after him will continue to replace him and draw randomly. If he choose to put ticket in each blocks, his attack cost is (101 * block_ticket_sale), but what's the expected return, still the ticket sale he put in one block, he will lose.

Maybe for some games 101 blocks draw interval is too long for their requirement, and need shorter draw time, the solution is as following:

Ticket result will be drawn by 2 delegates:

The first delegate's random number is only in charge of producing a number X, which is between 1 to 3, and that X will determine the Xth block after him will draw the result random for the ticket. The 2th delegate could be the evil guy who is trying to attack, but he can not predict who will produce the right drawing block before 4 blocks, his attack cost is (3 * block_ticket_sale), but his expect return is still only 1 block_ticket_sale. The only thing game rule need is to set the draw interval 1 block before the first delegate.

Note: block_ticket_sale means all the ticket sale the evil delegate buy in one block.

 

269
Thanks everyone who provided and will give name suggestions, but name related to gaming will not be considered, part reason is due to regulation consideration.

Pages: 1 ... 11 12 13 14 15 16 17 [18] 19 20 21 22 23 24 25 ... 59