To prevent communication with non-Hallmarked nodes, the first thing we need to verify the peer whether it is hallmarked. So how to verify it? I'm confused.
- simple. First time verify the IP. If it is not hallmarked, you put it in your black list. Thats all. |
|
|
|
Aren't zombie scripts a temporary problem anyway until the network grows? Once healthy nodes outnumber zombie nodes, there won't be this problem.
- of course it is constatn problem, becouse zombie is very cheap to attacker. Only need to put hallmarks make zombies much much pricie to attacker.
Come-from-beyond said earlier that zombie nodes are easy to identify. Could the server attempt to validate the node on connection before it requested data and if the validation failed it would try another peer?
- it is easy only now. The attacker will quickly modify his zombies. It is like viruses. |
|
|
|
Периодическое выкладывание файла с блокчейном - нормальная практика, если файл подписанный. Хотя бы в целях дебага или истории.  - CfB, может пока не поздно запрограммировать чекпойнты ? Что-то мне подсказывает, что PoS алгоритм сейчас у BCNext-а плохонький (т.к. сейчас плодится масса форков блокчейна, т.е. майнящие ноды сейчас неверно определяют вес чейна, в который нужно положить вновь созданный блок), и атакующий скоро просто будет генерить нужную ему цепь, и всех заставлять переходить на неё. Вот тут и нужен будет чекпойнт. |
|
|
|
I think the best is to mark nodes and let peers to decide if they prioritize hallmarked nodes.
- it is useles unless you manadge to find a way for Hallmarket nodes to prevent communication with non-Hallmarket nodes. |
|
|
|
Completely remove hallmarks may be practical.
- 1000. Hallmark is the only way to distinguish zombie scripts. |
|
|
|
- please do not delude yourself. We are constantly stuck with a much lower depth then 720 blocks.
Alice on block 23577 of longest chain, Bob on block 23400 on a shorter chain. How do u know where the fork has happened? It may happen 2000 blocks ago and Bob won't be able to jump to a legit chain without redownloading the whole blockchain. - in other words, currently the node can not find the longest chain. Despite your previous statement (lets network to find longest chain). |
|
|
|
Well, hallmarks would work if everyone used them. Wait for a few hours and I'll release a version with disabled hallmarks.
- what?? May be you should release a hallmarks-only version ?? I do not whant to see a zombies in me Active peers window. I want to see (and communicate) only with hallmarked peers. New users just should use the other server to obtain some NXT to setup their own hallmarked node, or to continue use of public servers. |
|
|
|
I think having the network reliant upon VPS provided by benefactors is a bad idea. Nxt will then be centralized because it will depend on the people paying for VPS and the VPS providers. Both of these can be taken down.
- agree 100% |
|
|
|
расово верного блокчейна только CfB выкладывает.
- нет, теперь другая мода (точнее, возвращение старой) - удалять блокчейн, и заново его загружать, в надежде, что загрузится правильная ветка блокчейна. Раньше CfB запрещал удалять блокчейн, но теперь он, видимо, надеется, что люди наделали VPS-ов много, где-нибудь да заваляется ... В целом VPS-ы это зло, это способ отсрочить большие проблемы. Потому, что если сеть не будет работать с обычными юзерами, то когда энтузиазм VPS-строителей поутихнет (и многие позакрываются), но популярность Nxt вырастет, сеть в некий момент просто станет, т.к. количество форков блокчейна будет огромным, а сейчас софт просто не умеет находить правильный форк. Софт просто замирает на каком-то форке навсегда. Опять же огромный прокол с Халлмарками. Очень многие их установили, но они оказались вообще не задействаванными в защите от зомби. Но зато притягивающими на себя атаку зомби. То есть сейчас злоумышленник просто переиграл BCNext-а. Причём очень красиво переиграл - его же якобы контр-оружием (халлмарками). Но ничего, всё что нас не убивает - делает сильнее. Требования установки VPS в 2-4-8 Гб ОЗУ - просто безумные. Для линукса и 512МБ - это огромная память (да ещё в наши начальные времена малого блокчейна). Если текущий софт в нём не может работать, то и 8Гб не помогут. |
|
|
|
.. hallmarking nodes is just a bad idea in my opinion. Instead of using hallmarked nodes to stay in sync, nodes should simply use other nodes with the lowest ping time.
- namely, zombie. If the zombie node has the blockchain, does it matter? - of course they have not, they just a very small scripts. Once a node makes a request and doesn't get a response in 'x' time, it then needs to try another node until it receives a response. It should try nodes in increasing ping time order. - didn't you see in your Active peers window 300 zombies, and only 1-2 healthy nodes? What the odds your node find the healthy? |
|
|
|
Why does it not correct itself ? I thought when I collide with a peer with longer blockchain, I would correct my blockchain to the longer one ? Why it it not the case here ?
There is a limit of max blockchain reorg depth. Sometimes manual work is required (blockchain deleting). - please do not delude yourself. We are constantly stuck with a much lower depth then 720 blocks. |
|
|
|
.. hallmarking nodes is just a bad idea in my opinion. Instead of using hallmarked nodes to stay in sync, nodes should simply use other nodes with the lowest ping time.
- namely, zombie. If the zombie node has the blockchain, does it matter? - of course they have not, they just a very small scripts. |
|
|
|
.. hallmarking nodes is just a bad idea in my opinion. Instead of using hallmarked nodes to stay in sync, nodes should simply use other nodes with the lowest ping time.
- namely, zombie. |
|
|
|
I don't remember if this question came up before:
If I have 200 nxt, 100 forging, another 100 maturing...
- it is not possible. If 100 NXT forging, all coming NXT starts to forge immediately. |
|
|
|
отсыпьте монеток ... Подкиньте, .. - подсыпал :-)) |
|
|
|
No thanks... another scamcoin?
- thanks. Bye, then. Or, better, farewell. |
|
|
|
... and shortly after that - gets Killed: [2013-12-23 17:02:41.420] "blacklistingPeriod" = "300"
[2013-12-23 17:02:41.420] "wakeKharon" = "false"
[2013-12-23 17:02:41.421] "logPeerCommunication" = "false"
[2013-12-23 17:02:41.421] Loading transactions...
[2013-12-23 17:02:43.369] ...Done
[2013-12-23 17:02:43.370] Loading blocks...
[2013-12-23 17:02:46.165] ...Done
[2013-12-23 17:02:46.166] Scanning blockchain...
[2013-12-23 17:02:50.563] ...Done
2013-12-23 17:02:50.595:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppContext@6e7bdb1c{/,file :/root/nxt/webapps/root/,AVAILABLE}{/root}
2013-12-23 17:02:50.679:INFO:oejs.ServerConnector:main: Started ServerConnector@27c3aecb{HTTP/1.1}{0. 0.0.0:7874}
2013-12-23 17:02:52.296:INFO:oejs.ServerConnector:main: Started ServerConnector@4ffddfc4{SSL-http/1.1 }{0.0.0.0:7875}
2013-12-23 17:03:34.183:WARN:oejh.HttpParser:qtp1313211444-63: badMessage: java.lang.IllegalStateException: too much data after closed for HttpChannelOverHttp@5bc2832e{r=5,a=IDLE,uri=-}
Killed
|
|
|
|
my 0.4.0 VPS constantly gets bad Messages shortly after the launch of the java: [2013-12-23 17:00:25.132] "logPeerCommunication" = "false"
[2013-12-23 17:00:25.132] Loading transactions...
[2013-12-23 17:00:26.260] ...Done
[2013-12-23 17:00:26.261] Loading blocks...
[2013-12-23 17:00:27.504] ...Done
[2013-12-23 17:00:27.504] Scanning blockchain...
[2013-12-23 17:00:29.568] ...Done
2013-12-23 17:00:29.588:INFO:oejsh.ContextHandler:main: Started o.e.j.w.WebAppCo ntext@363affc0{/,file:/root/nxt/webapps/root/,AVAILABLE}{/root}
2013-12-23 17:00:29.622:INFO:oejs.ServerConnector:main: Started ServerConnector@ 5de422ef{HTTP/1.1}{0.0.0.0:7874}
2013-12-23 17:00:30.234:INFO:oejs.ServerConnector:main: Started ServerConnector@ 1d305c92{SSL-http/1.1}{0.0.0.0:7875}
2013-12-23 17:02:12.982:WARN:oejh.HttpParser:qtp197871000-14: badMessage: java.l ang.IllegalStateException: too much data after closed for HttpChannelOverHttp@26 57ea6a{r=3,a=IDLE,uri=-}
2013-12-23 17:02:25.698:WARN:oejh.HttpParser:qtp197871000-34: badMessage: java.l ang.IllegalStateException: too much data after closed for HttpChannelOverHttp@50 57f334{r=1,a=IDLE,uri=-}
2013-12-23 17:02:25.883:WARN:oejh.HttpParser:qtp197871000-13: badMessage: java.l ang.IllegalStateException: too much data after closed for HttpChannelOverHttp@3e 200421{r=1,a=IDLE,uri=-}
2013-12-23 17:04:02.646:WARN:oejh.HttpParser:qtp197871000-34: badMessage: java.lang.IllegalStateException: too much data after closed for HttpChannelOverHttp@64898d3d{r=1,a=IDLE,uri=-}
|
|
|
|
how I can configure my server in order to communicate only with Hallmarked nodes (> 100 000 weight) ?
U can't atm. - it is very sad. And it is after the setting of the Hallmarks by many stakeholders, which means disclosure of theirs IPs and stacks .. placement under the risk, in other words. |
|
|
|
|
Show Posts
