summaryrefslogtreecommitdiff
path: root/87/cd51ace4dafd152a4a1cad31b6a776266fd323
blob: 67125432d5cda3ccf5012090abb0736497d70211 (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
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
Return-Path: <alicexbt@protonmail.com>
Received: from smtp4.osuosl.org (smtp4.osuosl.org [140.211.166.137])
 by lists.linuxfoundation.org (Postfix) with ESMTP id 92066C002F
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 18:12:55 +0000 (UTC)
Received: from localhost (localhost [127.0.0.1])
 by smtp4.osuosl.org (Postfix) with ESMTP id 6ABF34208D
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 18:12:55 +0000 (UTC)
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org 6ABF34208D
Authentication-Results: smtp4.osuosl.org;
 dkim=pass (2048-bit key) header.d=protonmail.com header.i=@protonmail.com
 header.a=rsa-sha256 header.s=protonmail3 header.b=bUeXEIT7
X-Virus-Scanned: amavisd-new at osuosl.org
X-Spam-Flag: NO
X-Spam-Score: -2.102
X-Spam-Level: 
X-Spam-Status: No, score=-2.102 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, FREEMAIL_FROM=0.001,
 RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001]
 autolearn=ham autolearn_force=no
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 vqwfWdtEl33G
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 18:12:53 +0000 (UTC)
X-Greylist: domain auto-whitelisted by SQLgrey-1.8.0
DKIM-Filter: OpenDKIM Filter v2.11.0 smtp4.osuosl.org C103B4208C
Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19])
 by smtp4.osuosl.org (Postfix) with ESMTPS id C103B4208C
 for <bitcoin-dev@lists.linuxfoundation.org>;
 Thu, 30 Mar 2023 18:12:52 +0000 (UTC)
Date: Thu, 30 Mar 2023 18:12:46 +0000
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=protonmail.com;
 s=protonmail3; t=1680199969; x=1680459169;
 bh=jZlFZwg3maiW3gegmTegeDp1gHu+EGkNnhV5Tdnw6XE=;
 h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References:
 Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID:
 Message-ID:BIMI-Selector;
 b=bUeXEIT7BqqLygUUhtLZEUhAC98QNvt7JpBP9HgrzZGEf22I/GC0h3GSWq85cW8LP
 r/GwRXQOHFlQ5zfy4tzqWcTH6yHFYRmk+LrZlhdX3fGRR85zpduC3pZzNVDihaPdGW
 WkgR/XEVCak9SqS9vafX2gSSZhM2hvehIF/CFqFScJZJnqveEK35r4AqeevQedu+e3
 N0yx4G6lGGkI9BXyCNGLg2CW5509Cr+wfMqMSODJ3eGmy8904y+GxNt2Mf2352E8VV
 tue9YbTILhFreF6o+IA22W9/YfI9JpiM5RIuE+Rh+4q6xZLhqu62qOHNxg8JRH4fT2
 ojDgHcBH0DpSA==
To: Zac Greenwood <zachgrw@gmail.com>
From: alicexbt <alicexbt@protonmail.com>
Message-ID: <v7l8qpYTrt0POXPCeN4FJIDtZnItd8u7Gs9qd3FKiVoduEXfisATmmRA0SfYAKFR0mzZFY8-4zgzA0R2dJqIW4p_gXchZMECoY9I_-6fX6w=@protonmail.com>
In-Reply-To: <CAJ4-pEDq7kqLR9bAguShazdH6H92Y-pgNsOdEuqj=HaTWom88w@mail.gmail.com>
References: <CAPfvXfJQKb7i8GBvTEvTTz-3dU_5mH8jOv8Nm4Q8gPt=KxrqLQ@mail.gmail.com>
 <CAB3F3DveCDz6yy-rd3ttV8+4sMufsvB+9J-qVK95yh9aLYX+Mw@mail.gmail.com>
 <ZAAqIZZO1KK32Th9@erisian.com.au>
 <CAB3F3DtGpVHkyT_=KLS42rvdP=dgnMvChhR1Rs0BHO5yOEabmw@mail.gmail.com>
 <CAPfvXf+4iX0h-nSuyTai_VvJHkDvAyKtgSk6DsaEwE8N3wnYEg@mail.gmail.com>
 <ZAcx7oEZxC9BiWvg@erisian.com.au> <ZB2THW3WT2wiU7Ni@erisian.com.au>
 <CAJ4-pEAyuHi-1iBzYWbpUNi2-YkxFLVBKAWTV=TyP1TVTFYMfA@mail.gmail.com>
 <C4SV8-jdNABNgVA8aE8Du6WITwynrcq9st7wkSN4k6Px4zhWKWZdSlAvYhTLRXe3yDMC5uNhRNoMGAdMqKReVYUjr-0dGGv9H2u2L9v7gtY=@protonmail.com>
 <CAJ4-pEDq7kqLR9bAguShazdH6H92Y-pgNsOdEuqj=HaTWom88w@mail.gmail.com>
