DropKick ⚽️ - A minimal commit/reveal PQ rescue protocol

The discussion in the recent email from the Bitcoin Development Mailing List highlights several key points regarding the implementation and security concerns of DropKick, a blockchain protocol feature. Firstly, the reveal delay parameter (d) is fixed at deployment and applies globally to all dropkick transactions. This parameter, along with the minimum fee rate (δ), is critical and currently non-adjustable post-deployment, which might limit flexibility according to specific user needs. Suggestions are welcomed on how to securely allow users to set their own block delay parameters to better suit individual use cases.

Furthermore, the role of aggregators in this system is simply to compile merkle trees of commitments and place them on-chain. They may also earn fees directly from users they assist. The security concerns discussed involve potential time-dilation and eclipse attacks. In time-dilation attacks, the attacker delays the victim's ability to publish a reveal by making blocks appear slower than usual. An eclipse attack allows attackers to censor a victim’s reveal transaction and proceed with their own commit/reveal spend without the victim’s awareness. This could mislead the user into believing their transaction has been successfully mined when it has not, thus providing attackers with a substantial advantage.

Additionally, the Lifeboat protocol variant seems to mitigate these risks effectively. It ensures that once a user's commitment is part of the chain, it cannot be overridden by subsequent commitments, thus preventing censorship attacks including those from eclipse attacks as long as there are no deep chain reorganizations.

Lastly, addressing potential vulnerabilities related to third parties inflating aggregator fees or manipulating proofs was mentioned. Specific design choices, such as placing commitments outside the witness segment in transaction structures like OP_RETURN or using P2TR public key tweaks, are suggested to enhance security. Moreover, there is a need for robust anti-DoS measures to prevent misuse in proof handling and commitment manipulation.

This overview underscores the importance of flexible yet secure blockchain protocol design to accommodate diverse user requirements while safeguarding against various types of security threats.