summaryrefslogtreecommitdiff
path: root/bf/ec87ad25dc9af22480df31f28d39894e210654
blob: 7dcebc86d44c6b7b2fac999fe959b1a56a71f7e6 (plain)
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
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
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 7827EC002C;
 Sun, 10 Apr 2022 19:33:03 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 5546940363;
 Sun, 10 Apr 2022 19:33:03 +0000 (UTC)
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.8
X-Spam-Level: 
X-Spam-Status: No, score=-2.8 tagged_above=-999 required=5
 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1,
 DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_LOW=-0.7,
 RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
 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="iIKtj2gA";
 dkim=pass (2048-bit key) header.d=messagingengine.com
 header.b="QpKJi4iY"
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 Mh9GgNCaWJwK; Sun, 10 Apr 2022 19:33:01 +0000 (UTC)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com
 [64.147.123.19])
 by smtp4.osuosl.org (Postfix) with ESMTPS id 6F38340023;
 Sun, 10 Apr 2022 19:33:01 +0000 (UTC)
Received: from compute2.internal (compute2.nyi.internal [10.202.2.46])
 by mailout.west.internal (Postfix) with ESMTP id 8467F32001C6;
 Sun, 10 Apr 2022 15:32:56 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute2.internal (MEProxy); Sun, 10 Apr 2022 15:32:56 -0400
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=fm2; bh=d1agli0/qTJc2gadojm9e4g39MkpC0
 43kG8LJhV1nfA=; b=iIKtj2gAoomdHmM+ND5gjG6b+cr33boEi2jq/WWbVTcOMQ
 rq83ihlWNIdr+V2CrXMbEVc3zjDHSw7bGqD5qc9CmTnG7ujY49XSpmODjrRtLzC3
 jmjaCFaTzKbBHKSO/CVIX0jRJ6mTQI5w/aaNQRBQ+9dcFk2XS5jpUO286KdUEG25
 1y9OpIi8bBq8m2b7LLHMc+6yHQqHLtwuAbrNCUMKvscDHvJSsKewUlwqblG4eA5L
 6rfOunHQrmxmoQudm+/W67FUPQIwIIvVnvnTChNp+s45V4zqnqO/ufUg95qaOw5q
 jCXUJOPURMY91VjzGNjy9esO304UBHLJDDK1UVXw==
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=fm3; bh=d1agli0/qTJc2gado
 jm9e4g39MkpC043kG8LJhV1nfA=; b=QpKJi4iYr1RimAErJJBsO5xaG9EKEq7JG
 w+c8O0rTcUX9nGD7/emammUJadoIm3LsQOmv3n7mwKq57+XVvrTsH2dZaZuRUiPy
 cVYnyEAbUJ1DX3FnPl1PoV5vjc1GGL1Nf+92RS9aZTWMzmfwJ/xA5SA5RArVKw9o
 J+ReSAXu0zxaN2VRqRcSvFwq4sfHo8iV+/Ba/7Kc5BflxhBH7DdNqwP1HZE2YnsR
 dRettHmghMyxL4YUCotacz6VFOwTEiWW30PFyWC3iVs/E54Wr/6mbnlrRJLMoTzw
 NqAfk2mFQos0G+vs7tPoRx+Inn7hc44udhmeiOEHLXOOTR39iX9GA==
X-ME-Sender: <xms:5zBTYhotJBXG7VW4r_uxD4RSrOjDCF0P_B0jf8FoMakSKfyiv2aG8g>
 <xme:5zBTYjqs2uh0nCnxu5Uay8zdwyIN9kI84nGDeWseuFoxR6RCyLiNvNUH_3zCdYx1-
 GtQcnnN9M3RqKmep4U>
X-ME-Received: <xmr:5zBTYuPIr6TMw_3BQZiRbes0oOeWkQroT_wBi0YFeG7nfIiNJOybho_hPCwC>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekgedgudefiecutefuodetggdotefrod
 ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh
 necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd
 enucfjughrpeffhffvuffkfhggtggujgesghdtreertddtvdenucfhrhhomheprfgvthgv
 rhcuvfhougguuceophgvthgvsehpvghtvghrthhouggurdhorhhgqeenucggtffrrghtth
 gvrhhnpeefveeuleetvdehgeetgeeiteekleeihfehtdffledtheduiefffffhffdvgefg
 geenucffohhmrghinhepfihikhhiphgvughirgdrohhrghdpphgvthgvrhhtohguugdroh
 hrghenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpehu
 shgvrhesphgvthgvrhhtohguugdrohhrgh