Feedback-ID: 40602938:user:proton
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Mailman-Approved-At: Fri, 31 Mar 2023 09:54:10 +0000
Cc: Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>,
 Anthony Towns <aj@erisian.com.au>
Subject: Re: [bitcoin-dev] BIP for OP_VAULT
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, 30 Mar 2023 18:12:55 -0000

Hi Zac,

> Regarding =E2=80=9CFees paid: 150 BTC=E2=80=9D (uh, *citation needed*):

https://dune.com/queries/2008613/3326984

> Your other arguments are nonsensical so excuse me for ignoring them.

There were zero browser extensions that could sign PSBT to be used in diffe=
rent bitcoin projects that have web interface earlier. Now there are severa=
l open source extensions that could be used to sign PSBT. If such developme=
nt and interest by developers from other chains to build things on bitcoin =
makes no sense to you that there is nothing much to debate here.

Humans have inscribed things on money since thousands of years when bitcoin=
 didn't even exist. Trying to fight this and going against market wont work=
.

I do not agree with other things mentioned in your email.

/dev/fd0
floppy disk guy

Sent with Proton Mail secure email.

------- Original Message -------
On Thursday, March 30th, 2023 at 4:09 PM, Zac Greenwood <zachgrw@gmail.com>=
 wrote:


> Hi alicexbtc,
>=20
> Under no circumstance should Bitcoin add any functionality intended to su=
pport private businesses that rely on on-chain storage for their business m=
odel.
>=20
> Regarding =E2=80=9CFees paid: 150 BTC=E2=80=9D (uh, *citation needed*):
>=20
> To optimize for profitability a business would generally attempt to opera=
te using zero- or low-fee transactions. Therefore they tend to contribute c=
omparatively little fees but are depriving public use of these cheap transa=
ctions. Worse, they exert a constant upward pressure on fee levels, making =
it more expensive for everyone else to transact.
>=20
> Unlike miners, node operators do not receive any compensation. They howev=
er incur additional cost for bandwidth, electricity and processing time to =
not only support some current business but all businesses in the past that =
ever tried to turn a profit at their expense, so also after such business f=
ailed and has been long gone. They foot the bill.
>=20
> Lastly, I don=E2=80=99t believe there is any value in having for instance=
 Ordinals spam the blockchain with images of wojaks, bored apes and other c=
rap but perhaps you wish to clarify why this might be something to be =
=E2=80=9Cexcited about=E2=80=9D.
>=20
> Your other arguments are nonsensical so excuse me for ignoring them.
>=20
>=20
> Zac
>=20
>=20
> On Thu, 30 Mar 2023 at 03:57, alicexbt <alicexbt@protonmail.com> wrote:
>=20
> > Hi Zac,
> >=20
> > Let me share what those parasites achieved:
> >=20
> > - Fees paid: 150 BTC
> > - Lot of users and developers trying bitcoin that either never tried or=
 gave up early in 2013-15
> > - Mempools of nodes of being busy on weekends and got lots of transacti=
ons
> > - PSBT became cool and application devs are trying their best to use it=
 in different ways
