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
|
Return-Path: <dave@dtrt.org>
Received: from hemlock.osuosl.org (smtp2.osuosl.org [140.211.166.133])
by lists.linuxfoundation.org (Postfix) with ESMTP id E0EAAC0171
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jan 2020 21:02:34 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id D3DBB86CD7
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jan 2020 21:02:34 +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 mL-iiEK4nmnn
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jan 2020 21:02:33 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.7.6
Received: from newmail.dtrt.org (li1228-87.members.linode.com [45.79.129.87])
by hemlock.osuosl.org (Postfix) with ESMTPS id 9228D86416
for <bitcoin-dev@lists.linuxfoundation.org>;
Fri, 31 Jan 2020 21:02:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1ixdQt-00076g-UX; Fri, 31 Jan 2020 16:02:31 -0500
Date: Fri, 31 Jan 2020 15:01:29 -0600
From: "David A. Harding" <dave@dtrt.org>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200131210129.ufnjxb2x7wllhcuw@ganymede>
References: <2U3WdMgyM7iLhQnak0GjkH6u6C0C_Ry59WucTiRthajkOXqAirvN55U39to0kQY5bDzv9SBZXy5Qbx2QZopJwktHqVUKbfpCjEfq1H_v0vE=@protonmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="gscbx64t2zhk4gwn"
Content-Disposition: inline
In-Reply-To: <2U3WdMgyM7iLhQnak0GjkH6u6C0C_Ry59WucTiRthajkOXqAirvN55U39to0kQY5bDzv9SBZXy5Qbx2QZopJwktHqVUKbfpCjEfq1H_v0vE=@protonmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] Onchain fee insurance mechanism
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: Fri, 31 Jan 2020 21:02:35 -0000
--gscbx64t2zhk4gwn
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Fri, Jan 31, 2020 at 03:42:08AM +0000, ZmnSCPxj via bitcoin-dev wrote:
> Let me then propose a specific mechanism for feerate insurance against on=
chain feerate spikes.
>=20
> [...]
>=20
> At current blockheight B, Alice and Ingrid then arrange a series of trans=
actions:
>=20
> nLockTime: B+1
> nSequence: RBF enabled, no relative locktime.
> inputs: Alice 5000000, Ingrid 800000
> outputs:
> Bob 400000
> Alice 99400
> Ingrid 800400
> fee: 200
>
> [...]
Ingrid is able to rescind this series of pre-signed transactions at any
time before one of the transactions is confirmed by double spending her
UTXO (e.g. via a RBF fee bump). If Alice needs to trust Ingrid to honor
the contract anyway, they might as well not include Ingrid's input or
output in the transaction and instead use an external accounting and
payment mechanism. For example, Alice and Ingrid agree to a fee
schedule:
> height: B+1
> fee: 200
>
> height: B+2
> fee: 400
>
> height: B+3
> fee: 599
>
> height: B+4
> fee: 3600
Then they wait for whichever version of the transaction to confirm and
one of them remits to the other the appropriate amount (either 400, 200,
or 1 base unit to Ingrid, or 3,000 base units to Alice). This
remittance can be done by whatever mechanism they both support (e.g. an
onchain transaction, an LN payment, or just credit on an exchange).
Since it's possible to achieve equivilent security (or lack thereof)
without the locktime mechanism, I don't think the locktime mechanism
adds anything to the idea of hedging fees---and, as you note, it suffers
=66rom incompatibility with some cases where users would be especially
eager to obtain feerate insurance.
-Dave
--gscbx64t2zhk4gwn
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl40lakACgkQ2dtBqWwi
adOaoxAAnVbJme1HN9kl+rY2V0Arxf7oSXlACBNO04rBrMnW4q5Ne7WVQYHI+RV4
zs+lOIzayQ+7bOa3QJ7EfWTODOc8VlykWCMOpF3Ry4GFgWpbhhS2F/CWBcG9bW09
NS4TIu7qEDqUWJV64sZ63kmo5pp8Mv86/1uKl0oGdK/yW36D5hMa1WnkSocFwOM8
L2r947WFhJk5BE1L6BST2bHm6uYP/wK1YVaBBrK5/9SR01TZA+XcduhUG6SPGChy
RBlwkXh1/fXOrrur4WyqJROHzyJdK7kfFPcQPDdgJDGh5c9rG6WwpbJ2C3aF2ZFJ
DNokeYsWxiOSxDaQP2KdMHKXroWTnW3y+TXaiDsjjtuJI9VOJjcEfM9eQaEszykz
XvqF4MaorgA0m+kPYXdsipVYQQvBuVd2apfIQ/1NvMaJpo15PPBELOo3oecwH2+d
YHp1CjRCfCZlGujDi+gjOvRHxQP3Y9I1UIj9c9+pf0lpgjxa0QGNR/DfqHakjuVD
NmOi3ueNdiwMDrmUE8rIwj2MRKo/oNrGgwXLl0A2/PhDHgGmlOmOd3NDJwLmumsl
3nIE6OEUb6rfFA7wlx85MIOZ7AmVVAFOgD8925oFwCtQi33yxouuSAHfbt41ytp6
vOguZ9EMRQGtqB1tVl9+Iq23BDz2DrYegFi7JZt0FllyUr+H0ds=
=qDn5
-----END PGP SIGNATURE-----
--gscbx64t2zhk4gwn--
|
