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
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
|
Return-Path: <user@petertodd.org>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
by lists.linuxfoundation.org (Postfix) with ESMTP id A646AC000B;
Thu, 10 Feb 2022 06:59:04 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by smtp4.osuosl.org (Postfix) with ESMTP id 8706C4091A;
Thu, 10 Feb 2022 06:59:04 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -0.903
X-Spam-Level:
X-Spam-Status: No, score=-0.903 tagged_above=-999 required=5
tests=[BAYES_20=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
autolearn=ham autolearn_force=no
Authentication-Results: smtp4.osuosl.org (amavisd-new);
dkim=pass (2048-bit key) header.d=petertodd.org header.b="r4wtyNR2";
dkim=pass (2048-bit key) header.d=messagingengine.com
header.b="d+Bl2g0C"
Received: from smtp4.osuosl.org ([127.0.0.1])
by localhost (smtp4.osuosl.org [127.0.0.1]) (amavisd-new, port 10024)
with ESMTP id Ghfed-tnv1uA; Thu, 10 Feb 2022 06:59:03 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com
[66.111.4.27])
by smtp4.osuosl.org (Postfix) with ESMTPS id 52C7C40917;
Thu, 10 Feb 2022 06:59:03 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
by mailout.nyi.internal (Postfix) with ESMTP id 9C2085C010D;
Thu, 10 Feb 2022 01:58:59 -0500 (EST)
Received: from mailfrontend2 ([10.202.2.163])
by compute2.internal (MEProxy); Thu, 10 Feb 2022 01:58:59 -0500
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=petertodd.org;
h=cc:cc:content-type:date:date:from:from:in-reply-to
:in-reply-to:message-id:mime-version:references:reply-to:sender
:subject:subject:to:to; s=fm1; bh=rh+0Hp5tDd2iqKF3XzD0mvH9g0Pedc
k6+gS1eMnX0tk=; b=r4wtyNR277mZyYqV18w2ZGFyTFew70N7Yw87FRgZxe4FGK
RTemP7dw6SWINqzgaXfnIhMHkVtOxAu6telFejajIqBXSzNUNzRXv6ppDaB8h6Lt
tuIolTlXxLcgBHQQeE0ofmz6DNpYfkMOcGqxyJWK8vLlKz92irCtSZ/fk5l4Vu7l
vBouFH4snHk6S/4VW7GVgRrf/4t59f70aOqcsaBnkFBcnDq1yHPLbnPWCN3/u7Ku
YqRdlYChybt381NnmObCtm86mh6xBwoc4JkKwc3YTHnlekVtCi6K6B00lkGO8iP3
sjffQx5NCcJ0o4bfCo5dJRqQjWn7LnIViIMDeehw==
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
messagingengine.com; h=cc:cc:content-type:date:date:from:from
:in-reply-to:in-reply-to:message-id:mime-version:references
:reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy
:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=rh+0Hp5tDd2iqKF3X
zD0mvH9g0Pedck6+gS1eMnX0tk=; b=d+Bl2g0CTESbHbTtXPGGjZiyK4jwiw8k3
OujEo0qXQ1sxHeRoKlHiL9NF9l+F1JLAo9T9jXzGmkAvBCh4as3Mlq48qknNFpI4
27lFMEwT0idSue4NiTn29MPTtoe2nrtd5uz6L72Ya9xcuCMOCfCb+tcWsQSRXb+L
A01t251sJfhmzTUUIOnDonqJkcCfLKvk1hVqwMZGWLNnpjFSBOSpE2wjb6vLP7Vs
1l4Z9x/iDZB/EPMTvahyyl7+PpWqBThiwQ9DhCFnZCvfRHArTgqoa1lnzT2K9egi
nGl4oDJC+Y44BjmgFW65DJ/o5Lg9/kFGrUFs5NyX06KedAbzT2DxQ==
X-ME-Sender: <xms:s7cEYg9p6DYrZqK_L87JFm1H05pDsYweVL4Au8fk0D1WWyOx9fldiw>
<xme:s7cEYotRIlPR2i9l9xG4MIB8bz_bRdXwY81Q7ora0USAQL8Mt1Y1Ga4sUFWP-qQ8Z
TDf8H5Ngvf7vqsyXtQ>
X-ME-Received: <xmr:s7cEYmDyY-jOL2xg8UjrRGo8yD_saLnjPxmayWbC-olgbmTxiwyAHuSLLnFNRhFrVUYxr_ipJDedzRedOBqwKcPDc8ZAi9u9ZrknDjwdmA>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddriedtgddutddtucetufdoteggodetrfdotf
fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen
uceurghilhhouhhtmecufedttdenucenucfjughrpeffhffvuffkfhggtggujgesghdtre
ertddtvdenucfhrhhomheprfgvthgvrhcuvfhougguuceophgvthgvsehpvghtvghrthho
uggurdhorhhgqeenucggtffrrghtthgvrhhnpeeivddvleeikeejueekgfdtleefgeehhe
elffeuheetgefhleevjeefleegvefffeenucffohhmrghinhepphgvthgvrhhtohguugdr
ohhrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpe
hushgvrhesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:s7cEYgffs7NGxZUleGyqDE5S-E9Zz5Mp9mfVT7qZ07C_nj4ydNOQsA>
<xmx:s7cEYlMErgbWUtLCgR3p45DbswNpy4ON9y7L75kcah7RRWS-USazMQ>
<xmx:s7cEYqkFZad4ZtdPYzn_EGalqUw0F7pdxKBin1WfB0oAR5aTtVaReQ>
<xmx:s7cEYj0kD5JThVjtAzxD7zDET2_LWy9zZZjm8DF0SmTUH28PvU2Mtw>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
10 Feb 2022 01:58:59 -0500 (EST)
Received: by localhost (Postfix, from userid 1000)
id 360CE5FB03; Thu, 10 Feb 2022 01:58:56 -0500 (EST)
Date: Thu, 10 Feb 2022 01:58:56 -0500
From: Peter Todd <pete@petertodd.org>
To: Jeremy <jlrubin@mit.edu>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <YgS3sJvg6kG3WnVJ@petertodd.org>
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="4n2c0ZHw8MhhzNdK"
Content-Disposition: inline
In-Reply-To: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
Cc: lightning-dev <lightning-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] [Pre-BIP] Fee Accounts
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: Thu, 10 Feb 2022 06:59:04 -0000
--4n2c0ZHw8MhhzNdK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
> Happy new years devs,
>=20
> I figured I would share some thoughts for conceptual review that have been
> bouncing around my head as an opportunity to clean up the fee paying
> semantics in bitcoin "for good". The design space is very wide on the
> approach I'll share, so below is just a sketch of how it could work which
> I'm sure could be improved greatly.
>=20
> Transaction fees are an integral part of bitcoin.
>=20
> However, due to quirks of Bitcoin's transaction design, fees are a part of
> the transactions that they occur in.
>=20
> While this works in a "Bitcoin 1.0" world, where all transactions are
> simple on-chain transfers, real world use of Bitcoin requires support for
> things like Fee Bumping stuck transactions, DoS resistant Payment Channel=
s,
> and other long lived Smart Contracts that can't predict future fee rates.
> Having the fees paid in band makes writing these contracts much more
> difficult as you can't merely express the logic you want for the
> transaction, but also the fees.
>=20
> Previously, I proposed a special type of transaction called a "Sponsor"
> which has some special consensus + mempool rules to allow arbitrarily
> appending fees to a transaction to bump it up in the mempool.
>=20
> As an alternative, we could establish an account system in Bitcoin as an
> "extension block".
<snip>
> This type of design works really well for channels because the addition of
> fees to e.g. a channel state does not require any sort of pre-planning
> (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> design is naturally immune to pinning issues since you could offer to pay=
a
> fee for any TXID and the number of fee adding offers does not need to be
> restricted in the same way the descendant transactions would need to be.
So it's important to recognize that fee accounts introduce their own kind of
transaction pinning attacks: third parties would be able to attach arbitrary
fees to any transaction without permission. This isn't necessarily a good
thing: I don't want third parties to be able to grief my transaction engine=
s by
getting obsolete transactions confirmed in liu of the replacments I actually
want confirmed. Eg a third party could mess up OpenTimestamps calendars at
relatively low cost by delaying the mining of timestamp txs.
Of course, there's an obvious way to fix this: allow transactions to design=
ate
a pubkey allowed to add further transaction fees if required. Which Bitcoin
already has in two forms: Replace-by-Fee and Child Pays for Parent.
--=20
https://petertodd.org 'peter'[:-1]@petertodd.org
--4n2c0ZHw8MhhzNdK
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmIEt6oACgkQLly11TVR
Lzc3dA//dFCCJJh1t/XchnJlTXr4iQrmQAUOEajUnXL/2kUAlBqJ2jvE3tXUg4Lh
SB5jvs4EnC6phhrbphpWxso1v6XL3RGJUf60tUz0h/bO41DyOMGbVX82NtSNNfne
z4qDeVKNKv/Wo9/lHAoSQvH/CrK7AajMqWOZk4Rvok00FLkKAAAvOxBlL+KkZKhL
PYLMfvSXLoTMeiV1EjZZep8qDMh82VB5cOQIWYYiMhB+q0ebx7jpy6A/Z/pqwZfe
NBh2P+Ryw/kCo1e4c/JBI4Cr8Bybl3VgcYdymDgpCyGd2Uldz2X/K3bKCpVaHNQI
Sg9yPf+d9+d02y2gQfAVAH1+2sP540fkitkXBmLuwNRKwDifLjGqseZUdajwndGK
ggSqfcXiH/y0WSzRDOOLW37Jg09q8nNjogreJ9AsqbbCHlf0phCTqtothdpTAV3u
C0+ug/A6sWmGQm28iqYroV03nGIz3vHiMwtfsCIWUMphAS19puZN/cUFqqzE7My0
h/7GT6glhDd4Ybh27/LelhkjKQgtV1hjSBbBRIS1uitr7QyX93gJxYN1FvZYrhdJ
4KW6Ix4cruHqk1p3s3wjRy2444sEDwMHFGj4shFJZEyuinG8yoyzSayF0wxfsPaC
xQSMikGWDRptt3jTwBivmKodFYDMHI3WoJskhLV3fWA6I5Ghp8I=
=2YOz
-----END PGP SIGNATURE-----
--4n2c0ZHw8MhhzNdK--
|
