SWIP-44: eligibility for sampling and game participation during reserve-expanding pull-sync #92
SWIP-44: eligibility for sampling and game participation during reserve-expanding pull-sync #92significance wants to merge 3 commits intomasterfrom
Conversation
zelig
left a comment
zelig
left a comment
There was a problem hiding this comment.
jaw-dropping accuracy, cannot find a problem with this SWIP
zelig
changed the title
zelig
changed the title
zelig
changed the title
zelig
added
improvement
| interval during which the node computes its reserve sample for the current | ||
| redistribution round. | ||
|
|
||
| **Algorithm 3 (Sync Suspension Protocol).** On entry to the sampling window: |
There was a problem hiding this comment.
while there are still a lot of details for me to digest with this proposal, this part for me is particularly alarming. getting sync to work well is hard enough; why do we want to introduce an architectural change that basically goes against every common sense of having a reasonable UX? do we see ethereum preventing you from submitting a transaction while a block is mined?
i really don't think that continuously turning syncing on and off is a good idea, not at all. also, how do you prevent pushsync chunks from coming in during this time-window? from my perspective all of these considerations must be handled on the persistence abstraction level, not on the protocol level.
3 participants
No description provided.