Update ergoplatform/ergo#1905 submission — awaiting review (PR #2453)

[beejaygee]

Updates the existing reservation for ergoplatform/ergo#1905 (originally #43, closed as stale/duplicate against #48 while work was paused) to awaiting-review, linking the completed fix: ergoplatform/ergo#2453.

Timeline for reviewers: this bounty was reserved 2026-07-16 (#43) with root-cause analysis posted same day on the issue. Work paused pending clarification of the ergo repo's agent-facing AGENTS.md test-only restriction, during which #48 (Ergologica) independently reached the same fix and opened ergo#2451. #2453 completes the originally reserved work; leaving it to maintainers to sort out precedence between the two upstream PRs.

[github-actions]

Submission triage

• Update ergoplatform/ergo#1905 submission — awaiting review (PR #2453) #52 needs attention: Update /wallet/payment/send is trying to spend custom scan boxes ergoplatform/ergo#1905 submission — awaiting review (PR #2453)
  • submissions/beejaygee-ergo-1905.json: in-progress reservation expired on 2026-08-15

Closing: stale reservation exceeded grace period.

[Ergologica]

Hi @beejaygee — thanks for laying the timeline out here rather than quietly re-filing. That's a fair way to handle it and I'll try to match it.

For whoever arbitrates, my side of the dates:

• 2026-07-16 — you opened reservation [WIP] Bounty ergoplatform/ergo#1905 - Prevent custom-scan boxes from being spent #43 for ergo#1905.
• 2026-07-30 — I opened upstream PR Wallet must not spend boxes tracked by external scans only (#1905) ergoplatform/ergo#2451 with the fix, and reservation Create ergoplatform-ergo-1905.json (reservation, 500 SigUSD) #48 here.
• 2026-07-31 — the triage bot labelled both [WIP] Bounty ergoplatform/ergo#1905 - Prevent custom-scan boxes from being spent #43 and Create ergoplatform-ergo-1905.json (reservation, 500 SigUSD) #48 duplicate-bounty and auto-closed them in the same run; ergo#2453 was opened the same day.

So upstream, ergo#2451 was opened a day before ergo#2453; on the reservation side you were first. I did not read #43 as active when I picked this up, since it had passed its stated completion date with no upstream PR attached, but I take your account of why it was paused at face value.

I'm not asking for #52 to be closed. You've already left precedence to the maintainers, and I'd rather they compare the two patches on their merits than have either of us argue seniority. @glasgowm148 @cannonQ @kushti — whichever of ergo#2451 / ergo#2453 you prefer, I'm happy to close mine and review the other if that helps. I'd only ask that the bounty follow whichever PR gets merged.

One thing worth flagging regardless of who ends up with this one: the auto-close that hit both #43 and #48 looks like a rough edge in scripts/triage_submission_prs.py. bounty_claims() labels every open submission pointing at a contested bounty as duplicate-bounty, and should_close_invalid() closes on that label unconditionally — so two claims annihilate each other instead of the earlier one surviving. Happy to open a separate PR making the first open claim keep priority, if that would be useful.

[Ergologica]

Following up on the bot behaviour I mentioned above, rather than just complaining about it: #59.

The check filtered claims with != pr["number"], so with two open claims on one bounty each one saw the other, both got duplicate-bounty, and should_close_invalid closed both. The fix counts only earlier claims, so the first one survives and later ones are still closed — which is the first-come rule the repo already states.

Applied to this case it would have kept #43 and closed #48. #48 was mine. That is the correct outcome for a first-come rule, and it changes nothing about which patch the maintainers pick here.

One thing I left out of that PR on purpose: what happens when the earliest claim goes stale. That is a policy call for @glasgowm148 and the maintainers, not something to settle inside a bugfix.

[Ergologica]

Hi @beejaygee — thanks for flagging that we reached the same fix independently; that was fair of you and I would like to keep this equally straightforward.

For whoever arbitrates it, the timeline as I understand it:

• 2026-07-16 — you opened reservation [WIP] Bounty ergoplatform/ergo#1905 - Prevent custom-scan boxes from being spent #43 for ergo#1905, with an expected completion of 07-24.
• 2026-07-30 — I opened upstream PR Wallet must not spend boxes tracked by external scans only (#1905) ergoplatform/ergo#2451 with the fix, and reservation Create ergoplatform-ergo-1905.json (reservation, 500 SigUSD) #48 here.
• 2026-07-31 — the triage bot labelled both [WIP] Bounty ergoplatform/ergo#1905 - Prevent custom-scan boxes from being spent #43 and Create ergoplatform-ergo-1905.json (reservation, 500 SigUSD) #48 duplicate-bounty and auto-closed them in the same run, since two open submissions pointed at the same bounty.
• Afterwards you opened this PR against upstream Wallet must not spend boxes tracked by external scans only (#1905) ergoplatform/ergo#2453.

So on the upstream side ergo#2451 was opened a day before ergo#2453, and neither is merged yet. On the reservation side you were first, though #43 had passed its stated completion date and had no upstream PR attached at the time I opened mine, which is why I did not read it as still active.

I am not asking for this PR to be closed — that call belongs to the maintainers, and I would rather they compare the two patches on their merits than have either of us argue seniority. @glasgowm148 @cannonQ @kushti, whichever of ergo#2451 / ergo#2453 you prefer to merge, I am happy to close mine and, if it helps, review the other. I would only ask that the outcome follows the merged PR.

One thing worth noting regardless of who ends up with this bounty: the auto-close that hit both #43 and #48 looks like a rough edge in scripts/triage_submission_prs.py. bounty_claims() labels every open submission pointing at a contested bounty as duplicate-bounty, and should_close_invalid() acts on that label unconditionally, so two claims annihilate each other instead of the earlier one surviving. I am happy to open a separate PR making the first open claim keep priority, if that would be useful.