GaloyMoney
batch payment for onchain transactions
current approach
currently, every onchain transaction we are doing is not batched but sent instantly to the recipient.
while it's offering an instant feedback for the recipient (transaction appears in the mempool instantly), this is not the best way to have low fees, or to deal with a rising fee environment.
UXTO with this approach are typically reused from the mempool, so there is the issue of having eventually too many child-pay-for-parent. This may leads to error where no more transaction can be sent, not because there is a lack of uxto/funds, but because all the utxo max out child-pay-for-parent in the mempool per bitcoin-core policy (the number is at 20 AFAIR).
This could leads to issue in the rising fee environment because if all the uxto has been sent and we can't increase the fee, then our users could never see their tx confirmed. Or only see their TX confirmed after days/weeks/months which would not be an acceptable UX.
so far this has not happened, because 1/ the fees are low, and 2/ we pay high enough fees to typically confirm on the next block.
the code handling the onchain payment is here
why batching
-
batching could help lower the fees for the end user
-
batching would help us lower the amount of block space Galoy instances are using. As more Galoy instances are being deployed, this could eventually have an impact on the mempool.
-
if the transaction is construct with one of the output been the change, then this change could be re-spent with a RBF. This would ensure that batch transaction are not stuck in the mempool.
api / executable
the batcher could be a micro service that we have as part of our the Galoy stack.
it would have an API that looks like this:
- addPayment(address, amount, pool): Success | Error
A typical error could be if there is not enough funds to pay for the transaction. an important point to consider is how much funds to reserve to bump the batched transaction if the fees are rising.
whenever a payment would be added to the batcher, if the return is a success, we would assume the funds have withdraw from the associate end user. for this reason, there is no need (in our case) to be able to withdraw a payment (for the first version at least)
a configuration file could look like this:
queues:
- name: instant
frequency: 10s
- name: daily
frequency: 1d
lnd:
- macaroon: ...
cert: ...
address: ...
whenever a payment is been sent through the API, the batcher would add the payment to a queue. periodically, and depending off the settings of each queues, the payment would be signed and sent to the mempool.
