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
|
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 4386CC0051
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Sep 2020 14:53:35 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
by hemlock.osuosl.org (Postfix) with ESMTP id 3D5E787259
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Sep 2020 14:53:35 +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 fGMnMmrkAAJi
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Sep 2020 14:53: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 A859783957
for <bitcoin-dev@lists.linuxfoundation.org>;
Mon, 21 Sep 2020 14:53:33 +0000 (UTC)
Received: from harding by newmail.dtrt.org with local (Exim 4.92)
(envelope-from <dave@dtrt.org>)
id 1kKNC7-0001dl-2X; Mon, 21 Sep 2020 10:53:31 -0400
Date: Mon, 21 Sep 2020 10:52:21 -0400
From: "David A. Harding" <dave@dtrt.org>
To: Antoine Riard <antoine.riard@gmail.com>,
Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Message-ID: <20200921145221.76bg5rnw7ohkm3ck@ganymede>
References: <CAD5xwhi6+Q-UX2xVnD4TE9uEbe-omQ748tpJJpYdrMNnG6D5vA@mail.gmail.com>
<CALZpt+FbRGrcW7LZY=4NtR9w4CP=kavVdqutfrX86OYnouHUJg@mail.gmail.com>
<CALZpt+EAWbPWh_knT7yDdPT396jEL1g+XSEv1JALuwaJVqNS7w@mail.gmail.com>
<CAD5xwhgw4Hsco73B1D5+EafXFbcr3227MM2ZNPtycyv2TS-n7g@mail.gmail.com>
<CALZpt+HtuVC6YmZvABaZUWmN9c3pV1FnX1UUJgGbd_iLuuU8hg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
protocol="application/pgp-signature"; boundary="6wtnduqfij32l4i6"
Content-Disposition: inline
In-Reply-To: <CALZpt+HtuVC6YmZvABaZUWmN9c3pV1FnX1UUJgGbd_iLuuU8hg@mail.gmail.com>
User-Agent: NeoMutt/20180716
Subject: Re: [bitcoin-dev] A Replacement for RBF and CPFP: Non-Destructive
TXID Dependencies for Fee Sponsoring
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, 21 Sep 2020 14:53:35 -0000
--6wtnduqfij32l4i6
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On Sun, Sep 20, 2020 at 07:10:23PM -0400, Antoine Riard via bitcoin-dev wro=
te:
> As you mentioned, if the goal of the sponsor mechanism is to let any party
> drive a state N's first tx to completion, you still have the issue of
> concurrent states being pinned and thus non-observable for sponsoring by =
an
> honest party.
>=20
> E.g, Bob can broadcast a thousand of revoked LN states and pin them with
> low-feerate sponsors such as these malicious packages absolute fee are
> higher than the honest state N. Alice can't fee-sponsor
> them as we can assume she hasn't a global view of network mempools. Due to
> the proposed policy rule "The Sponsor Vector's entry must be present in t=
he
> mempool", Alice's sponsors won't propagate.=20
Would it make sense that, instead of sponsor vectors
pointing to txids, they point to input outpoints? E.g.:
1. Alice and Bob open a channel with funding transaction 0123...cdef,
output 0.
2. After a bunch of state updates, Alice unilaterally broadcasts a
commitment transaction, which has a minimal fee.
3. Bob doesn't immediately care whether or not Alice tried to close the
channel in the latest state---he just wants the commitment
transaction confirmed so that he either gets his money directly or he
can send any necessary penalty transactions. So Bob broadcasts a
sponsor transaction with a vector of 0123...cdef:0
4. Miners can include that sponsor transaction in any block that has a
transaction with an input of 0123...cdef:0. Otherwise the sponsor
transaction is consensus invalid.
(Note: alternatively, sponsor vectors could point to either txids OR
input outpoints. This complicates the serialization of the vector but
seems otherwise fine to me.)
> If we want to solve the hard cases of pinning, I still think mempool
> acceptance of a whole package only on the merits of feerate is the easiest
> solution to reason on.
I don't think package relay based only on feerate solves RBF transaction
pinning (and maybe also doesn't solve ancestor/dependent limit pinning).
Though, certainly, package relay has the major advantage over this
proposal (IMO) in that it doesn't require any consensus changes.
Package relay is also very nice for fixing other protocol rough edges
that are needed anyway.
-Dave
--6wtnduqfij32l4i6
Content-Type: application/pgp-signature; name="signature.asc"
-----BEGIN PGP SIGNATURE-----
iQIzBAEBCgAdFiEEgxUkqkMp0LnoXjCr2dtBqWwiadMFAl9oviUACgkQ2dtBqWwi
adPCShAAmxOnEMZeaPQK6+YnfLcfjrHyKK2Ru+S4ATPYhb0MQkzM7skyuP5XVk0p
yIPKASEwDZuXosnmTx7uJwTWQtx7lf+fsPbc4ye+KgTJ4dnEmEq94/hw56gCUo3N
qNzPE4Pa4PEMYmT/w8aJ55Jwvymb1slHwRxY8QbAVUiVfwy+yT1NTjcerkdiLsjU
zsJzbr26ZrUCaevx/vm7+8xrwtaXuzqWWodMtCzDCt30mXfOttLBh5o14K6zP+We
11yQ28HVOuRPxLIItI5sN7vKwZSHn6anQyjpuJQ/bRgVw4dlWZEtpDp6i0tVbePG
ezxFLtABUgnC3vIo6b7zU+NtTv33paflXdgqEtdqI3n/wKaMc9mHlA6MZDuWZoSY
LNlgmrwUbQpgABkH/In+UV5dVdSXMhyoIp7YqLL/cHOLpA4r5JL5EzXRE3Q38Ps7
lsdunr5bPLVWPIkuHZ9tE0GDEddvEhes6/YGvBJNvGT6O0Xgky4nmlcVtlokWkV7
HuloudOyGWvUDavqDJznnW3TyYrE1j+2ZrhvmsxLL9dyHfA+Xn0AHzt3UCyHgRIs
AuHy/XI+3LX0quNRIOjac4uEVJEatehjgMFk0BiZ+UtteIYj5Vg3O6U5VFHOcVCU
so0Ynr39Yuu9TcYTYhL6dbEzxsDslfvl0h5AnLdgKHvnTQepFJI=
=xMt9
-----END PGP SIGNATURE-----
--6wtnduqfij32l4i6--
|