> > - Some developers exploring taproot and multisig
> > - AJ shared things how covenants could help in fair, non-custodial, on-=
chain auction of ordinals that is MEV resistant although I had shared it ea=
rlier which involves more steps: https://twitter.com/1440000bytes/status/16=
34368411760476161
> > - Investors exploring about funding projects
> > - Bitcoin more than Bitcoin and people excited about it
> >=20
> > We can have difference of opinion, however I want bitcoin to be money a=
nd money means different things for people in this world. Please respect th=
at else it will become like Linux, something used by 1% of world.
> >=20
> > /dev/fd0
> > floppy disk guy
> >=20
> > Sent with Proton Mail secure email.
> >=20
> > ------- Original Message -------
> > On Wednesday, March 29th, 2023 at 12:40 PM, Zac Greenwood via bitcoin-d=
ev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> >=20
> >=20
> > > I=E2=80=99m not sure why any effort should be spent on theorizing how=
 new opcodes might be used to facilitate parasitical use cases of the block=
chain.
> > >
> > > If anything, business models relying on the ability to abuse the bloc=
kchain as a data store must be made less feasible, not more.
> > >
> > > Zac
> > >
> > >
> > > On Fri, 24 Mar 2023 at 20:10, Anthony Towns via bitcoin-dev <bitcoin-=
dev@lists.linuxfoundation.org> wrote:
> > >
> > > > On Tue, Mar 07, 2023 at 10:45:34PM +1000, Anthony Towns via bitcoin=
-dev wrote:
> > > > > I think there are perhaps four opcodes that are interesting in th=
is class:
> > > > >
> > > > > idx sPK OP_FORWARD_TARGET
> > > > > -- sends the value to a particular output (given by idx), and
> > > > > requires that output have a particular scriptPubKey (given
> > > > > by sPK).
> > > > >
> > > > > idx [...] n script OP_FORWARD_LEAF_UPDATE
> > > > > -- sends the value to a particular output (given by idx), and
> > > > > requires that output to have almost the same scriptPubKey as this
> > > > > input, _except_ that the current leaf is replaced by "script",
> > > > > with that script prefixed by "n" pushes (of values given by [...]=
)
> > > > >
> > > > > idx OP_FORWARD_SELF
> > > > > -- sends the value to a particular output (given by idx), and
> > > > > requires that output to have the same scriptPubKey as this input
> > > > >
> > > > > amt OP_FORWARD_PARTIAL
> > > > > -- modifies the next OP_FORWARD_* opcode to only affect "amt",
> > > > > rather than the entire balance. opcodes after that affect the
> > > > > remaining balance, after "amt" has been subtracted. if "amt" is
> > > > > 0, the next OP_FORWARD_* becomes a no-op.
> > > >
> > > > The BIP 345 draft has been updated [0] [1] and now pretty much defi=
nes
> > > > OP_VAULT to have the behaviour specced for OP_FORWARD_LEAF_UPDATE a=
bove,
> > > > and OP_VAULT_RECOVER to behave as OP_FORWARD_TARGET above. Despite
> > > > that, for this email I'm going to continue using the OP_FORWARD_*
> > > > naming convention.
> > > >
> > > > Given the recent controversy over the Yuga labs ordinal auction [2]=
,
> > > > perhaps it's interesting to consider that these proposed opcodes co=
me
> > > > close to making it possible to do a fair, non-custodial, on-chain a=
uction
> > > > of ordinals [3].
> > > >
> > > > The idea here is that you create a utxo on chain that contains the =
ordinal
> > > > in question, which commits to the address of the current leading bi=
dder,
> > > > and can be spent in two ways:
> > > >
> > > > 1) it can be updated to a new bidder, if the bid is raised by at le=
ast
> > > > K satoshis, in which case the previous bidder is refunded their
> > > > bid; or,
> > > >
> > > > 2) if there have been no new bids for a day, the current high bidde=
r
> > > > wins, and the ordinal is moved to their address, while the funds
> > > > from their winning bid are sent to the original vendor's address.
> > > >
> > > > I believe this can be implemented in script as follows,
> > > > assuming the opcodes OP_FORWARD_TARGET(OP_VAULT_RECOVER),
> > > > OP_FORWARD_LEAF_UPDATE(OP_VAULT), OP_FORWARD_PARTIAL (as specced ab=
ove),
> > > > and OP_PUSHCURRENTINPUTINDEX (as implemented in liquid/elements [4]=
)
> > > > are all available.
> > > >
> > > > First, figure out the parameters:
> > > >
> > > > * Set VENDOR to the scriptPubKey corresponding to the vendor's addr=
ess.
> > > > * Set K to the minimum bid increment [5].
> > > > * Initially, set X equal to VENDOR.
> > > > * Initially, set V to just below the reserve price (V+K is the
> > > > minimum initial bid).
> > > >
> > > > Then construct the following script:
> > > >
> > > > [X] [V] [SSS] TOALT TOALT TOALT
> > > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > > DEPTH NOT IF
> > > > 0 10000 FORWARD_PARTIAL
> > > > 0 FROMALT FORWARD_TARGET
> > > > 1 [VENDOR] FWD_TARGET
> > > > 144
> > > > ELSE
> > > > FROMALT SWAP TUCK FROMALT
> > > > [K] ADD GREATERTHANOREQUAL VERIFY
> > > > 1 SWAP FORWARD_TARGET
> > > > DUP FORWARD_PARTIAL
> > > > 0 ROT ROT
> > > > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > > > 0
> > > > ENDIF
> > > > CSV
> > > > 1ADD
> > > >
> > > > where "SSS" is a pushdata of the rest of the script ("TOALT TOALT T=
OALT
> > > > .. 1ADD").
> > > >
> > > > Finally, make that script the sole tapleaf, accompanied by a NUMS p=
oint
> > > > as the internal public key, calculate the taproot address correspon=
ding
> > > > to that, and send the ordinal to that address as the first satoshi.
> > > >
> > > > There are two ways to spend that script. With an empty witness stac=
k,
> > > > the following will be executed:
> > > >
> > > > [X] [V] [SSS] TOALT TOALT TOALT
> > > > -- altstack now contains [SSS V X]
> > > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > > -- this input is the first, so the ordinal will move to the first
> > > > output
> > > > DEPTH NOT IF
> > > > -- take this branch: the auction is over!
> > > > 1 [VENDOR] FWD_TARGET
> > > > -- output 1 gets the entire value of this input, and pays to
> > > > the vendor's hardcoded scriptPubKey
> > > > 0 10000 FORWARD_PARTIAL
> > > > 0 FROMALT FORWARD_TARGET
> > > > -- we forward at least 10k sats to output 0 (if there were 0 sats,
> > > > the ordinal would end up in output 1 instead, which would be a
> > > > bug), and output 0 pays to scriptPubKey "X"
> > > > 144
> > > > ELSE .. ENDIF
> > > > -- skip over the other branch
> > > > CSV
> > > > -- check that this input has baked for 144 blocks (~1 day)
> > > > 1ADD
> > > > -- leave 145 on the stack, which is true. success!
> > > >
> > > > Alternatively, if you want to increase the bid you provide a stack =
with
> > > > two items: your scriptPubKey and the new bid [X' V']. Execution thi=
s
> > > > time looks like:
> > > >
> > > > [X] [V] [SSS] TOALT TOALT TOALT
> > > > -- stack contains [X' V'], altstack now contains [SSS V X]
> > > > 0 PUSHCURRENTINPUTINDEX EQUALVERIFY
> > > > -- this input is the first, so the ordinal will move to the first
> > > > output
> > > > DEPTH NOT IF ... ELSE
> > > > -- skip over the other branch (without violating minimalif rules)
> > > > FROMALT SWAP TUCK FROMALT
> > > > -- stack contains [X' V' X V' V], altstack contains [SSS]
> > > > [K] ADD GREATERTHANOREQUAL VERIFY
> > > > -- check V' >=3D V+K, stack contains [X' V' X]
> > > > 1 SWAP FORWARD_TARGET
> > > > -- output 1 pays to X (previous bidder's scriptPubKey), and the
> > > > entire value of this input goes there; stack contains [X' V']
> > > > DUP FORWARD_PARTIAL
> > > > -- execute "V' FORWARD_PARTIAL", stack contains [X' V']
> > > > 0 ROT ROT
> > > > -- stack contains [0 X' V']
> > > > FROMALT DUP 3 SWAP FORWARD_LEAF_UPDATE
> > > > -- execute "0 X' V' SSS 3 SSS FORWARD_LEAF_UPDATE" which checks
> > > > that output 0 spends at least V' satoshis back to the same
> > > > script (because that's how we defined SSS), except the first
> > > > three pushes (previously X V SSS) are replaced by X' V' SSS.
> > > > 0
> > > > ENDIF
> > > > CSV
> > > > -- "0 CSV" requires nSequnce to be set, which makes the tx rbf'able=
,
> > > > which hopefully makes it harder to pin
> > > > 1ADD
> > > > -- ends with 1 on the stack; success!
> > > >
> > > > (The "SSS n SSS FORWARD_LEAF_UPDATE" construct is more or less a qu=
ine,
> > > > ie a program that outputs its own source code)
> > > >
> > > > I think that script is about 211 witness bytes, with an additional =
40
> > > > witness bytes for X'/V', so when making a bid, your tx would be
> > > > something like:
> > > >
> > > > tx header, 10vb
> > > > input 0: 103vb for the old bid including witness and control block
> > > > input 1: 58vb for a taproot key path spend
> > > > output 0: 43vb for the new bid
> > > > output 1: 43vb for your change
> > > >
> > > > for a total of about 257vb -- slightly larger than a regular 2-in-2=
-out
> > > > transaction, but not terribly much. Mostly because input 0 doesn't =
require
> > > > a signature -- it's size is effectively 6 pubkeys: X, X' VENDOR twi=
ce,
> > > > and the script code twice, along with a little extra to encode the
> > > > various numbers (10000, 144, K, V, V').
> > > >
> > > > This approach seems pretty "MEV" resistant: you pay fees via input =
1 if
> > > > your bid succeeds; if it doesn't, you don't pay any fees. A potenti=
al
> > > > scalper might want to put in an early low ball bid, then prevent
> > > > higher bidders from winning the auction, take control of the ordina=
l,
> > > > and resell it later, but unless they can prevent another miner from
> > > > mining alternative bids for 144 blocks, they will fail at that. The=
 bid
> > > > is fixed by the bidder and committed to by the signature on input 1=
, so
> > > > frontrunning a bid can't do anything beyond invalidate the bid enti=
rely.
> > > >
> > > > Obviously, this is a pretty limited auction mechanism in various wa=
ys;
> > > > eg maybe you'd rather specify K as a percentage than an absoute inc=
rement;
> > > > maybe you'd like to have the auction definitely finish by some part=
icular
> > > > time; maybe you'd like to be able to have the auction be able to co=
ntinue
> > > > above 21.47 BTC (2**31 sats); maybe you'd like to do a dutch auctio=
n
> > > > rather than an english auction. I think you can probably do all tho=
se
> > > > things with this set of opcodes and clever scripting, though it pro=
bably
> > > > gets ugly.
> > > >
> > > > I don't think this is easily extensible to taro or rgb style assets=
,
> > > > as rather than being able to ensure the asset is transferred by
> > > > controlling the input/output positions, I think you'd need to build
> > > > up merkle trees and do point tweaks beyond what's supported by
> > > > OP_FORWARD_LEAF_UPDATE/OP_VAULT. Of course, without something like
> > > > OP_PUSHCURRENTINPUTINDEX I don't think you could do it for ordinals
> > > > either.
> > > >
> > > > Cheers,
> > > > aj
> > > >
> > > > [0] https://github.com/bitcoin/bips/blob/7f747fba82675f28c239df690a=
07b75529bd0960/bip-0345.mediawiki
> > > >
> > > > [1] https://twitter.com/jamesob/status/1639019107432513537
> > > >
> > > > [2] https://cointelegraph.com/news/scammers-dream-yuga-s-auction-mo=
del-for-bitcoin-nfts-sees-criticism
> > > >
> > > > [3] Inscriptions remain a wasteful way of publishing/committing
> > > > to content, however!
> > > >
> > > > [4] https://github.com/ElementsProject/elements/blob/master/doc/tap=
script_opcodes.md
> > > >
> > > > [5] Setting K too low probably invites griefing, where a bidder may=
 be
> > > > able to use rbf pinning vectors to prevent people who would be will=
ing
> > > > to bid substantially higher from getting their bid confirmed on
> > > > chain.
> > > > _______________________________________________
> > > > bitcoin-dev mailing list
> > > > bitcoin-dev@lists.linuxfoundation.org
> > > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev