Add inputs to unconfirmed dust spend transaction

[bubb1es71]

When creating a new dust spend transaction:

1. check for any existing unconfirmed transactions that have a single OP_RETURN output and one or more inputs with the SIGHASH_ALL|ANYONECANPAY signature type. The OP_RETURN can be empty (if original transaction was >= 65 bytes, ie. for single input P2WPKH) or contain the string ash.
2. add the new dust spend input(s) to the existing transaction.
3. verify the new fee rate is at least 1 sat/vb greater than the original transaction, if not don't combine.
4. create a new PSBT with the existing signed input(s) and new unsigned input(s).
5. sign and broadcast the new combined dust spend transaction.

This idea was suggested on delvingbitcoin by @ajtowns.

[bubb1es71]

@harismuzaffer would you like to add this feature? If so I'll help review and test.

[harismuzaffer]

@bubb1es71 yes, i will take up this

[harismuzaffer]

@bubb1es71 Should we consider defining a limit on the number of inputs we take from mempool? - Imagine there are 100s of txs in the mempool that match ddust pattern

[bubb1es71]

Good question, do you think we need a limit for performance reasons? Or is there some other reason to limit them?

As long as the fee rate of large combined spend transactions are greater than individual ones I don't see a reason not to create them. Larger ones should also (marginally) save block space.

[harismuzaffer]

I was thinking in terms of size that each input contributes. Because of block size limit, we can only have limited number of inputs in the dduts transaction - each p2tr input contributes ~58 vbytes

[bubb1es71]

Yes good point about transaction size. The max size needs to be under 400K weight units to meet the core standardness rule. Need to check while adding dust inputs that the new transaction doesn't go over that limit.

I don't think it's a high priority to put in right now, but should at least add an issue to do later.

[harismuzaffer]

Ok perfect, will create an issue later. Thanks