dergoegge

Reorg problem of the BlockRequestAllowed approach

The previous approach in #24571 used BlockRequestAllowed to determine if a peer is allowed to know about stale headers in a node's block index. BlockRequestAllowed returns true if the block is on the main chain or if the block is younger (by time and PoW) than STALE_RELAY_AGE_LIMIT (~ 1 month).

The idea was: If a peer sends us headers that build on top of an old stale block (according to the logic in BlockRequestAllowed) we reject the new headers.

The problem with the one-month limit was that it would reject headers that connect to an old fork chain that is longer than 2000 (MAX_HEADERS_RESULTS) blocks.

Consider the following block index:

dergoegge

{ pkgs ? import <nixpkgs> {} }:

  let
    python-with-my-packages = pkgs.python38.withPackages (p: with p; [
      setuptools
      vulture
    ]);
  in

  (pkgs.mkShell.override { stdenv = pkgs.llvmPackages_14.stdenv; }) {

dergoegge

import matplotlib.pyplot as plt
import json

with open('mempool.json') as f:
    data = json.load(f)

widths = []
feerates = []
count = []

dergoegge

const { google } = require('googleapis');

const authClient = google.auth.fromJSON(require('./serviceAccount.json'))

const rules = google.firebaserules({
	version: "v1",
	auth: authClient
});

return rules.projects.rulesets.list({

dergoegge

const { google } = require('googleapis');

const rules = google.firebaserules("v1");

rules.projects.rulesets.list({
	auth: "<my-api-key>",
	name: 'projects/<my-project-name>',
}).then(res => console.log(res));