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 - muse-umum

Pages: 1 ... 12 13 14 15 16 17 18 [19] 20 21 22 23 24 25 26 ... 48
271
中文 (Chinese) / Re: 斗胆预测下BTS的价格!
« on: June 27, 2014, 01:36:51 am »
LZ看来还是保守啊,BTS如果低于50RMB一个,基本上大部分人都算投资失败了。低于20元一个,那大部分人都会亏本了。
对于价格我在短期内持悲观态度。

272
中文 (Chinese) / Re: 建议做个插件筛选自动投票
« on: June 26, 2014, 06:55:26 am »
DPOS不适合用在BTSX上,用在赌球类需要引入现实数据的DAC有用,BTSX的代表会导致很多问题,也许现在市值低不会出什么问题,因为无利可图,但是一定支撑不到大市值,这基本是可以肯定的……我旗帜鲜明地反对DPOS用在BTSX上……


Sent from my iPhone using Tapatalk

你可以看看我在Approval Voting那个帖子里对你的回复。进行攻击并不那么难,但也远远没那么容易。

273
中文 (Chinese) / Re: Approval Voting 同意投票/赞同投票
« on: June 26, 2014, 06:49:40 am »
Quote
对绝大部分人来说,也包括我,不想玩这个还要去考虑投票给谁的问题,人们只是希望打开钱包就能收发转账就好,至于其他事,普通用户根本不想操心,简单实用,才能被市场认同。

我相信会越来越多人打开钱包投票的。这不是POW币。你见过对自己的公司毫不关心的shareholder吗?

Quote
仅仅是靠拉票选代表已经给人感觉这个制度有腐败的嫌疑,除非3I能设计出一套非常智慧的体系,但是目前我没有看到,而且看到前几天的讨论我甚至有一种DPOS以后是代表独裁制的趋势。美国崇尚自由与平等,对我们来说这样的渴望更强烈,如果DPOS里的代表的权利过大的话,我只有一种自己被代表绑架的感觉,要看代表的脸色,这不是我要的自由。

拭目以待吧。

274
中文 (Chinese) / Re: Approval Voting 同意投票/赞同投票
« on: June 26, 2014, 06:39:44 am »
这也给我们两点启示:
1,不要去玩股份过于集中的DAC。
2.  转变思维。POS跟POW的主要区别之一,就是持股(币)者有没有权力。POW里持币者没有权力,即使某老师拥有超过6位数的币,矿工都不需鸟他,更别说其他散户了,矿工才是主宰者,即使他1个币都不留;而POS里,持股人是维护网络安全的一部分,每1票都会产生影响,Your Voice Matters,这会促使越来越多的人常一点打开钱包,考核自己信任的受托人是否在好好地表现。

275
中文 (Chinese) / Re: Approval Voting 同意投票/赞同投票
« on: June 26, 2014, 06:11:44 am »
@Nimrod

你说的问题确实存在。
现在dry run 6 里已经改了,最多能给101个人投票,也就是说你必须拥有超过51%的票数,才能确保完全不被赶出局。
现实的情况是不可能全部人都在投票,假如像你说的那样投票率为50%,那你必须至少要有25%的票才能确保不出局,这里还有一个前提,那就是另外的那50%的票真的是没有投给任何1个人。


实际上要考虑的问题还很多,1%不行,我敢说10%就可以在很长一段时间內都没人能把我踢出了。投票率就是一个,还有另外一个问题就是,一旦发现做恶的代表,需要全体持有者去手动淘汰,大多数人可能几天几个月都不关注这个,我就用个币而已,谁想操心这个。DDPOS的学习理解成本太高。不得不说DDPOS是个馊主意,甚至是倒退。

如果你有10%的票,那只需要活跃的投票数超过20%就足够把你挤出去了,你没法折腾多久,这点我相信很容易做到,想想3I手上有多少票就知道。所以不需要全体持有者,仅需20%。 “我就用个币而已,谁想操心这个” 你的这种观点也许是目前大多数人的观点,但我相信会改变的,你要意识到持股者是shareholder,是股东,你再想想看。


是的,就算难以51%攻击(尽管我觉得这个攻击成本要低于其他算法),我就赖在代表里面捣乱恶心你都可以,你是拿我一点办法都没有的,只要我有超过最后一名代表得票率的币数。这个逻辑bm要好好理理……当然DPOS有不少好处,但是用在BTS X上绝对不适合。可以用在赌球DAC之类……


如上面所说,取决于你所拥有的票数能不能占活跃的投票总数的1半以上,并且另外的那些不活跃的票没有投给任何人。如果你没那么多票,随随便便就可以赶你出局。



