A Layer-3 (network-layer) blacklist risks cutting off innocent CGNAT and cloud users. What you’re proposing is similar to mechanisms that already exist (e.g., access control lists at the ISP level work by asking computer B which requests it wants to reject and rejecting those that originate from computer A). However, implementing any large-scale blocking effort beyond the endpoint (i.e. telling an unrelated computer C to blackhole all requests from computer A to computer B) would be too computationally expensive for a use case as wide and as precise as “every computer on the Internet”.

Also, in your post you mentioned, “A host would need to have a way to identify itself as authoritative, responsible for the IP address in question.” This already happens in the form of BGP though it doesn’t provide cryptographic proof of ownership unless additional mechanisms are in use (RPKI/ROA).

If I recall correctly, there were multiple posts in different communities.

The DKTB is a personal app. It is therefore assumed, that the User will not share it with other people, and that only the User can access and control their personal DKTB. Ultimately, this means that all attestations in a DKTB are expected to pertain to and only be presented by the same User. This is enforced by requiring the user to authenticate using biometry or PIN-code when using the app and only allowing the DKTB application to be installed on one device per user. (from the PDF)

This is a false assumption: PIN codes can be bypassed by sharing them with others. Devices can be faked unless using hardware attestation, which prohibits any modifications to the device which may be undertaken by those interested in rooting or installing a custom OS.

Users can initially acquire a DKTB on their smartphone or tablet via Google Play or the Apple App store. (from the PDF)

This method requires the use of a vanilla, unmodified device, effectively prohibiting modifications to devices that one might wish to alter.