[Feature Request] testmempoolaccept without signature #14859

In coinjoins I must scrutinize unconfirmed inputs registrations before the transaction is built.
For now, the only things I do are

1. To make sure it comes from another coinjoin created by me. (It's more like a convenience thing to rule out a host of possible attacks.)
2. Check how many unconfirmed coinjoins there are at the moment. If larger than 24, then I don't accept any unconfirmed input to be registered.

Lately I encountered an issue where at coinjoin propagation I got the following error from RPC: too-long-mempool-chain: too many descendants for tx....

Thus I figured it would be useful if I could build a fake unsigned transaction (I do not have signature at the point when the input is registered) and test mempool acceptance for that.

I know it wouldn't replace the first sanity check I described, but it would replace my second sanity check in a future proof way.

Also I'd be happy to hear out other suggestions, too.

Also I'd be happy to hear out other suggestions, too.

getmempoolentry does expose ancestorcount and ancestorsize, so you can loop through and apply an overzealous check by using that.

getmempoolentry does expose ancestorcount and ancestorsize, so you can loop through and apply an overzealous check by using that.

While they're called the same, unfortunately they're different.

the method returns the counts and sizes of the direct ancestors and descendants. However, the mempool acceptance policy checks if any ancestor would have 'n' or more in-mempool descendants and if any ancestor would have more than 'n' kilobytes of in-mempool descendants (https://github.com/zkSNACKs/WalletWasabi/pull/936#discussion_r239950022)

Of course this method makes me able to walk the chain if that's what you're referring to by "overzealous check", so thank you.

By "overzealous check", I just meant erring on the extremely conservative side. Which will allow you to avoid most problems, while still allowing legitimate unconfirmed usecases.

I might be wrong here, but I think fundamentally if you ever accept unconfirmed inputs you always need to handle the mempool acceptance errors. As you sort of fundamentally have a TOCTTOU style condition, when other transactions in that "package" are potentially spent and your transaction which was previously acceptable is now not.

The only way around that I see is removing the whole limitdescendant(count/size) stuff in favor of pure ancestor restrictions, but that opens a bit of a bag of DoS vectors.

See also the discussion in #14939 (comment)

I think this can be closed unless someone would like to spark a new discussion on this topic.