Make dust spam unspendable about namecoin-core

[domob1812]

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]

See namecoin/namecoin-legacy#140.

[indolering]

Well, then just close this.

[indolering]

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

[phelixbtc]

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

[JeremyRand]

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

[indolering]

@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]

Closing as of Indolering's post.

[JeremyRand]

@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]

@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]

@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]

@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.

[domob1812]

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?