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

Pages: 1 ... 290 291 292 293 294 295 296 [297] 298 299
4441
现在这样挺好.这样更多老外会来看中文版,沟通会更多.
这样也可以让大家发言更理智点,多讨论具体问题,而不只是为了发泄或者灌水.

Translation:
It's cool now , more English-speaker will visit the Chinese board more often to communicate.
By doing so , we can let the people more reasonable when doing posts , more discussion on specific problems instead of purely let off  their feelings .

4443
vato_ created a delegate report over here:
http://kettenblog.wordpress.com/101-delegates/

there's a table which states how has several delegates IIRC
Good. It would be better if we have more info about the candidates. When we vote we do not just look at top 101.

By the way it's hard to access that site from China..

4444
General Discussion / Re: My preferred solution for delegates
« on: November 12, 2014, 09:30:23 am »
My preferred solution for delegates:

1) They are trusted and able to maintain the network
2) They publish a budget on who they plan to fund and generally don't do work themselves.
3) They coordinate with other delegates.

If the role of delegates is to manage up to 1% of the spendable budget then we can hire many delegates.   Lets keep it really simple, if you don't know how to run a node ask for funding from a delegate that does run a node.   If the delegate thinks it is worth while and won't cause him to lose his spot then he can support you.

Thus at the end of the day you only have to trust that a delegate can make wise evaluations about the performance of the real workers while maintaining a node.
I agree with this.  though...

I think this begs for variable pay rates or perhaps multi-sig delegate pay over 3%?  Or do you see delegates just haveing multiple sub accounts.  100%/80%/50%/25%/3%   ... or just a 100% and a 3% and a promise to burn.  Or just a 100% and a promise to burn.

What i fear is a delegate gets 100% pay for some project.  Its completed, but the pay remains.  Rather than lose his spot, the delegate feverishly searches for somewhere else to spend the cash.  Fills up his project board with candidates etc.  (Its surely easier to keep 100% pay once you've got it, and usually leads to waste/inefficiencies)  Or do you campaign again to have your 3% delegate re-elected.  ... or promise to burn the 97%(multisig could force burn)

voter apathy should default to base 3% pay, not full 100% pay based on prior projects.
This make sense. +5%

4445
General Discussion / Re: My preferred solution for delegates
« on: November 12, 2014, 09:29:01 am »
Employee or big contributors really don't need to maintain the delegate themselves, because bitsuperlab provides such hosting service.
Besides, I support the opinion that we should set a variable payrate/block reward for delegate, according to the market cap.
but we need to ensure that we have > 30 (prefereably alot more) businesses running the delegates as a service.

else this will lead back to centralization ..
I agree with you that we need to consider decentralization..
However maintaining a delegate is not too hard from a technical point of view. Bitsuperlab can provide such service, others could also provide likely service. Just an example.

By the way I think the voter-delegate-contributor model make the system too complex, and maybe financial inefficient. How can we measure the amount of contribution of a delegate, or say why he deserve the payrate? When the marketcap changes, does all the delegates still deserve their payrate?

4446
General Discussion / Re: My preferred solution for delegates
« on: November 12, 2014, 08:45:05 am »
Employee or big contributors really don't need to maintain the delegate themselves, because bitsuperlab provides such hosting service.
Besides, I support the opinion that we should set a variable payrate/block reward for delegate, according to the market cap.
+5%
Why not just pay bitUSD instead of BTS? It's more stable.

4447
I like this thread. +5% +5%

4448
中文(Chinese) / Re: BitShares 0.4.24-RC2(可看一下新规则)
« on: November 11, 2014, 06:53:25 am »
是不是991700区块到达前出新钱包啊 老钱包不怎么好用 每次打开都要卡死2  3次
只看到说解决了一个内存泄露问题,可能会好用一点.
没看到说出全新钱包.

4449
DAC 委托人 / Re: 誰有空做一個seed node結點的教程?
« on: November 03, 2014, 07:59:53 pm »
上面那两个帖子不是我写的吗?
原帖怎么打不开了?

4450
General Discussion / Re: Cannot sync new client if less 2G Ram
« on: November 03, 2014, 05:09:57 pm »
It works; I've done syncing in multiple stages before when I was trying to figure out if the fact that later blocks sync slower than earlier blocks is because of this excessive memory usage.  (spoiler: it's not, later blocks are just as slow when the client's memory usage is 500MB as they are when it's 2GB.)

The new 0.4.23.1 build lets you sync from scratch without stopping.
Sure it works for syncing, I always sync this way in my winxp box.
But I don't think it will work for re-indexing..

4451
我觉得coins不是sfinder的马甲啊。虽然有些关系。
sfinder技术高手,自己会弄服务器。
coins之前连node server都不会架,还发帖悬赏求助的。

我去。。那帖子怎么找不到了,难得我还码了好多字在里面的。

4452
中文(Chinese) / Re: 关于BTS升级,几件你应该知道的事情
« on: November 03, 2014, 04:38:53 pm »
中肯。
一句话,请大家珍惜手中的票和投票权。
现在上榜的代表,升级后费率都变成是3%,不能上调,小散们先不要给新代表投票。
真正看到新的代表做出贡献了,如果是实实在在的贡献,才考虑加投。
看到有问题的就投反对票。
估计3i也不会随便给高费率的代表投票的。

以后很可能是大户自己投自己,或者联合起来互相投,这个很难防。不知道3I有什么对策没有。

4453
如题,急问,我原来投了AGS,但还没有创建BTSX账户领取BTSX,D​NS及VOTES,请问11月快照会受影响吗?
原来主要是担心BTSX钱包不稳定会丢币,因此一直没有导入pts钱包。
另外11月5日后还可以导入pts钱包吗?

之前为什么不领。肯定不影响。但现在价格都不是最好的时候了。。。
看你的意思,领了就是为了砸盘吗?
长期投资的早领晚领没什么区别。如果是要用来投票就领出来。

4454
中文(Chinese) / Re: 通胀是否损害了受托人外小股东的利益
« on: October 31, 2014, 01:45:00 pm »
BM这个帖子
https://bitsharestalk.org/index.php?topic=10781.msg141941
大意是说,11月5号硬分叉,之后所有现有的受托人费率会自动降为3%,如果有人想使用更高费率,需要重新注册受托人,然后重新拉票。
分叉后开始采用新规则:所有手续费销毁,受托人拿固定工资,也就是(50*费率)。(这个50的基数不在上面那个帖子里)
受托人工资不会再像现在这样,因为交易量多少导致实际产生手续费多少而浮动了。

所以,如果你不想要高通胀,不要把票投给那些高费率的受托人就好了。另外我好像记得可以投反对票?那就更好。
其实这个事情,会让大家更重视自己手中的票和投票权。

另一个帖子,
https://bitsharestalk.org/index.php?topic=10747.0
也就是说把DAC重新定义为自治社区的,里面说了:3I手头的票,不再由BM一个人决定投给谁,而是会分给核心团队,由他们自行决定投给谁。

4455
General Discussion / Re: Cannot sync new client if less 2G Ram
« on: October 29, 2014, 03:42:18 pm »
I'm running the client in Ubuntu 14.04 LTS. (maybe debug mode?)
Every time re-indexing the block chain database, it eats more RAM, say about 3GB for 0.4.20, more than 3GB for 0.4.23.
So.. if you run the client with less than 3G RAM, it's better to start from an empty database, don't upgrade from a old chain database.

Another experience in a old version of client: when syncing from a chain server, the client eats more and more RAM as well. Restart works. Maybe there is a memory leak bug.

Pages: 1 ... 290 291 292 293 294 295 296 [297] 298 299