Re: [bitcoin-dev] Out-of-band transaction fees

[Sebastian Geisler <sebastian@gnet.me>]

Hi Eric,

> In paying fees externally one must find another way to associate a fee with its transaction. This of course increases the possibility of taint, as you describe in part here:

I'm not sure I follow, do you see a problem beyond the facts that miners
would need to authenticate somehow? This can be done in a privacy
preserving way per block. I don't think transactions would need to
change in any way. The bounty-transaction link is upheld by a third
party service which the miners have to trust that it will pay out if the
transaction is included (not perfect, but a business decision they can
make).

> It is also the case that the "bounty" must be associated with the transaction. Even with miner and payer mutual anonymity, the fee inputs and outputs will be associated with the transaction inputs and outputs by the miner, rendering the proposal counterproductive.
> Total transaction sizing is not reduced by paying fees externally, in fact it would be increased. The only possible reduction would come from aggregation of fees. Yet it is not clear how that aggregation would occur privately in less overall block space. At least with integral fees, it's *possible* to spend and pay a fee with a single input and output. That is not the case with externalized fees.

I should have made this more clear, I don't imagine anyone to pay these
fees with L1 transactions, but rather some L2 system like Lightning or a
BTC backed chaumian token issued for that purpose by the bounty service
provider. Even Lightning would be far more private for the use cases I
described that don't allow fee deduction from inputs. But if one accepts
more counter party risk with e.g. some centrally pegged chaumian token
it can be anonymous.

I see that this might not be very useful today, but I imagine a future
in which Bitcoin is mostly a settlement and reserve layer. This would
make it feasible to keep most UTXOs in common sizes. Only large, round
transactions happen on-chain, the rest can happen on L2. This would
allow tumbling these already evenly-sized UTXOs on spend without toxic
waste if we can somehow tackle the fee payment problem. I know of the
following solutions:

 * everyone has to add a second UTXO per input
 * Someone is chosen fairly at random to pay the total fee
 * pay a service on L2 to add an input/output for fee payment
 * out-of-band L2 fee payments

Only L2 fee payments can hide who is involved in such a tumbling
operation as additional fee inputs that get reused would indicate the
same entity was present in two tumbling operations. The out-of-band
approach saves one input and one output and appears more general (e.g.
could be used like rbf).

This is also not a general solution for fee payments. In many cases it
will still be preferable to pay on-chain fees. But having the option to
avoid that in a standardized way could help some protocols imo.

Best,
Sebastian


> -----Original Message-----
> From: bitcoin-dev <bitcoin-dev-bounces@lists.linuxfoundation.org> On Behalf Of Sebastian Geisler via bitcoin-dev
> Sent: Monday, November 30, 2020 3:03 PM
> To: bitcoin-dev@lists.linuxfoundation.org
> Subject: [bitcoin-dev] Out-of-band transaction fees
> 
> Hi all,
> 
> the possibility of out of band transaction fee payments is a well known fact. Yet it has been mostly discussed as an annoying inevitability that can be problematic if on-chain fees are to be used as a consensus parameter. The potential use cases have seen little interest though (please correct me if I'm wrong).
> 
> One such use case is sending UTXOs "intact". Let's assume we get to a point where Bitcoin is primarily a settlement layer for L2 systems.
> These L2 systems might want to protect their privacy and keep UTXOs of a common sizes (e.g. 1 BTC, 10 BTC, …). For certain settlement applications these can be transferred as a whole, but currently fee requirements force the system to add another input for fees which will introduce taint (because it's used repeatedly). 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.
> 
> Taking this concept even further 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 afaik). Such a mechanism would probably also 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 can not be effectively prevented. So even though any such proposal will probably have slight centralizing effects I believe that having a standard for it is preferable to having every pool implement their own API making it harder for small pools to get into the market.
> 
> Imo the central questions are:
>  * how to build such a out-of-band "transaction bounty" system
>  * how to standardized it
>  * how can the centralizing effects from it be mitigated
> 
> Imo fees are small enough to not really care about counter party risk that much. It's more important that it is easy to run so that there is some choice for users and miners. In that sense I consider single-operator services providing both standardized user and miner APIs as well as an optional UI suitable. I would still take into account that this could change and might consider the needs of federated services in the protocol.
> 
> 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 e.g. in the coinbase scriptsig after the height push (is this feasible?). 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 (so this should also be enforced at least in the bounty protocol to avoid lazy implementations leading to dangerous precedents).
> 
> Any feedback is welcome :)
> 
> tl;dr Out-of-band fee payment services are inevitable and useful, so we should at least standardize them and mitigate negative effects as much as possible.
> 
> Best,
> Sebastian
> 
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>