X-ME-Proxy: <xmx:6DBTYs7me13Vq065lOr2sOoKsVR9x98ocs2KGigRqEoLTgu6loAHvA>
 <xmx:6DBTYg4eSsU1C7opFP7SUmCMb_JZ67QM_B9fi0aYFjGQT9hoIwIqjw>
 <xmx:6DBTYkj8XfHeYLuAbkMUhuWOKjhOCcQ4YsVOLc9P__ON2wz6gW-ZLg>
 <xmx:6DBTYgGfCT6Oftc63LFnn5mtI0xPJpa8VDGygwuw-i41m9lKO87EDA>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Sun,
 10 Apr 2022 15:32:55 -0400 (EDT)
Received: by localhost (Postfix, from userid 1000)
 id 801875F739; Sun, 10 Apr 2022 15:32:52 -0400 (EDT)
Date: Sun, 10 Apr 2022 15:32:52 -0400
From: Peter Todd <pete@petertodd.org>
To: Jeremy Rubin <jeremy.l.rubin@gmail.com>
Message-ID: <YlMw5NxXnGV9WrVg@petertodd.org>
References: <CAD5xwhik6jVQpP2_ss7d5o+pPLsqDCHuaXG41AMKHVYhZMXF1w@mail.gmail.com>
 <YgS3sJvg6kG3WnVJ@petertodd.org>
 <CAD5xwhi3Ja8gdU2h_6-1ck4kdU0TiC2Kx5O-61=f9=6JQSMs=A@mail.gmail.com>
 <YhAwr7+9mGJAe2/p@petertodd.org>
 <CAD5xwhi=sKckFZew75tZTogoeFABraWtJ6qMC+RgZjcirxYyZw@mail.gmail.com>
 <YhC6yjoe3bAfBS+W@petertodd.org>
 <CAD5xwhjR06Lp3ka-MqZQE64tfE5uDQB6TrMh06khjYrDzuT95g@mail.gmail.com>
MIME-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-sha512;
 protocol="application/pgp-signature"; boundary="GXfBbLfz3Ln4S9kK"
Content-Disposition: inline
In-Reply-To: <CAD5xwhjR06Lp3ka-MqZQE64tfE5uDQB6TrMh06khjYrDzuT95g@mail.gmail.com>
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 lightning-dev <lightning-dev@lists.linuxfoundation.org>,
 Jeremy <jlrubin@mit.edu>
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: Sun, 10 Apr 2022 19:33:03 -0000


--GXfBbLfz3Ln4S9kK
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sun, Feb 20, 2022 at 08:29:00AM -0800, Jeremy Rubin wrote:
> > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > > > As I said, it's a new kind of pinning attack, distinct from other t=
ypes
> > > of pinning attack.
> > >
> > > I think pinning is "formally defined" as sequences of transactions wh=
ich
> > > prevent or make it less likely for you to make any progress (in terms=
 of
> > > units of computation proceeding).
> >
> > Mentioning "computation" when talking about transactions is misleading:
> > blockchain transactions have nothing to do with computation.
> >
>=20
> It is in fact computation. Branding it as "misleading" is misleading... T=
he
> relevant literature is https://en.wikipedia.org/wiki/Non-blocking_algorit=
hm,
> sponsors helps get rid of deadlocking so that any thread can be guaranteed
> to make progress. E.g., this is critical in Eltoo, which is effectively a
> coordinated multi-party computation on-chain to compute the highest
> sequence number known by any worker.
>=20
> That transactions are blobs of "verification" (which is also itself a
> computation) less so than dynamic computations is irrelevant to the fact
> that series of transactions do represent computations.

It's misleading in the blockchain environment where lots of people have been
trying to portray blockchain schemes as "world computers" and other nonsense
marketing. You would have been better off just saying "make any progress"
without mentioning "computation" at all.

