[ANN][SEM] Semux - Official Thread

[gamechain]

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]

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]

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]

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]

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]

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]

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]

dear dev, any news on the upcoming airdrop please?

[Phash2k]

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

[stokholminfinity]

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]

This Project Rocks!

Waiting for the VM to bei powered up

[Messier81]

This Project Rocks!

Waiting for the VM to bei powered up

Great project! VM next year?

[The Catcher in the Rye]

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]

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]

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]

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]

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]

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]

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]

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.