Author Topic: Blockchain RNG with DPOS  (Read 14434 times)

0 Members and 1 Guest are viewing this topic.

Offline zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
We discussed this yesterday a little bit. It has several benefits but it makes resolving forks more complicated.

Do you mean http://bitshares.org/documentation/group__dpos.html#dpos_conflict_resolution ?

I guess there won't be much differences between randomness one and 1,2,3,4 one.

Let's say the next miner is decided by RGN(N-2) % 100 and the results are like [2,3,1]. In this case, A,B,C is [2,3,1] and all the same rules in that doc work with [A:2,B:3,C:1] just like [A:1,B:2,C:3]. Notice that I used N-2 which means that it's already decided when current block is not generated yet and the next miner can be ready waiting to resolve the conflicts when it happens. In the worst case, we can use N-100 but I think N-3 could be fine as the possibility of both miners are down is low and in that case the next miner (decided by RGN of last 99)  just picks up.

Edit:
In case that one miner doesn't produce block, it's just like ranking changes because we need to choose next next miner by using RNG of last 99. So there's really not much differences between the two from conflict resolving point of view.

@bytemaster, I think we can still introduce randomness into next miner decision and this can prevent most cases of miner cheating.
Weibo:http://weibo.com/zhangweis

Offline gamey

  • Hero Member
  • *****
  • Posts: 2253
    • View Profile

You could use the data/entropy from outside the DPOS system that is easily verified then have the delegates arrive at a consensus over that number ?

I can't speak for the difficulty of the code, but if you were to rely on a certain block # from the bitcoin chain and then have your DAC wait for 100 confirmations of the external data then you'd be ok ?

I guess that would require the DPOS delegates have the ability to read and post the btc data/hash/entropy to their own blocks, but I think it could work.

Although it would open you up to being cheated by a btc mining pool.  Seems silly, but if you are trying to avoid cheating with large prizes then even this needs to be considered.  I suppose a hash of multiple BTC blocks, similar to the basic RNG functionality proposed for DPOS might work ?  THen of course it becomes hard for people to verify without a high level of technical knowledge.
I speak for myself and only myself.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
We can not use btc block hash because of its long interval, other choice might be feasible, e.g. using other public feeds like gold price with frequent updates, although more centralized and less pow.
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 HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
I get your point of optionality that the btc chain delegate's secret is already public once btc block is out, 10 min is enough for a bts round of 100 delegates, so it is meaning less.  :(
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 HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile

2) For large lottery jackpots you will probably just want to rely on a BTC block header.... being dependent upon bitcoin for RNG poses some problems such as RNG speed, but has the benefit of being the most secure RNG we could hope for.

We can run a delegate for lotto DAC by generating random number from btc blockchain, combined with lotto block header.

People may vote for that delegate if people think this is necessary.

As soon as you combine data with the bitcoin header you re-introduce the problem of optionality.

I mean it is not a built-in mechanism in this DAC, just an option or suggestion for someone to run such a delegate as one of the 100 more delegates. I might be a good strategy for the delegate operator, since each delegate need to publish secret anyway, why not choose a public random seed which can be validated and trusted by the voters?

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 bytemaster


2) For large lottery jackpots you will probably just want to rely on a BTC block header.... being dependent upon bitcoin for RNG poses some problems such as RNG speed, but has the benefit of being the most secure RNG we could hope for.

We can run a delegate for lotto DAC by generating random number from btc blockchain, combined with lotto block header.

People may vote for that delegate if people think this is necessary.

As soon as you combine data with the bitcoin header you re-introduce the problem of optionality. 
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.

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile

2) For large lottery jackpots you will probably just want to rely on a BTC block header.... being dependent upon bitcoin for RNG poses some problems such as RNG speed, but has the benefit of being the most secure RNG we could hope for.

We can run a delegate for lotto DAC by generating random number from btc blockchain, combined with lotto block header.

People may vote for that delegate if people think this is necessary.
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 zhangweis

  • Sr. Member
  • ****
  • Posts: 305
    • View Profile
