Quote from: bytemaster on November 11, 2014, 09:56:38 pm

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.

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.

是不是991700区块到达前出新钱包啊 老钱包不怎么好用 每次打开都要卡死2  3次

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.