> > > Something that only increases possibility to make progress cannot be
> > > pinning.
> >
> > It is incorrect to say that all use-cases have the property that any
> > version of
> > a transaction being mined is progress.
> >
>=20
> It is progress, tautologically. Progress is formally definable as a
> transaction of any kind getting mined. Pinning prevents progress by an
> adversarial worker. Sponsoring enables progress, but it may not be your
> preferred interleaving. That's OK, but it's inaccurate to say it is not
> progress.

Let's try to use terminology with straight-forward meanings. I've yet to see
any other protocol where "progess" can also mean useless work being done.

> I didn't claim there to be a chain of unconfirmed, I claimed that there
> could be single output chain that you're RBF'ing one step per block.
>=20
> E.g., it could be something like
>=20
> A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
> A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}}
>=20
> such that A_i provably can't have an unconfirmed descendant. The notion
> would be that you're replacing one with another. E.g., if you're updating
> the calendar like:
>=20
>=20
> Version 0: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
> Version 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}
> Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar, delta}}
>=20
> and version 1 gets mined, then in A_1's spend you simply shift delta to
> that (next) calendar.
>=20
> A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {delta}}
>=20
> Thus my claim that someone sponsoring a old version only can delay by 1
> block the calendar commit.

You seem to still be confused about OpenTimestamps. There is no output chai=
n at
all; OTS has no reason to use CheckSequenceVerify and does not. OTS
transactions are, from the point of view of the timestamp proofs, entirely
independent of one another.

Remember that OTS simply proves data in the past. Nothing more.

> > > Lastly, if you do get "necromanced" on an earlier RBF'd transaction b=
y a
> > > third party for OTS, you should be relatively happy because it cost y=
ou
> > > less fees overall, since the undoing of your later RBF surely returned
> > some
> > > satoshis to your wallet.
> >
> > As I said above, no it doesn't.
> >
> >
> It does save money since you had to pay to RBF, the N+1st txn will be
> paying higher fee than the Nth. So if someone else sponsors an earlier
> version, then you save whatever feerate/fee bumps you would have paid and
> the funds are again in your change output (or something). You can apply
> those change output savings to your next batch, which can include any
> entries that have been dropped .

Again, that is not true. Because OTS doesn't have a chain of transactions, =
I'd
rather do one transaction with all pending commitments at a particular time
rather than waste money on mining two transactions for a given set of
commitments that need timestamping.

--=20
https://petertodd.org 'peter'[:-1]@petertodd.org

--GXfBbLfz3Ln4S9kK
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEE0RcYcKRzsEwFZ3N5Lly11TVRLzcFAmJTMOEACgkQLly11TVR
LzfyWhAAgVKu/QZBwvBC0UNetiKdjEkfYFxz4cEgqYaOcS88Av3nglKRY6zXG9eb
QhBlPSCGtrvOGTI5MDSjAbQZ1jPZv8kWWck5DmZafRGFpTQ5UT4onwaGyq4bkxzK
N/DSn6v6pyo79DnL5CgF8oUywqFESIosfm3ZYgNGU5hv0W+yk9Fa5k9jo/C23H3U
/8x/hUxWtqTJv8lFYIYlB/OW1VrgPq60zD9kSTSnrrgugUXj2wZT5druScRWL9mY
nFmPuDM5ruxrVM1mc2/pNI20xe677fazJ4sn9uElxb6C0DKYLCKXV5bK1zGf07rW
ohnBx4ZRikyqUe9XIG5pzz3OlT/WYYJN2Q7KBopHT8+6NTlowWcV1FtNbvSc8TDl
KrnXo0ugLzrB+7Fk75mm4CE1pIdI16T34gJ2TVxUlZHGkZP8+Uos2LfjhBwyczjB
0N029CPpYRoSYQ8jKeZruEXyaGeeAilvwYoKIG0rV7ul3awlvsv11mSIQ0cBHyv8
ETMFET9RWCseQ9pI1I2kkGi98+G0XHYFHoib13gocnqzz9U5OVGiW0r+HGYr9sqN
vALh4g0bRA1lJqP2LcJ7uIxwp/pVJsjGIWry4O/rY3cJopHj6vvAMYaZ3Zl6kUz4
VxMNEqynRgYZxCvmsY28Vcb2T02ZpyqZA6KQKAXhRkg0xMYA6R0=
=nhF5
-----END PGP SIGNATURE-----

--GXfBbLfz3Ln4S9kK--