carllin

> However I was thinking, it's not necessary to change the structure, just interpret the "confirmation_count" field differently. It's 32 bits which is way overkill for counting confirmation counts up...

@AshwinSekar that's only in the VoteStateUpdate, I think this proposal was to modify the confirmation counts in the `VoteState` itself to track the latency

> In https://github.com/solana-labs/solana/pull/23257, assuming one packet has one transaction, packets with same fee-per-cu are put into same bucket, keeping the same order of stake weighted shuffle. So if two transactions...

> the bucket is by writable-account. Hmmm, does this mean every account that tries to grab a write lock on `A` will fall into the same bucket? What if transactions...

> Right now, if (AB, 1000) is included in a block, it will be counted into both A and B buckets. So both A and B buckets will increase by...

> 1. Bucket by write lock is to gate TXs not to exceed max_account_limit. (A minor correction is `AB` will be in `bucket 2` as well, as it will also...

> Hmm, isn't this why we have block-limit and account-limit to help such scenario? Plus allowing additional-fee to give AB better chance? Based on my understanding thus far, it doesn't...

@behzadnouri do you have any input on this? This seems like a variation of the job-shop scheduling problem with `n` tasks and `m` machines, where: 1. We have an estimate...

hmm so something in `handle_votable_bank` is taking a long time, thus delaying their slot which in turn races with the blocks produced by future leaders? `handle_votable_bank` seems pretty tame on...

Having a dedicated thread that produces the leader block also does make sense. It can just receive the latest reset information from before `handle_votable_bank`. I remember discussing some nasty traps...