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?
Topic: [ANN][SEM] Semux - Official Thread - page 382. (Read 694145 times)
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?
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.
Hackers spamming the network with TX's and DDOSing validators I think is the only major stumbling block left here. If dev can put a countermeasure on this then the road ahead is clear for us to travel.
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?
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.
upgrade to rc.2, works and smoothly succes for semux 
yes ,also work fine for me ,hope dev process rc test as qucik as possible ,i am waitting for main network.
upgrade to rc.2, works and smoothly succes for semux
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?
Or am I wrong?
Very good, I will buy it.I will always be concerned about the progress of the project, sem will be on the moon. Each round of testing is conducted in an orderly manner.
I am running a client and everything is fine.
I am running a client and everything is fine.
i am also keep watching this project closely alought i have a little coins, but really happy when i see dev is working hard on project behind.
Very good, I will buy it.I will always be concerned about the progress of the project, sem will be on the moon. Each round of testing is conducted in an orderly manner.
I am running a client and everything is fine.
I am running a client and everything is fine.
What is the issue exactly?
We dumped 8000 transactions in one block for stress test.
Many validator were unable to handle such load. The network had trouble with propagating the block within 10 seconds, and thus got stuck.
RC2 will be released on Saturday to address issue!
Semux v1.0.0-rc.2
1. This version is not backward compatible. Please do NOT copy database folder from previous version.
2. Please keep your wallet open if you're a validator; the network will resume when 2/3+ validators are upgraded.
https://github.com/semuxproject/semux/releases
Upgraded , works great!
Is there any particular reason behind having only 64 validators at max? Wouldn't the network be more stable with more?
Fewer validators would mean fewer propagation needed to reach concensus(2/3). This is not yet final since we will all base it on the results of the RC tests.
Rc2 currently appears to be running relatively stable, and the concurrency of 5000txs is not a small number. Since it can be successfully passed, it is proved that this scheme is feasible.At least for now, few projects can do that.
Yes we are happy that the network is able to handle 5000tx per block. Ultimately we want to be able to handle more than that and this can be achieved once we have more upscale validators.
Let me get this straight please.
Basically if the wallet was working without crashing during stress test than my vps configuration is sufficient?
Based on my experience, V with 2cpu, 4GB and 100M is sufficient to handle 5000 tx per block. But maybe not enough for 10000 tx.
Rc2 currently appears to be running relatively stable, and the concurrency of 5000txs is not a small number. Since it can be successfully passed, it is proved that this scheme is feasible.At least for now, few projects can do that.
Yes we are happy that the network is able to handle 5000tx per block. Ultimately we want to be able to handle more than that and this can be achieved once we have more upscale validators.
Let me get this straight please.
Basically if the wallet was working without crashing during stress test than my vps configuration is sufficient?
Rc2 currently appears to be running relatively stable, and the concurrency of 5000txs is not a small number. Since it can be successfully passed, it is proved that this scheme is feasible.At least for now, few projects can do that.
Yes we are happy that the network is able to handle 5000tx per block. Ultimately we want to be able to handle more than that and this can be achieved once we have more upscale validators.
Is there any particular reason behind having only 64 validators at max? Wouldn't the network be more stable with more?
Rc2 currently appears to be running relatively stable, and the concurrency of 5000txs is not a small number. Since it can be successfully passed, it is proved that this scheme is feasible.At least for now, few projects can do that.
Yes we are happy that the network is able to handle 5000tx per block. Ultimately we want to be able to handle more than that and this can be achieved once we have more upscale validators.
Rc2 currently appears to be running relatively stable, and the concurrency of 5000txs is not a small number. Since it can be successfully passed, it is proved that this scheme is feasible.At least for now, few projects can do that.
I was surprised that RC-1 has already been updated! It's amazing how things are advancing in Semux! 
the development of Semux is really surprise ,the movement is running smoothly.
I was surprised that RC-1 has already been updated! It's amazing how things are advancing in Semux!
How are validators forced to allocate resources for semux? now even if they are down, validator status only depends on votes.
Any new performance metric planned for next release?
Any new performance metric planned for next release?
If validators are down, they wont be forging any blocks, missing the rewards. We are looking for other ways to provide incentive in running a stable validators. For now we are focusing on RC tests to ensure we get a more stable network.
A little bit explanation of recent stress test:
1. We're flooding the network with large scale of transactions (if we don't do this, hackers will do it eventually).
2. The current block limit is 5,000 txs per block. Validator nodes will the following minimum configuration should be capable of dealing this load, based on our experiments.
Common errors:
1. "Unable to retrieve your IP address"
We're using https://www.ipify.org/ to get your IP; if this proves to be not stable, we'll choose another API in next release.
2. "BAD_PROTOCOL"
This is because the peer you're connecting to is using an incompatible P2P protocol; please ignore it if you're using RC.2
3. "INVALID_HANDSHAKE"
This means the other peer failed to validate your handshake message, either signature or timestamp or IP is incorrect.
4. "BAD_PEER"
The network only allows one connection per IP; they refuse any further connections.
5. "DUPLICATE_PEER_ID"
This means your account is being used in another wallet instance.
1. We're flooding the network with large scale of transactions (if we don't do this, hackers will do it eventually).
2. The current block limit is 5,000 txs per block. Validator nodes will the following minimum configuration should be capable of dealing this load, based on our experiments.
Quote
8GB Memory
Dual Core CPU
100 Mbps Bandwidth
3. We will continue this task until the network can survive.Dual Core CPU
100 Mbps Bandwidth
Common errors:
1. "Unable to retrieve your IP address"
We're using https://www.ipify.org/ to get your IP; if this proves to be not stable, we'll choose another API in next release.
2. "BAD_PROTOCOL"
This is because the peer you're connecting to is using an incompatible P2P protocol; please ignore it if you're using RC.2
3. "INVALID_HANDSHAKE"
This means the other peer failed to validate your handshake message, either signature or timestamp or IP is incorrect.
4. "BAD_PEER"
The network only allows one connection per IP; they refuse any further connections.
5. "DUPLICATE_PEER_ID"
This means your account is being used in another wallet instance.
roger that,keep your hard work dev ,i always support semux , i think type this common errors in OP is better. like Q&A
Before SEM, XEL was the last exciting and interesting project to participate! Now SEM has taken this place. 
yes ,i know xel project ,it is really a great project, but i think sem will be better then xel ,there is no donation for semux ,but xel have.
Jump to: