Quote from: abit on January 12, 2016, 09:24:11 pm

Quote from: BTSdac on October 15, 2015, 11:09:14 am

香港高速双线API 服务器(极乐净土提供）：ws://btaer.com:8090

@BTSdac 这个服务器挂了？关了？

帖子已经更改,换成国内的服务器了

谢谢。我提交到GUI的ws服务器清单了，看看下个版本会不会打进去。

Quote from: abit on January 12, 2016, 10:26:42 pm

Is there a up-to-date white paper of DPOS itself?
It would be useful when comparing to the competitors' E.G. IBM's OpenLedger, Linux Foundation's OpenLedger, Eth and so.
Sorry if this is a stupid question.

Not a stupid questions .. and we *STILL* lack this whitepaper ..
Any help/assistance would be greatly appreciated!

It's sad that bm have no time to write it down. Always rushing on implementing things and/or think about new ideas.
I am not good at writing at all, I can help check/improve if there is a draft.

Is there a up-to-date white paper of DPOS itself?
It would be useful when comparing to the competitors' E.G. IBM's OpenLedger, Linux Foundation's OpenLedger, Eth and so.
Sorry if this is a stupid question.

Thanks for the efforts.
FYI some docs are here http://docs.bitshares.eu/testnet/index.html

Quote from: bitacer on January 12, 2016, 04:07:23 pm

Are there any other websocket servers that we can choose from ?

In China we have DACPLAY, and harvey, and perhaps btsabc running ws servers. Anyone else is running this service?
Maybe it's better to add them to Graphene-ui? Maybe add a list in the documents? @xeroc  @svk @wmbutler

//Update:
I'll try to collect a detailed list first.

DACPLAY: wss://bitshares.dacplay.org:8089
RiverHead: ws://185.82.203.92:8090
Harvey: ws://128.199.143.47:2016
BTSDac: ws://139.196.37.179:8090
BTAER(BTSDac): ws://btaer.com:8090 (currently offline for me)

Pull request submitted. https://github.com/cryptonomex/graphene-ui/pull/666

Quote from: Akado on January 12, 2016, 05:14:28 pm

Quote from: BunkerChain Labs on January 12, 2016, 05:09:35 pm

Quote from: Akado on January 12, 2016, 05:01:51 pm

Quote from: xeroc on January 12, 2016, 03:27:54 pm

Quote from: Akado on January 12, 2016, 03:19:44 pm

How decentralized is BitShares if we depend on OpenLedger service to be up and running? I couldn't use it with the light client too.

Run a business .. setup your own witness nodes and there you go ..
The network is decentralized .. access to the network currently is not ..

I just don't know how to connect to other witness node in case the OpenLedger one that seems to be the default, is down. I don't know which other websocket servers to choose from, where's a list for me to manually input a new one. Couldn't we make it so in case one is down, it automatically redirects to other random node ran by witnesses?

That's not a bad idea.. setup a proxy that monitors available nodes and connects you. The only danger in that is if those nodes are not keeping up to date could be an issue.. it's easy to tell if a server is online and responding but not so easy to tell if the node is getting blocks properly etc.

Then when we click to add a new node, a list of nodes owned by witnesses would popup and we would choose the one we want. Witnesses nodes should be up to date. Or a list of witnesses who processed the last 10 blocks

It's up to the witnesses to provide that.. however I don't think they should.. their task is to witness block production.. we add end user load to that and you invite an attack vector + you need to increase their pay for more infrastructure.

Better if seed nodes provide ws services as well. Or another list of ws servers.

The rich list is awesome 
Can you add a "total value" column to the rich list?
Can you format the numbers in rich list to same number of decimal places?

Earlier or later we'll have to face this. Imo it's better earlier than later.

Rather than complaining, I'd like to think more on how to prevent the top N worst scenarios from happening.
Improve the rules from the code, not from asking someone to do something or not to do something.

What are the worst scenarios?
* A whale votes badly (perhaps by accidentally)
* A whale's account is compromised, votes badly
* A whale distribute her stake among several accounts, votes badly
* A group of whales vote badly
* A whale lend her stake to someone else, asked for no change of votes, but the borrower changed the votes, badly.
* A "bad" witness or a group of "bad" witnesses is/are voted in

How to prevent them? Some ideas here, but may be wrong.
* One stake can only vote for one committee member
* Any witness with votes higher than 10% of total stake supply are considered "voted in" (in addition need to think what will happen if too many are voted in and how to deal with it)
* When voting, one must vote for at least 5 witnesses, no more than 100 witnesses, otherwise the vote is considered invalid.
* When voting, desired_witness_number = size_of(the voted list of witnesses)*2+1, or say, if you vote for 10 witnesses, you agree that you want there are 21 witnesses in total
* standby witnesses should be allowed to produce blocks in some cases, for example some "active" witnesses are detected offline, a detected offline witness must prove that it's online so that it's permitted to produce block again.

It's too bad that we lost two witnesses in the process.

It means our remaining active witnesses have to work harder.