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

[ZmnSCPxj <ZmnSCPxj@protonmail.com>]

Good morning Sebastian and e,

> 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).

There has to be an association of "how much do I get if I include *this* particular transaction" to "*this* particular transaction", so that the miners have an informed decision of how much they stand to earn.
Unless fees are also standardized, this can be used to leak the same information ("sombody offered this specific amount of money to the bounty server, and the bounty server associated this particular amount to this particular transaction").


More concerningly, [a trusted third party is hard to get out of](https://nakamotoinstitute.org/trusted-third-parties/).
If there are only a few of them, it becomes easy to co-opt, and then a part of the mining infrastructure is now controllable from central points of failure.
If there are many of them, then evaluating which ones cheat and which ones do not will take a lot of effort, and the system as a whole may not provide benefits commensurate to the overall system cost in finding good third parties.


> > 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.

Since such L2 mechanisms themselves are dependent on L1 and require a facility to bump up fees for e.g. commitment transactions in Lightning Network, this brings up the possibility of getting into a bootstrapping problem, where the security of L2 is dependent on the existence of a reliable fee-bumping mechanism at L1, but the fee-bumping mechanism at L1 is dependent on the security of L2.
Not impossible, but such strange loops give me pause; I am uncertain if we have the tools to properly analyze such.

>
> 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
>
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev