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 - zhangweis

Pages: 1 ... 12 13 14 15 16 17 18 [19] 20 21
271
DAC PLAY / Re: Bitshares Lotto FAQ
« on: April 03, 2014, 02:25:10 am »
I mean prepare multiple S values for the same hash(S). But as I mentioned later, if it maybe same difficult as collide a private key for a bitcoin address. So just ignore the previous reply if it's same difficult as bitcoin address hashing.

272
DAC PLAY / Re: Bitshares Lotto FAQ
« on: April 03, 2014, 02:08:27 am »
Maybe I was wrong if the hash collision is as difficult as bitcoin address hashing. In that case it's easier just to collide for an address with large amount bitcoin. :) If that's true, I think the way you describe will work perfectly.

273
DAC PLAY / Re: Bitshares Lotto FAQ
« on: April 03, 2014, 01:41:56 am »
Quote from: bytemaster on April 03, 2014, 01:08:13 am
Now we just have the problem of the last trustee having 64 entries into the RNG and thus selectively publishing his secret.   It seems the only way to prevent cheating is for all participants that participate in step 1 must also participate in step 2 or else lose a surety bond.   If not every participates in phase 2 then the process must restart.   

This means that an attacker could delay the selection of the Random Number so long as they were willing to give up their bond.   

Yes, I meant collision in step 2. As the number to be generated is in a limited range, I think it'll be achieved for an ASIC. To make things worse, the cheater can collide before hand preparing several S1,S2,S3 for the same hash. To prevent this, we may need to use current block's hash in step 3 to avoid prepared collision. Also I doubt surety bond would work. On the one hand, it's too little compared with what the cheater can get. It can avoid loosing anything by publishing the original S in the last second if collision failed. On the other hand, for an honest node, it's too much if any delay happens like network issue or computer issue.

274
DAC PLAY / Re: Bitshares Lotto FAQ
« on: April 03, 2014, 12:18:09 am »
Quote from: bytemaster on April 03, 2014, 12:01:59 am
I think the entire process can be boiled down to the following process without a BOD.

1) Anyone who wishes to contribute to the Random Number Generation process publishes the hash of their secret  HASH(S).
2) After all HASH(S) has been published all participants have an opportunity to publish S
3) After all participants are given an opportunity to publish their S,   HASH( S[0...N] ) is calculated as the chosen random number.

Anyone concerned about the randomness of the result can participate in the process by publishing two transactions.  Everyone else can simply choose to trust that the others are not colluding.   If there is even one honest individual in the batch then it is secure.   If all of the BOD contribute to the process then it can be assumed that there is a high probability that at least one of them is honest. 

In this way everyone who wants it to be provably fair 'for certain' can know for sure that it was fair if they pay the minimum transaction fee.  Everyone else can simply trust that it is fair and take the risk that everyone else is colluding against them.   Given the value of the network is derived from the fairness of this, the BOD is financial stake in the network, and anyone can prove it fair for their own use I suspect it is a perfect system from a fairness perspective.   It also allocates the cost of making sure it is provably secure to those who care about it the most.
It's much simpler than POW and I like it.
But as it is hash, there might be risk of last publishing person colliding his own hash for different S. HASH(S[0...N]) will make it a bit more difficult but it still can be done if you have huge computation power like ASIC. I think we can require signing using private key instead of hash which is more secure.

275
DAC PLAY / Re: Use bitcoin block hash as source of random number
« on: April 02, 2014, 11:53:18 pm »
Quote from: toast on April 02, 2014, 11:35:41 pm
As soon as bitcoin miners learn about this then the problem just moves from LOTTO miners to bitcoin miners... So if you're unsatisfied with POW for RNG generation on the lotto network then why would you accept RNG generation from the bitcoin network?

Quote from: zhangweis on April 02, 2014, 11:33:21 pm
If we need some kind of POW for randomness, why not directly use bitcoin blockchain?

Sorry if it confuses you. I've modified the original sentence a bit. I mean only using bitcoin chain as source of RNG instead of setup our own POW.

276
DAC PLAY / Re: Use bitcoin block hash as source of random number
« on: April 02, 2014, 11:43:58 pm »
Quote from: toast on April 02, 2014, 11:35:41 pm
As soon as bitcoin miners learn about this then the problem just moves from LOTTO miners to bitcoin miners... So if you're unsatisfied with POW for RNG generation on the lotto network then why would you accept RNG generation from the bitcoin network?

Actually I like the way to use POW for RNG. I propose to use bitcoin chain only because it has gained a very big computing power and resources which makes cheating mining quite difficult.

277
DAC PLAY / Use bitcoin block hash as source of random number
« on: April 02, 2014, 11:33:21 pm »
If we need some kind of POW for randomness, why not directly use bitcoin blockchain as source of RNG? The random number can be something like the future nth block's hash. As bitcoin mining involves randomness, it's more secure for a random number generation. The block's hash is difficult to find and it will be difficult for a miner to adjust the hash to his will (to win a lottery) even if he has say 51% power. If we carefully choose the way to use the hash(like hashing it to get the result number), it can be very difficult (if not impossible) to control the result of lottery.

Maybe we can even chain the blocks by using the hash as another block's index to make it more difficult but I'm not sure whether this will break the randomness.

The down side is that every node (or at least some nodes) needs to download 2 chains to verify the block. But considering the mining power on bitcoin, I think it's worth to directly use bitcoin chain. To improve this, some nodes may choose bypassing download of bitcoin blockchain by not verifying the random number generation or directly getting hash value from some online services like blockchain.info.

