Seems that there was a temporary issue for all users lasted about 4 hours, finally fixed by now. Usually I get E-Mails from them within a minute.

Seems that kucoin stopped sending any E-Mail to any address (tried three different services) around 09:00 UTC. Does anybody know, is there a way to withdraw funds from there without receiving an E-Mail?

Does anybody know how to send transaction after the hard fork? I always get an error like in this issue: https://github.com/monero-project/monero/issues/3581

Seems that fairpool finds significantly less number of blocks it should find if its reported hash rate is right. Moreover, most of blocks are being found by some unknown pool (hashvault/fairpool/official pools did not find any block in range 116616..116621, for example).

It's because of 4 Mb buffer instead of 2 Mb, number of threads should be decreased 2 times. Welcome to the GPU mining era!

Падения вроде поправил указанием на втором сервере первого в add-priority-node. Отставание блокчейна не могу решить, не знаю, где брать последние блоки. На официальном pool.karbowanec.com такое же отставание, а у sberex не знаю адрес p2p, коннектится только к wallet. Немного страшно майнить в такой ситуации.

EDIT: Сорри, туплю. На sberex просто depth requirement 6. Видимо, уже всё хорошо, просто если падает, то надо что-то разумное указать в priority node. Например, адрес pool.karbowanec.com помогает.

Это бинарник. Старый.
Я собираю из исходников, коммит 05acb5419db2d666e81081b9ea0fe804f1ce3752, по идее там вошёл этот фикс?
Один из серверов падать перестал, но отстаёт на несколько блоков от sberex (текущая высота 216011). Состояние коннектов нормальное.
Другой никак не может уйти за 216003, всё время падает.
Интересно, что blockchain explorer со sberex тоже не находятся в синхронизации явно. И бедблок на сберексе настораживает.

