Skip to content

Conversation

@tobtoht
Copy link
Collaborator

@tobtoht tobtoht commented Mar 3, 2023

Copy link
Contributor

@UkoeHB UkoeHB left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I did not check if everything related to blackballing was removed, if anything was missed it can be cleaned up in a future PR.

Copy link
Contributor

@jeffro256 jeffro256 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not approving the changes in principle yet, but this PR does successfully remove only blackball features and should not affect the behavior of anything else.

@tobtoht
Copy link
Collaborator Author

tobtoht commented May 15, 2023

Rebased.

@jeffro256
Copy link
Contributor

I believe we should keep the output blackballing feature as long as there still exists the possibility of poisoned outputs (e.g. Mordinals). If/when full-chain membership proofs get merged into mainnet, then it would be safe to remove blackballing entirely.

@tobtoht
Copy link
Collaborator Author

tobtoht commented Jul 11, 2023

I disagree. The current blackballing implementation is not helpful at mitigating effective ringsize reduction from large amounts of non-uniform outputs (such as Mordinals - which was mitigated), as it would require manually generating and importing up-to-date blacklists before sending a transaction. (About half of selected decoys are < 1 day old, so at least daily). Transactions that do not include these outputs in their rings are finger-printable on chain, reducing transaction uniformity and increasing traceability for the small subset of users that would go through the effort.

A better solution for output blackballing would be to implement it on the daemon side and have it mark undesirable outputs in the get_outs call. This would not require storing blackballed outputs in RingDB. In this way, all users would benefit and transaction uniformity is not harmed.

@tobtoht tobtoht added this to the fcmp++ hf milestone Feb 27, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants