Topic: [ANN][SEM] Semux - Official Thread - page 380. (Read 694145 times)
What an interesting project, I have been reading about it now and feel it will be something interesting
How to join a signature company
the signature campagne is over, second airdrop is for BTC holders
How to join a signature company
When the second airdrop will start?
if someone need
semux database (rc2)
16/NOV/2017 7.44 (europa time)
semux database (rc2)
16/NOV/2017 7.44 (europa time)
Please don't use blockchain downloaded from archive. It's extremely unsecure because it can be already modified.
man trust it's not modified.... i don't have the know/how for modify a blockchain...
sometimes my computer freeze and i need to download intere blockchain so i think this thing it could happen to someone else and i make this zip database
if someone need
semux database (rc2)
16/NOV/2017 7.44 (europa time)
semux database (rc2)
16/NOV/2017 7.44 (europa time)
Please don't use blockchain downloaded from archive. It's extremely unsecure because it can be already modified.
Write who wants to sell no higher than 4000sat, Depends on the quantity. Unlimited number sem
When the second airdrop will begin？after the test of 5000txs, the network is now stable, which is a major test, and the number of concurrent Numbers is the bottleneck of the blockchain.
do we earn anything by voting?
You can earn coins by voting for pools.
do we earn anything by voting?
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.
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? Eventually, there will be only private communication between the validators at the core (validator can distinguish if a connection is from a validator or not). Each validator only allows connections from a small number of trusted backbone nodes, which are open to any regular nodes. This network architecture is scalable and robust to ddos attack.
It takes time and money for people to build this infrastructure, but we will get there as the eco system evolves.
P.S. The current kernel implementation can already handle transaction flooding. The only reason that the network got stuck last time is because some validator nodes are not qualified. We're considering slashing mechanism
Oh, something interesting in fairy crypto world. 
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.
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.
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...
This Project Rocks!
Waiting for the VM to bei powered up
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?
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?
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..
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.
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?
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.
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.
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? Jump to: