return entire dependency package of matching tx with filtered mempool requests #7237

When an SPV client connects to a node and performs a mempool request after setting a bloom filter, it would be very useful for the response to include the entire dependency package of unconfirmed inputs for any transactions that match the filter.

This would allow for the SPV client to know if any transactions it receives are part of a unconfirmed dependency chain, allows it to have more information about fees paid in that chain for more accurate CPFP calculations when spending those inputs, and allows it to know if any other mempool limits might be violated when spending those inputs such as the 25 tx chain length limit.

Not sure if this is a good idea. Node operators are stopping bloom filters because of abusive/DOS-like incoming mempool messages. Adding the whole dependency chain might increase the problem. I think adding more and more features for spending or estimating risks for 0-confs is the wrong direction. Also the cost for such "features" needs to be paid by full node operators (we already have enough resource costs there).

By making the mempool message more useful, you prevent the need for clients to repeatedly update the filter and re-request. The filter is already auto-updated to catch transactions that spend previously matched outputs, so it doesn't need to be constantly re-loaded after each transaction. In any case the additional load will be negligible.

Improving the usability 0-conf is certainly an important goal for increasing bitcoin adoption. It's unrealistic to expect people not to use 0-conf, and there are several improvement paths, such as broadcasting partial block solutions, that can make them reliable in more situations.

Brief summary of breadwallet stance on 0-conf:

Worst case for 0-conf is full-RBF, any tx can be reliably reversed at any time before confirmation. In this case, merchants will still accept 0-conf and consider the fraud rate part of the cost of accepting bitcoin. (The cost of waiting for confirmation is even higher in many situations.) Our goal then is to lower that fraud rate as much as practical, even though getting to zero obviously isn't possible

@voisine

Have you seen the greenaddress.is instant transactions?

Instant transactions which are potentially compatible with full-RBF and transaction cut through.

"What exactly is an 'instant greenaddress transaction'?" https://greenaddress.it/en/faq.html

@voisine Full RBF does not logically increase fraud rate at all, only legit double spending.

@luke-jr are you referring to RBF in combination with CPFP and scorched-earth?

If automated and widely adopted, it certainly reduces the incentive to commit 0-conf fraud, at least against recipients with always-on wallets. There's still a chance the RBF tx reversal could get committed before the merchant detects it and has a chance to fully propagate their own CPFP response, so I'm inclined to think a first-seen policy with miners communicating which tx they saw first with partial block solutions or otherwise would probably still be safer in practice.

@pstratem thanks for the link. I think I spoke with Lawrence about it last year at a meetup in SF.

We're hoping to improve the situation in a way that's decentralized and preserves privacy, but your offering could be interesting as part of a 0-conf fraud insurance service.

@voisine The only solution for instant transactions which is decentralized is a network of payment channels.

Unconfirmed transactions are just that unconfirmed.

I think this is reasonable. It doesn't change the existing security model, and may allow SPV clients to do analysis on dependencies. The bloom filter functionality is optional now (see BIP111), but returning unconfirmed dependencies is something that can work without that too.

This is reasonable, but in order for SPV clients to reasonably use it it also needs to give merkle-inclusion-proofs for everything that was in a block so that clients can validate they aren't missing anything. It's probably a massive DoS vector to do this, but also probably not worse than the bloom filtering stuff itself, so I wouldn't neccessarily have an issue with allowing clients to do it if bloom filtering is enabled.

@TheBlueMatt: clients can be assumes to have the already-confirmed once if they're synced.

Since bloom filters are now disabled by default and on the road to being deprecated, I don't think this will be implemented.