276

Delegates can only be fired when someone produces a transaction with crypto-graphic proof that a delegate has signed a false statement (multiple blocks for the same time, or declared a transaction to be included in the chain when it wasn't).   


Be automatically fired or by approval removed manually.

277
General Discussion / Re: Approval Voting vs Delegation
« on: June 25, 2014, 11:42:44 pm »
33% ensures a spot as delegate

After more thinking I have increased this requirement in the latest dry run... no one is ever assured a spot
So you can vote for 101 delegates ?
Yes

Why? How did you calculate this ?

278
General Discussion / Re: Approval Voting vs Delegation
« on: June 25, 2014, 03:55:22 pm »
Can you please describe how we are going to kick the evil delegate out of the top 101 since we can't vote against ? 

Is it still a whack-a-mole game if the evil delegate owns a large amount of shares and can vote himself (another account) back ?
Hi heyD, I hope this explanation helps:
the "whack-a-mole" term comes from the idea of trying to vote down a delegate who then switches his support to another delegate he controls and then you have to switch your downvote etc.  This doesn't apply to approval voting because you don't need to actively downvote delegates.  In some sense you are by default already downvoting every delegate that you haven't actively decided to upvote.

Unlike in the previous system, the evil delegate can't vote himself in on his own because he needs much more support to get elected.  His stake is not enough to compete with delegates that have support from the whole community.  If he switches to a new delegate he is starting all over from scratch with no votes and no trust and it will take him a long time to get supporters.

People need to build trust from the community to get elected.  If they then reveal themselves to be evil (or more likely incompetent) the community will pull their support quickly in favor of better alternatives.  You get rid of bad delegates by simply keeping a bit of an eye on the delegates you voted for to make sure they performing well and if they don't, you remove your vote for them and vote for someone else instead.

Thanks, much clear now. So how much shares does the attacker have at least to own to make sure he won't be kicked out of the top 101 ? 33%

279
中文 (Chinese) / Re: Approval Voting 同意投票/赞同投票
« on: June 25, 2014, 03:45:57 pm »
这样的话,如果一个拥有超过1%币的人是否永远无法被踢出(就算它做恶)?因为只要自己投自己就能确保在前100名,如何踢出这类代表?


Sent from my iPhone using Tapatalk

No。要搞清楚一点,你有1个XTS的话,最多可以同时投给33个人受托人,这33个人都各得到1票。
所以,假如总数是100XTS,你占1%也就是1个XTS,顶多给自己的33个delegate各投1票。剩下有99个XTS,只要不投给你的33个delegate,无论怎么投都很容易把你挤出去。

280
中文 (Chinese) / Re: Approval Voting 同意投票/赞同投票
« on: June 25, 2014, 02:45:39 pm »
但是,也需考虑到负面因素:1、你信任的受托人不一定是稳定出块的人,也许只是因为你投给了你的朋友,这样很可能会出现”买票“行为;2、受托人一旦被多数人持续肯定,那么就意味着他需”永远“开动服务器出块,这等于变相绑架了受托人的选择权。建议在客户端给受托人留有”quit“选项。

1. 这种行为是肯定会发生的,但慢慢地大家就会发现选择表现好的人才能最大程度保障自己的利益。2. 我不觉得有绑架这一说。受托人要退出时关掉客户端不出块就可以了,给他投了票的人自然会取消对他的信任。但如果要退出的话一般都会在社区上先打个招呼吧。

不懂,如果排名头几名的突然反水作恶,或者被攻击,怎么及时把他们换下来?

取消对他们的信任即可,之后你的票就再不会投给他们了,大家都这么做的话他们很快就会被淘汰。除非他们拥有大部分投票权,这就涉及到DPOS攻击的问题了。

281
 +5% +5% +5%

282
中文 (Chinese) / Approval Voting 同意投票/赞同投票
« on: June 25, 2014, 10:25:50 am »
大家的怒气消了一点没?我再来转移大家的注意力吧,来看看DPOS中投票方式的改进:Approval Voting,中文叫同意投票/赞同投票,三俗称AV。

维基百科中对AV的定义:
中文 http://zh.wikipedia.org/zh/%E5%90%8C%E6%84%8F%E6%8A%95%E7%A5%A8
英文 http://en.wikipedia.org/wiki/Approval_voting

英文版的讨论:
https://bitsharestalk.org/index.php?topic=4009.msg67618#msg67618
https://bitsharestalk.org/index.php?topic=5164.0
https://bitsharestalk.org/index.php?topic=5205.0

参与测试的朋友应该知道之前的投票大概是这样的:你在钱包里选择受托人或候选人(delegate/candidate),给予信任(trust level >0)或者不信任(trust level<0),当然不选择也可以(trust level =0),然后在转账的时候,你的赞成票(vote for)或反对票(vote against)就会投出去他(给自己转账或者给别人转账都是投票的过程,其思想就是需要用股份/权益(Stake)来表达你的意见,这其实很好理解,POS嘛)。经过对赞成票和反对票的计算后,得分排名在前101的受托人才有出块的权力。这个过程有人会出局,有人会入局。

这个投票方法的弊端:
某个受托人作恶被逮到之后,几乎只有1个办法能把他赶出局,那就是靠投反对票来把他赶出top 101。问题一,大部分人是不会整天开着客户端来投票的(lazy voters),只有要转账时才会打开客户端,很难保证大部分人能一起联合起来投反对票;问题二,作恶者被赶出局之后,他可以通过注册新的受托人继续作恶,我们又要投反对票了,这样子会变成无穷无尽的打地鼠游戏(whack-a-mole game)。

Agent86提出了Approval Voting这种投票方式,经过他和toast的努力游说,BM接受了这种投票方式。它是这样的:
对于某个受托人你只有选择信任(trust level >0),或者不选择(trust level =0),而没有不信任这一选项, 也就是说没有反对票了。得赞成票数排名在前101的受托人有出块的权力。这样子的投票方式可以规避上面提到的两个问题,因为你对你所信任的受托人投了赞成票,实质上相当于对其他所有的受托人投了‘反对票’; 在任何时候你只需要关心你所信任的受托人,如果你觉得你信任的某个受托人在干坏事,很简单,不信任他并叫别人也这么做就可以了。

目前的测试版本里已经实施了这种投票方法,如果你信任了4个受托人,当你转账的时候就会把你的‘票’投给这4个人之中的某几个(应该是1--3个)。选择这几个人是随机的过程,你可以选择一直用某个随机组合(这样子投的话,别人可以通过对投票的分析知道某几个地址是属于同一个人的,匿名性有所降低),或者每次投票都用不同的组合。每次最多只能给33个受托人投票。

Edit:在dry run 6里,这个数字改变了,每次最多可以投给101个人。

大家觉得这样子的投票方法如何?

P.S 拜托大家,我希望这个帖子纯粹一点,就单单讨论这个话题,不要扯到其他的,例如“BM又乱想了,一天一个想法” “能不能先做出1个产品再说?”之类的。谢谢!
感谢cgafeng帮助我理解这种投票方法。




283
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 25, 2014, 08:08:10 am »
Strange that my delegates too-young and too-simple are always missing blocks. They are among the top 101.

Code: [Select]
heyddryrun5 (unlocked) >>> wallet_list_my_accounts
NAME (* delegate)                  KEY                                                             REGISTERED            FAVORITE       TRUST LEVEL    BLOCK PRODUCTION ENABLED
heyd-naive                         XTS54aGvENZaziDPoTBWB8DVFzcTpezKm8stU7kbpQ7yuZZ483pzN           2014-06-24T01:26:30   NO             0              N/A                     
heyd-simple                        XTS6XSi2PDstduVswZycvq8EwenbpERqQUq57QEm6XpbZjPj7XQz3           2014-06-24T01:26:30   NO             0              N/A                     
heyd-young                         XTS7YRXr7X4euUsQoEF8R4M9ErGxaNGEKYfpqMNYvHFPSsQpciyLG           2014-06-24T01:26:30   NO             0              N/A                     
sometimes-naive *                  XTS5kppbLHPT6JV7aGGXQ3Nu4TvtR1u388uau6Yqv1J9Ni64rnFnc           2014-06-24T02:12:30   NO             10             YES                     
too-simple *                       XTS5Def6N9bsueAX2YnvQNKHzbphG1Qx9syKthF9BFFSZZT5EkS3x           2014-06-24T02:12:30   NO             40             YES                     
too-young *                        XTS6Kp6598CtJhDVauQwQKVLBZZ34o9W55CR2vhCNRezvKL2KHQtB           2014-06-24T02:12:00   NO             30             YES                     

too-young
Code: [Select]
heyddryrun5 (unlocked) >>> blockchain_get_delegate_block_stats too-young
[[
    621,{
      "missed": false,
      "latency": null
    }
  ],[
    713,{
      "missed": false,
      "latency": null
    }
  ],[
    807,{
      "missed": false,
      "latency": null
    }
  ],[
    894,{
      "missed": false,
      "latency": null
    }
  ],[
    962,{
      "missed": false,
      "latency": null
    }
  ],[
    1088,{
      "missed": false,
      "latency": null
    }
  ],[
    1178,{
      "missed": false,
      "latency": null
    }
  ],[
    1278,{
      "missed": false,
      "latency": null
    }
  ],[
    1367,{
      "missed": false,
      "latency": null
    }
  ],[
    1421,{
      "missed": false,
      "latency": null
    }
  ],[
    1510,{
      "missed": false,
      "latency": null
    }
  ],[
    1585,{
      "missed": false,
      "latency": null
    }
  ],[
    1626,{
      "missed": false,
      "latency": null
    }
  ],[
    1713,{
      "missed": false,
      "latency": null
    }
  ],[
    1776,{
      "missed": false,
      "latency": null
    }
  ],[
    1842,{
      "missed": false,
      "latency": null
    }
  ],[
    1892,{
      "missed": false,
      "latency": null
    }
  ],[
    1942,{
      "missed": false,
      "latency": null
    }
  ],[
    1993,{
      "missed": false,
      "latency": null
    }
  ],[
    2089,{
      "missed": true,
      "latency": null
    }
  ],[
    2130,{
      "missed": false,
      "latency": null
    }
  ],[
    2201,{
      "missed": true,
      "latency": null
    }
  ],[
    2227,{
      "missed": true,
      "latency": null
    }
  ],[
    2301,{
      "missed": true,
      "latency": null
    }
  ],[
    2330,{
      "missed": true,
      "latency": null
    }
  ],[
    2418,{
      "missed": true,
      "latency": null
    }
  ],[
    2482,{
      "missed": true,
      "latency": null
    }
  ],[
    2533,{
      "missed": true,
      "latency": null
    }
  ],[
    2585,{
      "missed": true,
      "latency": null
    }
  ],[
    2598,{
      "missed": true,
      "latency": null
    }
  ],[
    2604,{
      "missed": true,
      "latency": null
    }
  ],[
    2657,{
      "missed": true,
      "latency": null
    }
  ],[
    2704,{
      "missed": true,
      "latency": null
    }
  ],[
    2737,{
      "missed": true,
      "latency": null
    }
  ],[
    2778,{
      "missed": true,
      "latency": null
    }
  ],[
    2824,{
      "missed": true,
      "latency": null
    }
  ],[
    2856,{
      "missed": true,
      "latency": null
    }
  ],[
    2893,{
      "missed": true,
      "latency": null
    }
  ],[
    2967,{
      "missed": true,
      "latency": null
    }
  ]
]

too-simple
Code: [Select]
heyddryrun5 (unlocked) >>> blockchain_get_delegate_block_stats too-simple
[[
    639,{
      "missed": false,
      "latency": null
    }
  ],[
    716,{
      "missed": false,
      "latency": null
    }
  ],[
    857,{
      "missed": false,
      "latency": null
    }
  ],[
    971,{
      "missed": false,
      "latency": null
    }
  ],[
    1073,{
      "missed": false,
      "latency": null
    }
  ],[
    1114,{
      "missed": false,
      "latency": null
    }
  ],[
    1202,{
      "missed": false,
      "latency": null
    }
  ],[
    1290,{
      "missed": false,
      "latency": null
    }
  ],[
    1374,{
      "missed": false,
      "latency": null
    }
  ],[
    1470,{
      "missed": false,
      "latency": null
    }
  ],[
    1561,{
      "missed": false,
      "latency": null
    }
  ],[
    1634,{
      "missed": false,
      "latency": null
    }
  ],[
    1772,{
      "missed": false,
      "latency": null
    }
  ],[
    1828,{
      "missed": false,
      "latency": null
    }
  ],[
    1887,{
      "missed": false,
      "latency": null
    }
  ],[
    1960,{
      "missed": false,
      "latency": null
    }
  ],[
    2011,{
      "missed": false,
      "latency": null
    }
  ],[
    2077,{
      "missed": false,
      "latency": null
    }
  ],[
    2136,{
      "missed": true,
      "latency": null
    }
  ],[
    2206,{
      "missed": true,
      "latency": null
    }
  ],[
    2277,{
      "missed": false,
      "latency": null
    }
  ],[
    2374,{
      "missed": true,
      "latency": null
    }
  ],[
    2451,{
      "missed": true,
      "latency": null
    }
  ],[
    2579,{
      "missed": true,
      "latency": null
    }
  ],[
    2625,{
      "missed": true,
      "latency": null
    }
  ],[
    2653,{
      "missed": true,
      "latency": null
    }
  ],[
    2666,{
      "missed": true,
      "latency": null
    }
  ],[
    2712,{
      "missed": true,
      "latency": null
    }
  ],[
    2742,{
      "missed": true,
      "latency": null
    }
  ],[
    2785,{
      "missed": false,
      "latency": 4294967268
    }
  ],[
    2945,{
      "missed": true,
      "latency": null
    }
  ],[
    2988,{
      "missed": true,
      "latency": null
    }
  ],[
    2992,{
      "missed": true,
      "latency": null
    }
  ]
]

Code: [Select]
heyddryrun5 (unlocked) >>> info
{
  "blockchain_head_block_num": 2995,
  "blockchain_head_block_time": "20140625T070730",
  "blockchain_head_block_time_rel": "57 seconds old",
  "blockchain_confirmation_requirement": 303,
  "blockchain_average_delegate_participation": 58.179723502304149,
  "network_num_connections": 41,
  "ntp_time": "20140625T070827.387744",
  "ntp_error_seconds": -0.0011310000000000001,
  "wallet_unlocked_seconds_remaining": 0,
  "wallet_next_block_production_time": "20140625T072400",
  "wallet_seconds_until_next_block_production": 933,
  "wallet_local_time": "20140625T070827",
  "blockchain_random_seed": "57b2e227579fff49c5d77dac4e3588b75169ccc9",
  "blockchain_shares": 199999056733994,
  "network_num_connections_max": 200,
  "network_protocol_version": 103,
  "wallet_open": true,
  "wallet_unlocked_until": "20140625T061658",
  "wallet_version": 100
}

Code: [Select]
heyddryrun5 (unlocked) >>> about
{
  "bitshares_toolkit_revision": "eb5bed05842718ac07ee26a20e264269f62efd42",
  "bitshares_toolkit_revision_age": "5 hours ago",
  "fc_revision": "3de924b33647a9a547b772a58415835f021f92b3",
  "fc_revision_age": "83 hours ago",
  "compile_date": "compiled on Jun 25 2014 at 02:29:00"
}

I guess I've found the reason.

The transactions which registered delegates are now in pending status. LOL.. Maybe the shitty forks caused this.

Code: [Select]
heyddryrun5 (unlocked) >>> wallet_account_transaction_history
BLK    .TRX  TIMESTAMP           FROM                TO                  MEMO                                             AMOUNT             FEE              ID
----------------------------------------------------------------------------------------------------------------------------------------------------------------------------
    475.3    2014-06-24T01:27:00 heyd-simple         heyd-simple         register heyd-young                         0.00000 XTS         0.10001 XTS        fd713570
    475.2    2014-06-24T01:27:00 heyd-simple         heyd-simple         register heyd-simple                        0.00000 XTS         0.10001 XTS        d4d3ec6e
    475.1    2014-06-24T01:27:00 heyd-simple         heyd-simple         register heyd-naive                         0.00000 XTS         0.10001 XTS        413f7028
    548.0    2014-06-24T02:12:30 UNKNOWN             UNKNOWN                                                         0.00000 XTS         0.00000 XTS        fb12b7a3
   pending   2014-06-24T02:12:30 heyd-simple         heyd-simple         register too-young as a delegate            0.00000 XTS         2.19716 XTS        341cfdce
    549.0    2014-06-24T02:13:00 UNKNOWN             UNKNOWN                                                         0.00000 XTS         0.00000 XTS        76705286
    549.1    2014-06-24T02:13:00 UNKNOWN             UNKNOWN                                                         0.00000 XTS         0.00000 XTS        e1b5a153
   pending   2014-06-24T02:13:00 heyd-simple         heyd-simple         register sometimes-naive as a d...          0.00000 XTS         2.19716 XTS        5950588d
   pending   2014-06-24T02:13:00 heyd-simple         heyd-simple         register too-simple as a delegate           0.00000 XTS         2.19716 XTS        04c88bc2

284
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 25, 2014, 07:25:19 am »
I just noticed that the default bandwidth limit may be a cause of forks with the stress testing going on.  A delegate with 40 connections that produces a block that is 200KB is going to have a hard time propagating that block with a 100KB / second limit.

There are command line arguments to adjust this and I am increasing the default size.

Thank you bytemaster for your hard work. But I guess it's 3AM in VA at this moment. Have a good rest and fight against the forks tomorrow.

285
General Discussion / Re: Dry Run 5: The Final Countdown
« on: June 25, 2014, 07:10:48 am »
Strange that my delegates too-young and too-simple are always missing blocks. They are among the top 101.
wallet_enable_delegate_block_production   ?

You can see the output of wallet_list_my_accounts. Both of them have been set to produce blocks.

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