-
Notifications
You must be signed in to change notification settings - Fork 456
Networks lose stability when broadcasting transactions #339
Comments
It seems some nodes stucked on other heights and forked. |
Can you provide debug logs for this issue? Theres nothing to go on from
this visual representation
…On Tue, Dec 6, 2016 at 1:31 PM, Unhandled Exception < ***@***.***> wrote:
It seems some nodes stucked on other heights and forked.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#339 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/APzFsAuY1LVb0GBrZWZtYSHN6dv2BCpFks5rFbf_gaJpZM4LFyxv>
.
|
I've not checked logs yet, but none of my nodes forked, there are few people on #mainnet, lisk.chat which experienced fork. |
This is most likely related to the fork 1/5 recovery mechanism which is not
functional correctly in 0.5.0 in that case.
…On Tue, Dec 6, 2016 at 1:41 PM, Unhandled Exception < ***@***.***> wrote:
I've not checked logs yet, but none of my nodes forked, there are few
peoples on #mainnet on lisk.chat which experienced fork.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#339 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/APzFsAzikvJPbwmutJc-BQIQHFjpbwzHks5rFbpcgaJpZM4LFyxv>
.
|
I think most problem is that network lost stability when ~100 transactions was made at one time. No need to debug it more, just need to analyse code responsible for that further and improve. Since forks occurred after stability has been lost. Forks should be avoided not only fixed temporary by recovering mechanism but i can agree that recovering mechanism is necessary as much. I've reported what i've noticed, hope it's helpful. For me it would be. |
The network is accepting fork forged blocks is most likely the root cause of nodes falling behind and staying behind, not transaction processing and broadcast. This has been proven time and again that accepting incorrect blocks the main issue we are having when it comes to nodes falling behind. |
Adding video from today test It clearly shows that propagation time increase badly when transactions are submitted, also some nodes get out of sync after that and needs some time to recover. it appears that network can be possibly killed for less than 10k LSK, 5$ VPS, and some effort. I wouldn't call Mainchain Stabilisation Milestone Finished |
@karek314 Comparatively speaking to previous releases the network is more stable. We have staged multiple tests on a network similar in size and had no problems with 1000s of transactions. I'm not sure what your intentions are by posting such a video, but from my point of view they are bad. Anyway, we will review the current situation and if there is a problem, we will resolve it. |
I can agree that is more stable, actually much more stable, but not stable enough yet - i wouldn't call it stable main chain. Video clearly shows propagation time issues. Why bad intentions ? This is not some unknown exploit, this is actually the simplest attack, currently incentive to attack Lisk network is very very small, there is no margin trading, lisk have nowhere to drop. It would be very hard to benefit from that. |
Not occurring in 1.0.0 version. |
I've noticed that shortly after my delegate sharing pool made withdraws, around ~100. Network lost stability, and it took few minutes for most of nodes to get back in sync.
Note: 3 last fields in table are incorrect temporary
The text was updated successfully, but these errors were encountered: