From: <eric@voskuil.org>
To: "'Sebastian Geisler'" <sebastian@gnet.me>,
 "'Bitcoin Protocol Discussion'" <bitcoin-dev@lists.linuxfoundation.org>
References: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me>
In-Reply-To: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me>
Date: Mon, 30 Nov 2020 17:06:13 -0800
Message-ID: <00e301d6c77e$2a4eeab0$7eecc010$@voskuil.org>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="utf-8"
Content-Transfer-Encoding: quoted-printable
Thread-Index: AQLv93ubyT21AA8J26luR0feJHDJbKevAsrw
Content-Language: en-us
Subject: Re: [bitcoin-dev] Out-of-band transaction fees
Precedence: list

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, =E2=80=A6). 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