Иногда ошибка другая, с трейсом. Может, это как-то поможет:
*** Error in `./karbowanecd': corrupted size vs. prev_size: 0x000000001f66fab0 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x777e5)[0x7f26389fc7e5]
/lib/x86_64-linux-gnu/libc.so.6(+0x80dfb)[0x7f2638a05dfb]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x4c)[0x7f2638a0953c]
./karbowanecd(_ZNSt6vectorIN10CryptoNote10Blockchain16TransactionEntryESaIS2_EED1Ev+0x102)[0x48c072]
./karbowanecd(_ZN13SwappedVectorIN10CryptoNote10Blockchain10BlockEntryEE7prepareEm+0x603)[0x48ea93]
./karbowanecd(_ZN13SwappedVectorIN10CryptoNote10Blockchain10BlockEntryEEixEm+0x47f)[0x48ef8f]
./karbowanecd(_ZN10CryptoNote10Blockchain14check_tx_inputERKNS_8KeyInputERKN6Crypto4HashERKSt 6vectorINS4_9SignatureESaIS9_EEPj+0x2ef)[0x4e4ebf]
./karbowanecd(_ZN10CryptoNote10Blockchain22checkTransactionInputsERKNS_11TransactionERKN6Cryp to4HashEPj+0xc0)[0x4e5800]
./karbowanecd(_ZN10CryptoNote10Blockchain22checkTransactionInputsERKNS_11TransactionERjRN6Cry pto4HashEPNS_9BlockInfoE+0xbc)[0x4e5bec]
./karbowanecd(_ZN10CryptoNote10Blockchain22checkTransactionInputsERKNS_11TransactionERNS_9Blo ckInfoES5_+0xb5)[0x4e5de5]
./karbowanecd(_ZNK10CryptoNote14tx_memory_pool14get_differenceERKSt6vectorIN6Crypto4HashESaIS 3_EERS5_S8_+0x179)[0x4c86a9]
./karbowanecd(_ZN10CryptoNote4core14getPoolChangesERKSt6vectorIN6Crypto4HashESaIS3_EERS1_INS_ 11TransactionESaIS8_EERS5_+0x60)[0x4a56c0]
./karbowanecd(_ZN10CryptoNote4core14getPoolChangesERKN6Crypto4HashERKSt6vectorIS2_SaIS2_EERS5 _INS_11TransactionESaISA_EERS7_+0x2e)[0x4a31be]
./karbowanecd(_ZN10CryptoNote4core18getPoolChangesLiteERKN6Crypto4HashERKSt6vectorIS2_SaIS2_E ERS5_INS_21TransactionPrefixInfoESaISA_EERS7_+0x50)[0x4a5c20]
./karbowanecd(_ZN10CryptoNote9RpcServer20onGetPoolChangesLiteERKNS_33COMMAND_RPC_GET_POOL_CHA NGES_LITE7requestERNS1_8responseE+0x47)[0x534ce7]
./karbowanecd[0x5382f0]
./karbowanecd(_ZN10CryptoNote9RpcServer14processRequestERKNS_11HttpRequestERNS_12HttpResponse E+0x1e2)[0x53ce02]
./karbowanecd(_ZN10CryptoNote10HttpServer10acceptLoopEv+0x63d)[0x532bdd]
./karbowanecd(_ZN6System10Dispatcher16contextProcedureEPv+0x8a)[0x5589fa]
./karbowanecd(_ZN6System10Dispatcher8getTimerEv+0x0)[0x558bd0]

Похоже, после наступления блока 216000 демон (по крайней мере, собранный из исходников) стал падать каждые полминуты с ошибкой Segmentation fault. Надеюсь, разработчики сумеют это быстро поправить.

Seems that kucoin stopped received ETN deposits about 07:30 UTC, or it's just for me? Send a bit of transactions during last 24 hours, only the ones before that time are shown. They're shown in blockchain but not on kucoin. Any other exchange for ETN?

UPD: seems that they fixed the issue about 15:00 UTC. Is it typical for kucoin?

Seems that miner.rocks that supported the longer part of blockchain is shut down now.
So dero.live is the only left? It is the winner?
It will be very sad because my money is on the other side...

If so, the higher cumulative difficulty is the chain of your pool because official pool was alone most of time. But why don't developers just stop that chain competition by shutting down the official pool as they did before? Or it is supported by some other people? Seems that pools from both sides already started to send their payments (more than 60 blocks gone), won't it be much harder to recover now?

Seems that somebody added some hash power to the "pool.dero.live" blockchain during last 20 minutes and now it has nearly the same length and difficulty with the other one. What now?

dero.miner.rocks is on a longer chain. stocks.exchange seems to be also there. It's very like the same that was happened yesterday - pool.dero.live is building its own blockchain regardless of others. May be it's because of its heavy load?

Seems that they forked due to an alternative at 40770.
Unfortunately, the dero daemon handles alternatives very strangely, sometimes it enters in a loop with exception cryptonote::BLOCK_DNE instead of choosing the correct block chain.

Sorry to say that, but again seems that the network is quite synchronized except the priority nodes - all of them stuck on 40785 (official blockchain is 40793). May be they can't handle the large number of connections? The same happened with pool.dero.live.

Can I just throw a hypothesis? I'm not sure that it is true because I'm very new to the cryptocurrency world, but at least an idea.
Seems that using --add-priority-node decreases diversity the network and creates heavy load on these priority nodes added by a lot of participants, so they could not handle the large traffic.
Is it possible that the network is better without any priority nodes?
May the problems had been arisen (or the things got worse) when the first bunch of priority nodes appeared?
How other networks based on monero (e.g. sumo, etn) do exist without any priority nodes and with a quite number of alternatives according to daemons' logs?

P.S. Sorry for writing this early morning but seems we're in completely different time zones.

It's not my local problem, there is no need to delete my base.
It's remote problem on these nodes.
The rest of network including my daemon are ok.
Now 45.77.89.64 seems also ok, so there are 3 stuck nodes of those 6.

Sorry but seems that did not help. sync_info command in daemon shows now most of these nodes (except two - 108.61.220.229 and 207.148.5.250) are simultaneously out of the blockchain. Seems that alternative at 40646 did the damage Regardless of that, the rest of network is probably synchronized.

According to the speed of finding blocks and corresponding difficulty, seems that the remaining part of the network is about one half of the official one (where pool.dero.live is), may be slightly more (400-500k difficulty against 700-800k). I could not find the other pools supporting that side of the network, may be they are private miners or something like that.