MManke188
commented
3 months ago A thing that might help with this would be to revert the approach by trying first to batch all transactions and then removing the ones dragging the batch down the most instead of adding them individually. The question then is how you would decide which transaction should get removed.
Any transaction paying the threshold or more as a fee rate should never improve the fee rate of the batch when removed. So one way you might do it is going through the transactions one by one starting from lowest density and pretending to remove it to see if it could cause the batch to meet the threshold. If so -> store the candidate and try again by removing 2 transactions. If that also produces a successful batch and improves the service fees collected replace the candidate with the new one just found. If not (or even if it did work) try again with 3 and so on until the perfect batch has been found.
This should work I think but will think it through again.
At the moment the batching server fails to recognize that the fee rate of an individual PSBT would increase the more transactions are added to a batch leading to some PSBTs getting skipped even though they could be included. In the extreme case this means that a queue of 50 transactions each paying a fee rate of 9.99 sats/vB would all remain queued if the fee preference is 10 sats/vB. (see https://github.com/Peach2Peach/groupHug/blob/c686eede97da4558b7e0b3e2fb1f21cdd3510ec3/src/utils/batch/attemptPushToBucket.ts - every single transaction individually would not meet the threshold but if all batched together all could be batched)