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

From: <eric@voskuil•org>
To: "'Sebastian Geisler'" <sebastian@gnet•me>,
	"'Bitcoin Protocol Discussion'"
	<bitcoin-dev@lists•linuxfoundation.org>
Subject: Re: [bitcoin-dev] Out-of-band transaction fees
Date: Mon, 30 Nov 2020 17:06:13 -0800	[thread overview]
Message-ID: <00e301d6c77e$2a4eeab0$7eecc010$@voskuil.org> (raw)
In-Reply-To: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me>

Hi Sebastian,

It's important to consider here that anonymity is the reason fees are incorporated into transactions. One must generally trust the party with whom one transacts. But since integral fees are paid to any miner, this does not apply to fees. 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:

> Miners that included a transaction need a way to authenticate when claiming the bounty.

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.

e

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