public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Sebastian Geisler <sebastian@gnet.me>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: [bitcoin-dev] Out-of-band transaction fees
Date: Mon, 30 Nov 2020 23:03:06 +0000	[thread overview]
Message-ID: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me> (raw)

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



             reply	other threads:[~2020-11-30 23:03 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-30 23:03 Sebastian Geisler [this message]
2020-12-01  1:06 ` [bitcoin-dev] Out-of-band transaction fees eric
2020-12-01 14:19   ` Sebastian Geisler
2020-12-01 15:49     ` ZmnSCPxj
2020-12-01 16:24       ` ZmnSCPxj
2020-12-01 19:14         ` Sebastian Geisler

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me \
    --to=sebastian@gnet.me \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox