Change Details

There is currently no case where polling an item more than once is desirable. This patch limits the polling for all types, not just invalidated blocks. Rationale on the filter size: Using BTC as a proxy, block propagation for 90 percentile has been under 12 seconds for the last few years: https://www.dsn.kastel.kit.edu/bitcoin/#propagation Assuming each round of polling finalizes in ~3 seconds, we assume 15 seconds is a window of time we can be reasonably sure a <1MB block will finalize across the network. It is desirable to not allow repolling of recently finalized blocks (see D13207), so it is essential that this 15 second window be covered by the filter and not allow the block to roll out of it prematurely. 20 polling cycles should take ~60 seconds so this should be sufficient even if you tweak assumptions, such as: * eCash can have larger blocks and therefore slower block propagation time. * The eCash network is smaller than BTC and may have less optimal paths that impact 90 percentile propagation time. Depends on D13207

There is currently no case where polling a finalized item more than once is desirable. This patch limits the polling for all finalized types, not just invalidated blocks. Invalidated items of types other than blocks are not tracked due to transient factors (for example, immature proofs may be invalidated but once mature they can be finalized). And future changes to voting policies on non-block items makes this challenging to navigate. However we can be sure that once a block is invalidated we don't care about descendants. We will not reorg to an invalidated chain. Rationale on the filter size: Using BTC as a proxy, block propagation for 90 percentile has been under 12 seconds for the last few years: https://www.dsn.kastel.kit.edu/bitcoin/#propagation Assuming each round of polling finalizes in ~3 seconds, we assume 15 seconds is a window of time we can be reasonably sure a <1MB block will finalize across the network. It is desirable to not allow repolling of recently finalized blocks (see D13207), so it is essential that this 15 second window be covered by the filter and not allow the block to roll out of it prematurely. 20 polling cycles should take ~60 seconds so this should be sufficient even if you tweak assumptions, such as: * eCash can have larger blocks and therefore slower block propagation time. * The eCash network is smaller than BTC and may have less optimal paths that impact 90 percentile propagation time. Depends on D13207

There is currently no case where polling ana finalized item more than once is desirable. This patch limits the polling for all types,finalized types, not just invalidated blocks. Invalidated items of types other than blocks are not tracked due to transient factors (for example, immature proofs may be invalidated but once mature they can be finalized). And future changes to voting policies on non-block items makes this challenging to navigate. However we can be sure that once a block is invalidated we don't care about descendants. We will not just reorg to an invalidated blockschain. Rationale on the filter size: Using BTC as a proxy, block propagation for 90 percentile has been under 12 seconds for the last few years: https://www.dsn.kastel.kit.edu/bitcoin/#propagation Assuming each round of polling finalizes in ~3 seconds, we assume 15 seconds is a window of time we can be reasonably sure a <1MB block will finalize across the network. It is desirable to not allow repolling of recently finalized blocks (see D13207), so it is essential that this 15 second window be covered by the filter and not allow the block to roll out of it prematurely. 20 polling cycles should take ~60 seconds so this should be sufficient even if you tweak assumptions, such as: * eCash can have larger blocks and therefore slower block propagation time. * The eCash network is smaller than BTC and may have less optimal paths that impact 90 percentile propagation time. Depends on D13207