gamechain
|
|
November 14, 2017, 08:03:13 AM |
|
I think we should be able to update the wallet in the old wallet,it's more easy and convenient for the user to do it. why we choose this way to update? allow the wallet develop,I think this project would be more successful than other project.
|
|
|
|
esprit577
|
|
November 14, 2017, 08:08:37 AM |
|
I think we should be able to update the wallet in the old wallet,it's more easy and convenient for the user to do it. why we choose this way to update? allow the wallet develop,I think this project would be more successful than other project.
That's a good idea. As far as I know, many updates are mandatory, and direct updates may be bug.
|
|
|
|
xibeijan
Legendary
Offline
Activity: 1232
Merit: 1001
|
|
November 14, 2017, 09:27:47 AM |
|
RC2 is still broken for me..
All I get is
11/13 19:22:51 [client-0] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:22:51 [client-1] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:22:52 [client-2] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:22:52 [client-3] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:22:53 [client-4] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:26:50 [client-5] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE
Someone please have a look into this?
visit us on Discord for faster response. Can't right now Please paste my message into your discord window?
|
|
|
|
mdodong
|
|
November 14, 2017, 10:23:52 AM |
|
RC2 is still broken for me..
All I get is
11/13 19:26:50 [client-5] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE
Someone please have a look into this?
visit us on Discord for faster response. Can't right now Please paste my message into your discord window? What's your set up? VPS or Home PC? OS, Java version? Also make sure date and time is updated.
|
|
|
|
CosaNostra
|
|
November 14, 2017, 10:48:48 AM |
|
RC2 is still broken for me..
All I get is
11/13 19:22:51 [client-0] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:22:51 [client-1] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:22:52 [client-2] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:22:52 [client-3] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:22:53 [client-4] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE 11/13 19:26:50 [client-5] INFO SemuxP2pHandler - Received DISCONNECT msg, reason = INVALID_HANDSHAKE
Someone please have a look into this?
visit us on Discord for faster response. Can't right now Please paste my message into your discord window? INVALID_HANDSHAKE" This means the other peer failed to validate your handshake message, either signature or timestamp or IP is incorrect.
I thought I should make a quote. Have you checked all this?
|
|
|
|
tradingdisaster
Full Member
Offline
Activity: 307
Merit: 100
0xb58D6E68944e195420843fA98c4A3481a5914282
|
|
November 14, 2017, 11:05:01 AM |
|
Devs: with only 64 validator nodes, would an attack by first spamming the network with tx's and then dDOSing a handful of validators not lead to the remaining validators getting overwhelmed and crash? It seems a rather vulnerable setup, esp considering a validator node needs 8GB RAM to handle 5K tx. Even on an expensive VPS, there would not be a lot of room for additional load.
Or am I wrong?
This is definitely a possibility regardless if we are using 64 or 100 validators. Validators need to have sufficient bandwidth, RAM and processing power to handle large amount of transactions and the recent and ongoing RC tests are going to expose these vulnerabilities. With these vulnerabilities exposed our Devs can work out a solution to prevent these problems from happening before we go on mainnet. I do software, so I know how usually strangers coming in and proposing "simple solutions" is a reason to face-palm, so forgive me if I am talking nonsense... In such a situation, I would either have a couple of "dark validator nodes" that light up once others go down (latencies and throughput should be measurable) or have a large pool of nodes and have them switch on and off in a random fashion so the mean is 64 active validators. Both make it harder keeping a sustained dDOS going. In your current setup, I'd be afraid of knock-on effects of a percentage of the validators getting taken out.
|
|
|
|
mdodong
|
|
November 14, 2017, 11:14:28 AM |
|
Devs: with only 64 validator nodes, would an attack by first spamming the network with tx's and then dDOSing a handful of validators not lead to the remaining validators getting overwhelmed and crash? It seems a rather vulnerable setup, esp considering a validator node needs 8GB RAM to handle 5K tx. Even on an expensive VPS, there would not be a lot of room for additional load.
Or am I wrong?
This is definitely a possibility regardless if we are using 64 or 100 validators. Validators need to have sufficient bandwidth, RAM and processing power to handle large amount of transactions and the recent and ongoing RC tests are going to expose these vulnerabilities. With these vulnerabilities exposed our Devs can work out a solution to prevent these problems from happening before we go on mainnet. I do software, so I know how usually strangers coming in and proposing "simple solutions" is a reason to face-palm, so forgive me if I am talking nonsense... In such a situation, I would either have a couple of "dark validator nodes" that light up once others go down (latencies and throughput should be measurable) or have a large pool of nodes and have them switch on and off in a random fashion so the mean is 64 active validators. Both make it harder keeping a sustained dDOS going. In your current setup, I'd be afraid of knock-on effects of a percentage of the validators getting taken out. Thank you for the feedback. We are taking all proposals into consideration in making sure we ship a stable network once we go live. Please check our github page and see if you'll be interested to contribute. We are looking to expand our team and are very much open for qualified contributors.
|
|
|
|
fudge
|
|
November 14, 2017, 12:17:51 PM |
|
dear dev, any news on the upcoming airdrop please?
|
Haшa гpyшa нaйpoзкopчyмaкyвaтiшa!
|
|
|
Phash2k
|
|
November 14, 2017, 03:31:50 PM |
|
I think we should be able to update the wallet in the old wallet,it's more easy and convenient for the user to do it. why we choose this way to update? allow the wallet develop,I think this project would be more successful than other project.
just use the upgraded version - the blockchain is no longer compatible with v RC1
|
Crypto-Beratung und Hilfe bei allen möglichen Crypto-Projekten oder Problemen! https://phash.de
|
|
|
stokholminfinity
Full Member
Offline
Activity: 352
Merit: 104
SquidCoin.cash
|
|
November 14, 2017, 05:08:03 PM |
|
I would like to see good news from the development team. Lately, there have been a lot of software changes. I see a good team work.
|
|
|
|
Phash2k
|
|
November 14, 2017, 06:03:44 PM |
|
This Project Rocks!
Waiting for the VM to bei powered up
|
Crypto-Beratung und Hilfe bei allen möglichen Crypto-Projekten oder Problemen! https://phash.de
|
|
|
Messier81
Newbie
Offline
Activity: 74
Merit: 0
|
|
November 14, 2017, 06:32:44 PM |
|
This Project Rocks!
Waiting for the VM to bei powered up
Great project! VM next year?
|
|
|
|
The Catcher in the Rye
Member
Offline
Activity: 131
Merit: 18
|
|
November 14, 2017, 09:52:20 PM |
|
This Project Rocks!
Waiting for the VM to bei powered up
Great project! VM next year? Early 2018: First release with Semux BFT consensus TBA: Second release with Semux virtual machine TBA: Third release with Semux smart contract
|
|
|
|
monsanto
Legendary
Offline
Activity: 1241
Merit: 1005
..like bright metal on a sullen ground.
|
|
November 14, 2017, 10:30:18 PM |
|
Devs: with only 64 validator nodes, would an attack by first spamming the network with tx's and then dDOSing a handful of validators not lead to the remaining validators getting overwhelmed and crash? It seems a rather vulnerable setup, esp considering a validator node needs 8GB RAM to handle 5K tx. Even on an expensive VPS, there would not be a lot of room for additional load.
Or am I wrong?
This is definitely a possibility regardless if we are using 64 or 100 validators. Validators need to have sufficient bandwidth, RAM and processing power to handle large amount of transactions and the recent and ongoing RC tests are going to expose these vulnerabilities. With these vulnerabilities exposed our Devs can work out a solution to prevent these problems from happening before we go on mainnet. I do software, so I know how usually strangers coming in and proposing "simple solutions" is a reason to face-palm, so forgive me if I am talking nonsense...In such a situation, I would either have a couple of "dark validator nodes" that light up once others go down (latencies and throughput should be measurable) or have a large pool of nodes and have them switch on and off in a random fashion so the mean is 64 active validators. Both make it harder keeping a sustained dDOS going. In your current setup, I'd be afraid of knock-on effects of a percentage of the validators getting taken out. Interesting ideas. Since we're talking nonsense I was thinking once all the validators are mostly pools, will there be a way to incentive people to check on their votes? I'm thinking people will vote and forget, or die, etc.. so you'd get votes parked for a very long time or forever.. leading to reduced voter participation. (Over really long periods burned votes could come from unintentionally burned addresses, and accumulate for certain pool validators) Do votes eventually expire?
|
|
|
|
mdodong
|
|
November 15, 2017, 12:51:22 AM |
|
Interesting ideas. Since we're talking nonsense I was thinking once all the validators are mostly pools, will there be a way to incentive people to check on their votes? I'm thinking people will vote and forget, or die, etc.. so you'd get votes parked for a very long time or forever.. leading to reduced voter participation. (Over really long periods burned votes could come from unintentionally burned addresses, and accumulate for certain pool validators) Do votes eventually expire? This wont be a problem since vote participation is not required for the concensus. Only the validator participation is required. And votes has no expiration. It remains locked until such time the voter decides to unvote.
|
|
|
|
Krista06
Member
Offline
Activity: 246
Merit: 10
AHQ3sd23QnVDzo8DqEQnhbJyYJhUSuwbmU
|
|
November 15, 2017, 02:53:15 AM |
|
Finally found a promising project that a newbie can join and participate. Thank you devs. I will read more on the project to try to learn more about it.
|
|
|
|
monsanto
Legendary
Offline
Activity: 1241
Merit: 1005
..like bright metal on a sullen ground.
|
|
November 15, 2017, 03:00:02 AM |
|
Interesting ideas. Since we're talking nonsense I was thinking once all the validators are mostly pools, will there be a way to incentive people to check on their votes? I'm thinking people will vote and forget, or die, etc.. so you'd get votes parked for a very long time or forever.. leading to reduced voter participation. (Over really long periods burned votes could come from unintentionally burned addresses, and accumulate for certain pool validators) Do votes eventually expire? This wont be a problem since vote participation is not required for the concensus. Only the validator participation is required. And votes has no expiration. It remains locked until such time the voter decides to unvote. I was thinking more along the lines of voters reconsidering who they are voting on. I'd guess voters will primarily be motivated by profits. But maybe all the pools will have very similar payouts, so there could be other reasons that decide which validator gets their vote. We've seen already some people doing research and pointing out validators that may have gamed the airdrop system. So, for example, maybe people wouldn't vote for them in the future, based on validator reviews, to keep things more decentralized. But if people just park their votes and forget they may never reconsider if at some point they should change that vote. And that validator over time can come to be associated with different owners and performance. And over years will accumulate burned votes. So having votes expire at some rate could be good in some situations, and would increase community participation. Just thinking how things may play out way down the line..
|
|
|
|
Gwyn
|
|
November 15, 2017, 03:06:29 AM |
|
This Project Rocks!
Waiting for the VM to bei powered up
Great project! VM next year? Early 2018: First release with Semux BFT consensus TBA: Second release with Semux virtual machine TBA: Third release with Semux smart contract if reach this roadmap ,Semux is next eth? may be stronger then eth ,right?
|
|
|
|
CosaNostra
|
|
November 15, 2017, 08:20:28 AM |
|
Devs: with only 64 validator nodes, would an attack by first spamming the network with tx's and then dDOSing a handful of validators not lead to the remaining validators getting overwhelmed and crash? It seems a rather vulnerable setup, esp considering a validator node needs 8GB RAM to handle 5K tx. Even on an expensive VPS, there would not be a lot of room for additional load.
Or am I wrong?
This is definitely a possibility regardless if we are using 64 or 100 validators. Validators need to have sufficient bandwidth, RAM and processing power to handle large amount of transactions and the recent and ongoing RC tests are going to expose these vulnerabilities. With these vulnerabilities exposed our Devs can work out a solution to prevent these problems from happening before we go on mainnet. I do software, so I know how usually strangers coming in and proposing "simple solutions" is a reason to face-palm, so forgive me if I am talking nonsense... In such a situation, I would either have a couple of "dark validator nodes" that light up once others go down (latencies and throughput should be measurable) or have a large pool of nodes and have them switch on and off in a random fashion so the mean is 64 active validators. Both make it harder keeping a sustained dDOS going. In your current setup, I'd be afraid of knock-on effects of a percentage of the validators getting taken out. I believe the idea about backup validators is great. Whenever any of the main validators fail backup validators can be used...
|
|
|
|
mdodong
|
|
November 15, 2017, 11:34:43 AM |
|
if reach this roadmap ,Semux is next eth? may be stronger then eth ,right?
That's the ultimate goal. We just have to take it one step at the time. The Dev team is hard at work in making sure we stand on solid ground with the implementation of BFT consensus hence the constant tests. More to come and a very bright future for Semux.
|
|
|
|
|