Gil Danziger

Ok it's more that it's changing the approach to the issue from - "it's not working we need to fix it" to "that's the current Bitcoin Core behaviour, let's understand...

aka "Improved proposal randomness" - we definitely wanna handle this issue. @amiller wrote about it and should assist in design/implementation

When you say you expect the finalizer to vote in a certain way (after the checkpoint) is it from security perspective or because that's how you assume the client should...

There's quite an extensive thread about the topic here (mostly encoding / security considerations): https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014935.html

regardless of the specific data we decide to store and how efficient it's gonna be. with frequent blocks (e.g 16 seconds) and the need for new clients to validate the...

This item was mostly added back then as a concern for the data transfer costs / chatty protocol. Since then we identified the downloading blocks and the initial sync as...

> If we tackle this I think it might sense to do it along/after #61 and any way it should be backported to bitcoin. If we plan to merge with...

Yeah definitely a good point, but as @Gnappuraz mentioned - not relaying blocks created with a duplicate stake (a stake transaction which was seen before by the node) sounds good...

> > Particl punishes nodes detected to be staking the same coins by delaying their blocks > > This ticket was never about disconnecting nodes. This part can affect nodes...

The need totally makes sense, solution wise maybe it would be useful to have a generic dataset persisted and read from disk on startup and can be easily extended with...