bitcoin-dev

Out-of-band transaction fees

Out-of-band transaction fees

Original Postby eric at voskuil.org

Posted on: December 1, 2020 01:06 UTC

The possibility of out-of-band transaction fee payments has been discussed as an annoying inevitability that can be problematic if on-chain fees are to be used as a consensus parameter.

However, there is potential for use cases that have seen little interest so far. One such use case is sending UTXOs "intact". L2 systems might want to protect their privacy and keep UTXOs of common sizes, but currently, fee requirements force the system to add another input for fees, which introduces taint. If instead, a fee could be paid out of band in a privacy-preserving way, the TXO chain would leak little about the intermediate holders.CoinJoin-like protocols could also be used to introduce further ambiguity without leaking that a certain entity took part in the CJ, which fee inputs/reused "toxic waste" inevitably do. Such a mechanism would probably make CJ transactions much smaller as no fee inputs had to be provided (assuming the inputs already have the right size).Out-of-band transaction "accelerators" already exist, and taking fee payment out-of-band cannot be effectively prevented. A standard for it is preferable to having every pool implement its API, making it harder for small pools to get into the market. The central questions are how to build such an out-of-band "transaction bounty" system, how to standardize it, and how the centralizing effects from it can be mitigated.Each such service would need to announce which means of payment it supports and allow users and miners to choose when paying/redeeming fees. Users should be able to submit transactions and either be presented with a single payment method-dependent "invoice" or one per input (for the CoinJoin use case). As soon as all invoices are paid, the bounty goes live and is visible to miners through an API.Miners that included a transaction need a way to authenticate when claiming the bounty. One possibility would be to optionally include a unique public key in the coinbase scriptsig after the height push. This could be used to claim any bounties after 100, 120, or even a user-defined confirmation threshold is met. If the key is unique for every block, there won't be a problem with pool accountability, which might become a risk down the road.In conclusion, out-of-band fee payment services are inevitable and useful, so standardizing them and mitigating negative effects as much as possible is necessary.