We discussed this yesterday a little bit. It has several benefits but it makes resolving forks more complicated.

Do you mean http://bitshares.org/documentation/group__dpos.html#dpos_conflict_resolution ?

I guess there won't be much differences between randomness one and 1,2,3,4 one.

Let's say the next miner is decided by RGN(N-2) % 100 and the results are like [2,3,1]. In this case, A,B,C is [2,3,1] and all the same rules in that doc work with [A:2,B:3,C:1] just like [A:1,B:2,C:3]. Notice that I used N-2 which means that it's already decided when current block is not generated yet and the next miner can be ready waiting to resolve the conflicts when it happens. In the worst case, we can use N-100 but I think N-3 could be fine as the possibility of both miners are down is low and in that case the next miner (decided by RGN of last 99)  just picks up.

Edit:
In case that one miner doesn't produce block, it's just like ranking changes because we need to choose next next miner by using RNG of last 99. So there's really not much differences between the two from conflict resolving point of view.
« Last Edit: May 01, 2014, 11:02:14 pm by zhangweis »
Weibo:http://weibo.com/zhangweis

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
every delegate just create one block in the period of 100 blocks ?  if one delegate create two block in latest 100 blocks ?
it's deterministic with dpos, not probabilistic like with proof of work. So it is fixed that 100 blocks are created by hundred delegates.

Right.
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 santaclause102

  • Hero Member
  • *****
  • Posts: 2486
    • View Profile
every delegate just create one block in the period of 100 blocks ?  if one delegate create two block in latest 100 blocks ?
it's deterministic with dpos, not probabilistic like with proof of work. So it is fixed that 100 blocks are created by hundred delegates.

Offline BTSdac

  • Hero Member
  • *****
  • Posts: 1219
    • View Profile
  • BitShares: K1
every delegate just create one block in the period of 100 blocks ?  if one delegate create two block in latest 100 blocks ?
github.com :pureland
BTS2.0 API :ws://139.196.37.179:8091
BTS2.0 API 数据源ws://139.196.37.179:8091

Offline ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1905
    • View Profile
  • BitShares: ebit
@HackFisher
I give you a PM

Yes, ebit, I understand you, and just waited and checked the http://www1.agsexplorer.com/. It seems that it did happened.

You know that like BTC, this transaction are recorded on the blockchain, and no one has the power to change it technically. And as it's being part of contract and being a special case with large amount PTS, I think ans suggest you might need help from the community and AGS foundation. I can not respond to your PM now.

Thanks very much.
telegram:ebit521
https://weibo.com/ebiter

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
@HackFisher
I give you a PM

Yes, ebit, I understand you, and just waited and checked the http://www1.agsexplorer.com/. It seems that it did happened.

You know that like BTC, this transaction are recorded on the blockchain, and no one has the power to change it technically. And as it's being part of contract and being a special case with large amount PTS, I think and suggest you might need help from the community and AGS foundation. I can not respond to your PM now.
« Last Edit: April 20, 2014, 03:39:46 pm by HackFisher »
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 ebit

  • Committee member
  • Hero Member
  • *
  • Posts: 1905
    • View Profile
  • BitShares: ebit
@HackFisher
I give you a PM
telegram:ebit521
https://weibo.com/ebiter

Offline HackFisher

  • Moderator
  • Hero Member
  • *****
  • Posts: 883
    • View Profile
Can there be known numbers where S1,S2 have the same HASH(S)? If yes, delegates can use this to cheat. Say the number is SH. Say I always publish SH and choose S1 or S2 to reveal if I'm the last one in the round. How can I reduce this risk?

This is technically possible, but is cost/time prohibitive.  The entire BTC proof of work system is basically based on how impossible it would be to do this sort of thing.

Surprising that the answer in short is No.

http://crypto.stackexchange.com/questions/3049/are-there-any-known-collisions-for-the-sha-2-family-of-hash-functions
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.