Parth
> We kind of already have it though: https://github.com/subspace/subspace/tree/main/crates/sp-lightclient My bad. For bidirectional bridge SubspaceEthereum, this light client need to be implemented in Solidity + We also need to check...
> hi [@ParthDesai](https://github.com/ParthDesai) if I provided a v7.0.1 branch that included the patch would you be able to build from source? Sure. That would probably work. But, Can I ask...
@vedhavyas The main problem I believe is reward distribution to different nominators than the ones who were staked during the production of the block. The solution, I came up with...
@NingLin-P @dariolina Please correct me if I wrong, but I do not see the inconsistency here. When a nominator requests to withdraw `N` amount of shares, its value in terms...
@NingLin-P I went back and read the code once more. Just for my understanding the first case where the reward gets diluted happens because we calculate the share price for...
> @ParthDesai it's easy to see if you imagine the nominator withdraws all shares at epoch `n`. The rewards that count into the share price at epoch `n` are the...
@NingLin-P My thoughts on this matter and solution outline is as follows: At the moment, we use block confirmation to trigger epoch transition for non-confirmed blocks. This is confusing and...
> Currently, each nominator at most keeps 2 items for all its deposits: known for deposits that have converted into shares based on the share price and pending for deposits...
The confusion here arises because runtime code stored and runtime code being used to derive execution receipt for particular consensus block are different. I do not think there is any...
> > I believe the ideal approach would be to move the runtime code upgrade to the beginning of next block (i.e before any extrinsics are executed). > > I...