278
DAC PLAY / Re: Lotto two layers design
« on: April 02, 2014, 05:12:34 pm »
Quote from: HackFisher on March 31, 2014, 07:24:16 am
Second, the core layer is nothing but a true random number decentralized raffle process protected by mining, blockchain db etc.

If we need some kind of POW for randomness, why not directly use bitcoin blockchain? The random number can be something like the future nth block's hash. As bitcoin mining involves randomness, it's more secure for a random number generation. The block's hash is difficult to find and it will be difficult for a miner to adjust the hash to his will (to win a lottery) even if he has say 51% power. If we carefully choose the way to use the hash, it can be very difficult (if not impossible) to control the result of lottery.

Maybe we can even chain the blocks by using the hash as another block's index to make it more difficult but I'm not sure whether this will break the randomness.

The down side is that every node (or at least some nodes) needs to download 2 chains to verify the block. But considering the mining power on bitcoin, I think it's worth to directly use bitcoin chain.

279
KeyID / Re: Bitshare DNS and distributed static site content
« on: March 20, 2014, 03:56:07 am »
Quote from: toast on March 20, 2014, 02:33:41 am
That's "application layer" stuff. DNS just provides a key-value store. So yeah, you can make a convention for how to embed a magnet link into the record. It's all about how apps interpret the value you put in.

Sent from my SCH-I535 using Tapatalk

Thanks for the reply and it's clear now. So it's kinda like namecoin that we can put anything we want into the record.

280
中文 (Chinese) / Re: 论“去中心化股份交易系统Bitshares Me”在华为公司的首次落地
« on: March 20, 2014, 02:21:51 am »
如果把ME比成分布式证交所，很显然，MeCoin只是应该对应于证交所的收入，比如交易手续费和分红手续费之类的，这个比例应该很小而且手续费比例按理说应该不是固定的，而是应该有种市场机制来发现。

281
KeyID / Bitshare DNS and distributed static site content
« on: March 20, 2014, 02:09:17 am »
With bitshare DNS, we can have a secure p2p network for naming. But if I want to put up some static web content, I still have point of failure risk as I need to point my DNS to an IP address. Some example risks:

. IP address banned.
. Attack on this IP.

Can we set up something backed by torrent and bitshare DNS? Something like twister(http://twister.net.co/) and pirate bay plan(http://www.theregister.co.uk/2014/01/08/pirate_bay_blockade_evading_client/).

282
中文 (Chinese) / Re: 基于Bitshares Lotto的去中心化双色球系统
« on: March 19, 2014, 01:43:14 pm »
Quote from: SuanBing on March 17, 2014, 05:34:55 pm
中奖结果用一个不可逆的函数生成，这个函数设计为：
fun(当前区块数，本期投注次数，本期投注金额）---〉中奖结果（一组像双色球那样的数字）
fun(当前区块数，本期投注次数，本期投注金额）。这个我比较怀疑矿工可以生成自己想要的结果。比如当前要生成的块是开奖的那个块，矿工可以通过生成新的投注的方式来碰撞生成自己想要的结果，而且他的这些交易可以不广播，如果没有生成快也没有损失。需要更好的随机算法。

283
General Discussion / Re: One possible attack to POS mining
« on: March 11, 2014, 08:19:20 am »
Quote from: bytemaster on March 11, 2014, 05:44:33 am
Quote from: Troglodactyl on March 11, 2014, 05:28:34 am
http://the-iland.net/static/downloads/TransactionsAsProofOfStake.pdf

Pages 5 and 6 seem to address these issues.  Also, I suspect that there's a maximum on coin day accumulation.  When the inactivity fee is charged, doesn't this effectively reset the coin age to 0?

Yes it does.

Thanks for the clarification and this does eliminate the risk quite a lot.

What if I carefully choose time when large CDD just happened which means my percentage of CDD grows relatively? Also consider the diversity of shares, even if you find my attack in short time, it will be difficult to collect enough coin days to beat my alternative chain in time. It turns worse as time goes on when this alternative chain grows as I'm in the longest chain and all the following transactions are protecting me.

I think the point here is that comparing with total CDD in a block, I don't need much percentage of shares to make an attack. I suspect one block will destroy less than 1% of coin days in average. This means the cost of an attack is low. If I have 10% shares, even if it's defeated to discarded branch chain, it's relatively easy to roll back several blocks and make it survive 1 or 2 future blocks. To defeat it, you may need manual processes. This will not happen in POW if you own 10% power and it will be quite impossible that you can roll back 1 block because to do so, you'll need to win at least 2 sequencial blocks and it contains randomness. But with POS, you'll be assured your attack can work as I don't see any randomness in POS mining. Maybe we should inject some randomness in the mining to solve this issue.

284
General Discussion / Re: One possible attack to POS mining
« on: March 11, 2014, 07:55:24 am »
Quote from: toast on March 11, 2014, 04:34:01 am
Hmm, I think the answer is that your CDD can only accumulate on the current longest chain, you can't make an alternate longer chain because if you start building off of an old block then your coins will look much younger with respect to that block.

Let's say I want to roll back 10 blocks and my CDD will be just a little younger than the current longest chain.

285
General Discussion / Re: One possible attack to POS mining
« on: March 11, 2014, 04:00:12 am »
Even if the coin days are cut to be less than 365 days, I guess 20% of the shares can be enough to make such an attack if I carefully choose time to attack.

I can spend the coins before my attack and roll them back so that I lose very little no matter the value of shares drops or not after the attack.

Pages: 1 ... 12 13 14 15 16 17 18 [19] 20 21

Page created in 0.027 seconds with 20 queries.