1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
|
Return-Path: <sebastian@gnet.me>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id 500D9C0052
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Nov 2020 23:03:16 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 3D3718708E
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Nov 2020 23:03:16 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
Received: from hemlock.osuosl.org ([127.0.0.1])
by localhost (.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id B6s3UnESw4mb
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Nov 2020 23:03:14 +0000 (UTC)
X-Greylist: delayed 00:16:31 by SQLgrey-1.7.6
Received: from mail-40131.protonmail.ch (mail-40131.protonmail.ch
[185.70.40.131])
by hemlock.osuosl.org (Postfix) with ESMTPS id DAF3287064
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 30 Nov 2020 23:03:13 +0000 (UTC)
Date: Mon, 30 Nov 2020 23:03:06 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gnet.me;
s=protonmail; t=1606777390;
bh=jORp0D3CpflHgySgWzvFuBYptjExU6rl78jR/A5Uc7I=;
h=Date:To:From:Reply-To:Subject:From;
b=JVs2utmw3d+I+SVInSwMwlRxOuaVMRWO/F6Rdoo22r2wpaDhz+me0keye6HhbDCm2
m3+Gp0SyiKuJfqSl6ZMGmv+h7QbWAOLuTVNVP0FWltWtIfGMcjUDdRH7enLfzulKeh
owlLgV1TNnMJieT7f59SlDXIQO1PQnzSOhIAR+gs=
To: bitcoin-dev@lists.linuxfoundation.org
From: Sebastian Geisler <sebastian@gnet.me>
Reply-To: Sebastian Geisler <sebastian@gnet.me>
Message-ID: <9a068476-855e-0dd7-4c9c-264d5d8bf60a@gnet.me>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Tue, 01 Dec 2020 00:26:20 +0000
Subject: [bitcoin-dev] Out-of-band transaction fees
X-BeenThere: bitcoin-dev@lists.linuxfoundation.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: Bitcoin Protocol Discussion <bitcoin-dev.lists.linuxfoundation.org>
List-Unsubscribe: <https://lists.linuxfoundation.org/mailman/options/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=unsubscribe>
List-Archive: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/>
List-Post: <mailto:bitcoin-dev@lists.linuxfoundation.org>
List-Help: <mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=help>
List-Subscribe: <https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev>,
<mailto:bitcoin-dev-request@lists.linuxfoundation.org?subject=subscribe>
X-List-Received-Date: Mon, 30 Nov 2020 23:03:16 -0000
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
|
