Should issue 7691 be an unconsented dest ownerDir / AccountDelete question rather than a DelegateSet patch?

[Krypto-Whitehat]

I am not proposing a patch or a PR.

Question: should #7691 be treated as a DelegateSet bug, or as a general unconsented dest ownerDir vs AccountDelete / resurrection question?

What I think I understand (please correct)

AccountDelete::preclaim only walks keylet::ownerDir(account):

• Type with nonObligationDeleter == nullptr -> tecHAS_OBLIGATIONS (deletion blocker). Dest must remove it with the type-specific tx.
• Auto-deleted type (including ltDELEGATE) -> counts toward kMaxDeletableDirEntries (1000). Over 1000 -> tefTOO_BIG. Cleanup happens only if preclaim passes.

XLS-75: OwnerNode is only on the delegating account; Delegate is not a deletion blocker; only the delegator submits DelegateSet. The implementation still dirInserts into dest ownerDir (sfDestinationNode) so dest AccountDelete can find inbound Delegates. That extra link is both:

• the Delegate inbound-directory griefing → permanent AccountDelete denial] (Version: [3.2.0]) #7691 griefing surface (dest cannot remove Delegates, so 1001 inbound auto-deleted entries -> tefTOO_BIG with no dest tx), and
• the resurrection cleanup hook (AccountDelete never sees objects that are not in its ownerDir; leftover Delegate authority can apply to a re-funded address after the 256-ledger window).

Dest-linked creates (develop)

These insert into another account's ownerDir without that account sending the create:

Type	Dest/other dir	Dest can remove?	Dest AccountDelete
Check	yes (sfDestinationNode)	CheckCancel (source or dest; anyone if expired)	blocker
Escrow	yes	EscrowFinish / EscrowCancel (time/condition)	blocker
PayChannel	yes	PaymentChannelClaim tfClose after settle delay	blocker
Credential	subject dir (sfSubjectNode)	CredentialDelete (subject or issuer; anyone if expired)	auto-delete
Delegate	yes (sfDestinationNode)	No (delegator empty Permissions only)	auto-delete + 1000 cap

Check/Escrow/PayChannel inbound: dest is blocked until dest uses a documented cancel/close path (dest agency). Delegate inbound: dest has no such path, so the 1000 cap can be permanent for dest.

That still looks like a pattern (dest ownerDir insert without dest create), not a one-file DelegateSet special case. I do not have a design that hits griefing, cleanup, work bounds, and XLS-75 at once, and I am not asking for a rubber stamp on one.

[Krypto-Whitehat]

Follow-up: the first post did not spell out what a later solution would have to satisfy.

A later systemic design, if there is one, has to hit all of these at once (still not choosing an implementation here):

• Dest AccountDelete must not be permanently blocked by objects dest did not create and cannot remove.
• Dest delete (or an equivalent hook) must still remove dest-linked authority so resurrection does not inherit it.
• No mixed ownerDir walk on the create path.
• Dest AccountDelete work stays bounded (today: 1000 auto-deleted entries or first blocker).
• DelegateSet stays delegator-only (XLS-75).
• Tests fail before the change on (a) and (b) above.

@mvadari thanks for your tipps and notices and sorry for the to fast pull requests..