Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make dust spam unspendable #498

Open
indolering opened this issue Jul 17, 2014 · 13 comments
Open

Make dust spam unspendable #498

indolering opened this issue Jul 17, 2014 · 13 comments

Comments

@indolering
Copy link

Removing all 1 Satoshi outputs before block 50k would remove the majority of the dust-spam from the system.

@domob1812
Copy link

Yes. This is my next project, and maybe I can submit a patch "really soon". ;) We can then discuss the details (if my selection of excluded outputs is ok, when to softfork, and all that).

@domob1812
Copy link

See namecoin/namecoin-legacy#140.

@indolering
Copy link
Author

Well, then just close this.

@indolering
Copy link
Author

Or not because Bounty Source won't do a bounty on a PR.

@phelixbtc
Copy link

@indolering Are the Bounty Source issues resolved? I would like to close this issue.

@JeremyRand
Copy link
Member

@phelixbtc This should not be closed until the softfork is merged. (As far as I know it is not merged yet.)

@indolering
Copy link
Author

@JeremyRand There is a standing PR for this issue. Shouldn't we close this and move discussion there?

@phelixbtc Yes, the bounties were paid via the forum and we no longer need this as a placeholder.

@phelixbtc
Copy link

Closing as of Indolering's post.

@JeremyRand
Copy link
Member

@phelixbtc @indolering It is my opinion that issues should not be closed until they are resolved in the master branch. This is consistent with standard policy for open-source projects, and also is standard policy for BountySource. BountySource allows bounties to be claimed as soon as an issue is closed, and if end users find that the issue is not fixed in master, they may choose to dispute the bounty, which is bad for everyone. As such, I'm re-opening this issue until the PR is merged. Furthermore, the PR is not in a mergeable state right now; the block depth has not been decided yet. That should be discussed in this thread, and closing the issue makes that more difficult. If there are objections, please give me time to respond -- the issue was closed only 10 hours after @indolering suggested doing so; I was not given adequate time to respond. Thanks.

@phelixbtc
Copy link

@JeremyRand Sorry for closing it so quick. IMHO the PR has "replaced" this issue. That's not strictly correct but I am confident that we will resolve the issue via the PR. The only reason for closing this issue was to keep the issue list lean and mean. If you prefer to keep the issue open it's fine with me.
Edit: To explain: I had thought you had missed the PR.

@indolering
Copy link
Author

@JeremyRand there are no standing bounties at BountySource for this issue, the bounty was directly to Domob in a private exchange.

Sorry for being too hasty about suggesting to close it, I meant to defer to Jeremy.

@JeremyRand
Copy link
Member

@domob1812 Can we roll the proposed fix (remove all 1-swartz outputs created between block heights 39k and 41k from the UTXO set) into the Taproot softfork event? Cyphrs is interested in this (they want to decrease the storage requirements of running a pruned node), and may be able to fund the work if needed.

@JeremyRand JeremyRand transferred this issue from namecoin/namecoin-legacy Mar 25, 2022
@domob1812
Copy link

What would this actually entail? Just adding a rule to disallow spending those outputs is relatively easy of course. But if we want to reduce storage for a pruned node, we need to a) actually remove all of them from the UTXO set, and b) somehow do so already while syncing (not only at the fork block).

Of course that's still very possible to develop, but would be a lot more effort. Do we know what practical effect that would have in terms of reduced requirements? What new usecases would that enable?

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

No branches or pull requests

4 participants