Quote from: zhangweis on September 28, 2015, 02:16:03 pm

app.js:39 WebSocket connection to 'wss://graphene.bitshares.org:8090/' failed: WebSocket is closed before the connection is established.
app.js:39 !!! WebSocket Error  wss://graphene.bitshares.org:8090

Seems your client has problems opening a connection the the websocket server ... is port 8090 accessible?

Well, sometimes the websocket connection will fail. But when it makes the connection, it will show blocks and every other page well. But not for exchange page. It can list markets. But when I click USD vs CORE, it shows a blank page and stays blank for ever.
Hope the logs can help.

 ownload the React DevTools for a better development experience: https://fb.me/react-devtools
app.js:39 Connecting...
app.js:39 connecting to wss://graphene.bitshares.org:8090
app.js:4 db init done
app.js:41 ChainStore Init
app.js:41 synced and subscribed, chainstore ready
app.js:65 [Markets.jsx:24] ----- render -----> Object {markets: Object, baseAsset: Object, assets: Object, settings: Object}
app.js:65 defaultMarkets: [Object, Object, Object, Object, Object, Object, Object, Object]
app.js:65 [Markets.jsx:24] ----- render -----> Object {markets: Object, baseAsset: Object, assets: Object, settings: Object}
app.js:65 defaultMarkets: [Object, Object, Object, Object, Object, Object, Object, Object]
app.js:65 [Markets.jsx:24] ----- render -----> Object {markets: Object, baseAsset: Object, assets: Object, settings: Object}
app.js:65 defaultMarkets: [Object, Object, Object, Object, Object, Object, Object, Object]
vendors.js:1 Warning: Failed propType: Invalid prop `amount` of type `string` supplied to `t`, expected `number`. Check the render method of `r`.
app.js:65 [Markets.jsx:24] ----- render -----> Object {markets: Object, baseAsset: Object, assets: Object, settings: Object}
app.js:65 defaultMarkets: [Object, Object, Object, Object, Object, Object, Object, Object]0: Objectbase: "1.3.0"quote: "1.3.1"__proto__: Object1: Object2: Object3: Object4: Object5: Object6: Object7: Objectlength: 8__proto__: Array[0]
app.js:56 !account_name:  Object {id: "1.2.38993", balances: Object, history: Array[104]}
app.js:56 !account_name:  Object {id: "1.2.38993", balances: Object, history: Array[104]}
app.js:56 !account_name:  Object {id: "1.2.38993", balances: Object, history: Array[104]}
app.js:56 !account_name:  Object {id: "1.2.38993", balances: Object, history: Array[104]}
app.js:56 !account_name:  Object {id: "1.2.38993", balances: Object, history: Array[104]}
app.js:65 [Markets.jsx:24] ----- render -----> Object {markets: Object, baseAsset: Object, assets: Object, settings: Object}
app.js:65 defaultMarkets: [Object, Object, Object, Object, Object, Object, Object, Object]
app.js:65 [Markets.jsx:24] ----- render -----> Object {markets: Object, baseAsset: Object, assets: Object, settings: Object}
app.js:65 defaultMarkets: [Object, Object, Object, Object, Object, Object, Object, Object]

@btsjohn

https://github.com/cryptonomex/graphene/issues/39

. Thanks for listening.

OP is a bad example because the server could spoof a name->address map just as easily. The real problem has to do with chain reorganization and replay attacks. Seems the solution is that DPOS achieves consensus too quickly for that or something

Yes, reorg and replay is another issue and I still think we need an option to transfer to a bitcoin like address.

If IDs cannot be trusted then the whole protocol breaks down. 

Users should share the ID as the primary identifier.  The name is a check. 

In some sense names are less necessary and should not be used on their own. 


Sent from my iPhone using Tapatalk

Well, in my case, I always use account name and don't even care what the account id is. Actually I fear typo a lot and always copy the name instead of typing. In this sense, it's not different than an address and address has even additional hash check for typo.

If we have to go in pool way, at least we should adjust the fixed supply to 3.0 billion which is the estimated final supply under current delegate pay rate.
If the fixed supply is not set to 3.0 billion, I suggest to set up a burning worker account and a 0.7 billion project for it. We can achieve this by using public key from a blockchain random number + 1000(fixed number to avoid delegate cheating). The random number can be taken from a future block so that we can be confident that it will be somewhat truly random.

What I understand of "burn" is that burnt BTS are gone and will never come back again. But in proposed BTS 2.0, the fee goes to a pool and can later come back to circuit and I don't think it's a "burn". This means the estimated final supply grows (again) to 3.7 billion from estimated 3.0 billion even if it's locked in pool.